How to Mature Your Software Consumption and Modernize Your Software Supply Chain Security
Software supply chain security rose to prominence after the SolarWinds hack - an event that impacted organizations and governments around the globe. The last few years have similarly been laden with issues and compromises, and the market landscape has filled with vendors talking about many different aspects and facets of the problem and attack surface. The problem with vendors driving the conversation around software supply chain security is that the term has often been twisted to fit the vendor's services as opposed to staying true to the definition of the intended outcomes. You can easily see this in motion yourself - a quick Google search about anything related to SBOMs or their specifications will yield endless pages of vendor blogs that discuss the concepts in the abstract, but provide no actionable information.
This might sound like an odd thing to hear coming from the co-founder and CEO of a vendor, but it is something that continuously bothers me, having been a practitioner myself. The whole reason my my co-founders and I founded Phylum due to hands-on exposure to the problem domain, and seeing first-hand the risks all large organizations are constantly exposing themselves to. At the time, there was not a single product in the market that addressed the issue. After launching Phylum, I watched as SCA, SAST and various types of vulnerability management vendors all convinced practitioners that they protected your software supply chains.
I’m not saying vulnerabilities should not be addressed as part of your appsec program. They absolutely should. They impact code quality and introduce risks. However, they are not the go-to attack vector for software supply chain attacks. Vulnerabilities are only exploited 2%-7% of the time, yet most vendors still only focus on detecting and remediating vulnerabilities while calling it software supply chain security. Imagine how frustrating it is, then, to watch malicious packages that have a 100% execution rate be published over and over and over again, and most companies are completely blind to it.
If you are taking a fresh look at your appsec program, consider what you can do to mature your software consumption and modernize your software supply chain security.
Core Components of a Software Supply Chain Security Program
Fundamentally, the software supply chain consists of people, processes, inputs and controls.
People are the human element in the process: software developers, security practitioners, devops professionals, and third-party contributors who develop, maintain, and manage the software and its surrounding infrastructure. Processes are comprised of the engineering practices and tools that enable development and delivery to happen: CI/CD workflows, security and testing protocols, etc. Inputs are the software libraries and packages, container images, infrastructure as code components, and the software developers have written in-house. Controls are the variable, which include all the vendor categories that touch your appsec program with varying degrees of overlap: software supply chain security, software composition analysis (SCA), static application security testing (SAST), application security posture management (ASPM), etc.
Three Different Categories of Focus Require Nuanced Approaches
With respect to software supply chain security it is important to split the focus into three categories - risks, attacks and compliance.
Risks are things that introduce potential threats. This includes vulnerabilities, license misuse, engineering risks, author insights, etc. Attacks are executed by bad actors publishing malicious code with the specific intention of compromising one or more organizations. Attack types include typosquatting, social engineering, dependency confusion, starjacking, etc., which all result in malicious code executing on company infrastructure. This looks less like what vulnerability management would cover, and more like the “Initial Access” section of the Mitre Att&ck framework. Compliance is focused on mandatory outcomes, in this case it includes things like SBOMs, vulnerability- free software delivery, or implementing mandatory controls to meet CMMC, FedRAMP, NIST, DORA, or other regulatory guidelines.
There is no one-size-fits-all approach to cover all three categories. While some of the risks, such as managing accesses of people and performing scans for vulnerabilities in development inputs, are mandated by regulations and security certifications, other issues are often either overlooked or may be captured in more nebulous regulatory documents such as CISA's self-attestation form or DORA's mandate to know your suppliers. Others, such as FedRAMP or CMMC, may require the creation of artifacts (such as a Software Bill of Materials) to try to understand the components within the software, but may not explicitly distinguish between the types of risks that need to be mitigated or managed.
From the perspective of a security professional, how do you even begin to approach this spectrum of issues? That all depends on what stage your core components are in: What human resources do you have available? What processes are in place now, and which ones need to be implemented? What tools are developers using to build software? What controls are already in place, and where are your gaps? The maturity process with Phylum varies based on answers to these questions.
To be clear, Phylum is not a vulnerability management tool. We are not SCA, we are not SAST and we are not ASPM. However, we play nicely with all these tools to cover their blind spots, and none do what we do. We focus on identifying and contextualizing software supply chain security risks, blocking attacks, establishing and enforcing policy, and helping organizations achieve software-related compliance and governance. We are uniquely positioned to do so because we analyze all third-party code as it is published into the open-source ecosystem so we know what’s in software packages before a developer installs it. Phylum’s findings are proprietary based on our analysis engine that uses SAST, Heuristics and ML/AI to detect and report zero-day findings that can’t be found on published, curated lists. When a prospect comes to us, we work with them to achieve the following based on how mature each of the core components of their program are:
Visibility/Monitoring: A shocking number of security organizations have little to no insight into what their developers are utilizing - meaning they are often already impacted by software supply chain attacks, which have escalated exponentially over the last year. For our users with no or limited visibility, we usually recommend first deploying Phylum into CI/CD pipelines in non-blocking mode, which enables security teams to start seeing if and when an incident has occurred. Then, we might implement an integration with an existing security boundary product as a next step, such as Phylum's Netskope integration, to see if any malicious or compromised software is being downloaded by developers. We also offer a threat feed of our high-fidelity malicious open-source package software indicators for organizations that want to correlate attack data in SIEMs, EDRs or Observability tools.
Policy Enforcement: Depending on an organization’s needs, we can set them up with our default policy or help setup policies that map to their specific threat models. We also try to make it easy for users by offering the option to toggle policy options on and off within our policy catalog, or they can build their own using Open-Policy Agent (OPA) to comply with best practices, internal policies or regulatory requirements.
Blocking: The next step would be transitioning from simply monitoring software downloads to blocking. This means taking the acceptable use guidelines an organization might use to determine which packages are fit for use, whether that includes license concerns, malicious software, or other issues, and implementing technical controls to prevent it from being used entirely. This can be done at a variety of places, such as within the CI/CD process, on the software developer's system (through the use of commodity CLI tools and IDE extensions, pre-commit hooks, etc.), in front of artifact repositories such as Artifactory or Sonatype Nexus or elsewhere.
Third-Party Risk Management: Beyond first-party consumption of open source, the same concerns apply to third-party SaaS and delivered software. In these cases, a third-party software bill of materials (SBOM) should be managed appropriately to identify vulnerability, compliance, and malicious software risks, and additionally, should be monitored to ensure that security teams are alerted if issues arise in the future. Not only can Phylum facilitate seamless collaboration with third-party contributors, but its suite of integrations and its extension framework enable SBOM data to be collected and catalogued without making operational changes to the development workflow. This gives stakeholders visibility into software supply chain security posture and associated risks, and enables continuous monitoring of impacted artifacts to flag new risks, threats, or other issues as they emerge. Phylum also helps automate guidance for the remediation of issues surfacing from a given SBOM, which can quickly streamline the process of addressing and remediating identified issues.
Governance: Once monitoring, policy, blocking and third-party controls are in place, governance is naturally achievable. This has never been more relevant for organizations - in a world of expanding risks, liability, and compliance requirements, achieving governance is the only path to managing against the types of issues SBOMs introduce, and applying automation is the only way to achieve governance at a price point that is affordable for all.
