Secure Supply Chain Consumption Framework (S2C2F) and Phylum
As threat actors increasingly execute more attacks via the open-source software ecosystem, clear gaps have emerged in modern application security. While organizations have adopted technologies to address threats from critical vulnerabilities - software flaws that could leave runtime applications exposed to exploitation - there’s very little attention being paid to directed attacks targeting developers - open-source packages with malicious code that triggers on install to steal developer keys and secrets. Many organizations have tools like software composition analysis (SCA), security analytics, endpoint protections and private repositories in place, but nothing that actually blocks software supply chain attacks.
--bookmeeting--
While some tools are certainly capable of identifying vulnerabilities in software dependencies before they arrive in production, these sorts of issues are not the same as the new, directed attacks that have continued to escalate year-over-year. Software supply chain attacks often target not just production systems, but software developers and CI/CD infrastructure - areas that are often totally undefended, but hold high-value credentials, permissions, and accesses.
The Secure Supply Chain Consumption Framework (S2C2F) is a consumption-focused framework that uses a threat-based, risk-reduction approach to mitigate real-world threats in Open Source Software (OSS). The S2C2F addresses popular gaps in today’s appsec programs by adding additional maturity levels around OSS consumption and management that go well beyond vulnerability management, triage, and remediation. It also calls for both governance programs, enabling the proactive management of software being consumed, and defense against malicious code being leveraged in the development process.
Phylum’s primary focus is around emerging OSS Supply Chain Threats, particularly those spaces uncovered by existing SCA solutions, and cover a broad spectrum of upstream risks and directed attacks. As these continue to escalate, we are now faced with a paradigm shift: vulnerability management has historically been the primary focus for most appsec programs, and malicious code was more thought of as an endpoint problem. However, the volume of new overtly malicious activities in the OSS ecosystem has grown to such a degree that it utterly dominates the new emerging application security issues, accounting for hundreds of thousands of findings per quarter, and a small fraction are now covered by the accidental, inherited vulnerabilities that may be mitigated against by legacy Software Composition Analysis-style solutions. Some examples of these overtly malicious behaviors include publishing malicious software libraries, or compromising components utilized in the build or engineering processes, attacks against package authors or maintainers, or availability issues that may result from package removal.
Two of the three major goals outlined in the framework seek to address those core issues:
- The creation of a strong OSS governance program
- The ability to block the consumption of malicious OSS
This framework culminates in four levels of maturity:
- L1: Minimum OSS Governance - This level is essentially achieved through the use of an SCA product, and the manual application of software updates as issues are identified.
- L2: Secure Consumption & MTTR (Mean Time To Remediation) improvement - This level goes a bit beyond just incorporating an SCA solution, and requires some additional controls, processes, & policy - including the use of a private registry or mechanism to ensure that the package leveraged is inline with organizational requirements.
- L3: Malware Defense & Zero Day Protection - This level falls firmly within Phylum’s wheelhouse - providing protection against emerging threats and issues, and enabling defense and validation before packages are downloaded.
- L4: Advanced Threat Defense - While the positioning in the framework is more aspirational, Phylum provides the advanced SBOM validation and management needed to set a foundation for how SBOMs will evolve.
While other tools mostly cover L1 and parts of L2, we built Phylum to focus primarily on the malware defense and aspirational categories of the framework.
| Practice: Ingest it | |||||
|---|---|---|---|---|---|
| Maturity Level | Title | Best Practice | How can this be bypassed? | Technical solutions | How Phylum improves security posture |
| L1 | Use package managers trusted by your organization | Organizations should set guidelines and educate developers on preferred repositories | There is no full-proof way to enforce developer behavior; while administrative controls & policies can set the groundwork for compliance, existing technical controls are insufficient to ensure across-the-board enforcement. | No technical solution solves this holistically, a combination of administrative & technical controls are required. | Phylum recommends leveraging a sandbox solution for installing packages (such as Phylum’s Birdcage) to ensure that if a compromised artifact is utilized, that additional controls are in place to protect against credential theft, etc. |
| L1 | Use an OSS Binary Repository manager solution | Organizations should leverage package caching repository managers to enable some level of software governance for builds. | It is difficult for modern organizations to ensure that developers are exclusively installing software from these sources (and in some cases, may not be possible at all). | Harbor, JFrog Artifactory, etc. | Phylum should be leveraged to scan packages that are loaded into a repository manager to identify malicious software, supply chain risks, and possible attack vectors, as these solutions provide no inherent protection against these types of attacks. |
| L3 | Have a deny list capability to block known malicious OSS from being consumed | Organizations should leverage a software supply chain security solution that enabled protection against known-malicious software packages. | The ability for such a solution to work is highly dependent upon how it is implemented. Additionally, in order to be effective, it will need to be able to examine transitive dependencies, and also to get updates in near-real-time. | Phylum | Phylum’s policy capabilities enable the automated enforcement of defined “acceptable use” for OSS. |
| L3 | Mirror a copy of OSS source code to an internal location | Organizations must be able to capture/download source code from third-party OSS packages | The ability to accomplish this is entirely dictated by an organization’s ability to stay in-step with the software artifacts developers are leveraging, and that are being utilized in builds. | Phylum | Phylum maintains a copy of all ingested packages, enabling later review. |
| Practice: Scan it | |||||
|---|---|---|---|---|---|
| Maturity Level | Title | Best Practice | How can this be bypassed? | Technical solutions | How Phylum improves security posture |
| L1 | Scan OSS for known vulnerabilities (CVEs, etc.) | Leverage a product that is able to scan for known vulnerabilities in the CI/CD pipeline. | Development best-practices must be adhered to - including the use of CI pipelines with defined stages. The ability for developers to bypass these stages would enable the controls to be effectively bypassed. | Phylum, SCA Products | Phylum ingests commodity feeds (e.g., vulnerabilities) and can provide a list of known issues in consumed OSS. |
| L1 | Scan OSS for licenses | Leverage a product that is able to scan for and manage software licenses in the CI/CD pipeline. | Development best-practices must be adhered to - including the use of CI pipelines with defined stages. The ability for developers to bypass these stages would enable the controls to be effectively bypassed. | Phylum, SCA Products | Phylum scans packages for licenses, and has some ML-enabled capabilities to identify conflicting licenses. |
| L2 | Scan OSS to determine if it is EOL | Leverage a product to scan OSS products to ensure that none have passed EOL in the CI/CD pipeline. | Development best-practices must be adhered to - including the use of CI pipelines with defined stages. The ability for developers to bypass these stages would enable the controls to be effectively bypassed. | Phylum | Phylum provides health and activity information for OSS packages, including whether or not a package is abandoned or archived. |
| L3 | Scan OSS for malware | Leverage a product to scan OSS packages utilized for malware in the CI/CD pipeline. | Development best-practices must be adhered to - including the use of CI pipelines with defined stages. The ability for developers to bypass these stages would enable the controls to be effectively bypassed. | Phylum | Phylum continuously monitors supported OSS ecosystems to flag malicious packages and behaviors. |
| L3 | Perform proactive security review of OSS | Leverage a product capable of proactive OSS security posture analysis in the CI/CD process. | Development best-practices must be adhered to - including the use of CI pipelines with defined stages. The ability for developers to bypass these stages would enable the controls to be effectively bypassed. | Phylum | Phylum identifies additional upstream security issues in OSS packages, include supply chain vulnerabilities. |
| Practice: Inventory it | |||||
|---|---|---|---|---|---|
| Maturity Level | Title | Best Practice | How can this be bypassed? | Technical solutions | How Phylum improves security posture |
| L1 | Maintain an automated inventory of OSS used in development | Leverage a product throughout the development process that can maintain an inventory of the software leveraged in development. | Phylum provides the most comprehensive solution here, as it is able to capture all packages throughout the development process. Other products, including most SCA solutions, can provide a partial answer to this problem, at a minimum giving some feedback about what is being leveraged in the CI/CD pipeline. The big challenge is ensuring that this record is accurate and that it is comprehensive - e.g., insights in the CI/CD pipeline may miss packages used earlier, and also may not accurately reflect the packages deployed to production. | Phylum, SCA products (Partial) | Phylum scans on CI/CD builds and proxy package installations automatically catalogue OSS utilized. |
| L2 | Have an OSS Incident Response Plan | A documented plan should be generated by security to ensure that there is a clear strategy for what should happen in the event of an OSS-derived incident. This can happen in a variety of places, from developer workstations, CI/CD infrastructure, and also production. | An effective plan will need to address the key places that are often blind spots for the security team in organizations: this includes developer workstations, CI/CD pipelines, and similar. | No technical solution exists to cover this gap holistically. Some technical products (such as Phylum) can provide things that will be necessary to action an incident response plan, but are not a substitute for having a plan in place. | Phylum can help address several required components in order for an incident response plan to operate effectively, including: The ability to procure a copy of installed packages, and an active inventory of packages installed throughout the SDLC. |
| Practice: Update it | |||||
|---|---|---|---|---|---|
| Maturity Level | Title | Best Practice | How can this be bypassed? | Technical solutions | How Phylum improves security posture |
| L1 | Update vulnerable OSS manually | Once vulnerabilities are identified, there should be a process to ensure that the underlying OSS packages are continually updated. | OSS and vulnerability identification must be properly established in order to ensure that issues are rapidly identified and queued for remediation. | No technical solution will totally cover this gap, as manual updates imply the use of administrative, rather than technical controls. | Phylum can assist in identifying vulnerabilities & prioritizing which should be updated. |
| L2 | Enable automated OSS updates | OSS software should be updated as new releases emerge, while ensuring appropriate governance and risk management controls are applied. | The biggest challenge with achieving this level of maturity is ensuring that proper engineering best practices are adhered to (in order to ensure that downstream breakages are avoided), and that there is a clear process and path to allow those updates to happen safely & securely. | No single technical solution will be able to enable this to happen end-to-end in a secure fashion. Governance & guardrails need to be added to ensure that updates do not contain supply chain issues or malicious code, and engineering best practices (including adequate test coverage & build automation) must exist in order to ensure that the change management process can support these sorts of updates. | Phylum can assist in providing codified policy to ensure that “acceptable use” is enforced throughout the SDLC. |
| L2 | Display OSS vulnerabilities as comments in PRs | Organizations must ensure that scanning solutions in CI/CD can appropriately comment on engineer-proposed changes with vulnerabilities prior to their incorporation into feature branches or production builds. | Development best-practices must be adhered to - including the use of CI pipelines with defined stages. The ability for developers to bypass these stages would enable the controls to be effectively bypassed. | Phylum, some SCA products | Phylum is able to add comments with software supply chain security findings (to include vulnerabilities) inline on pull or merge requests. |
| Practice: Audit it | |||||
|---|---|---|---|---|---|
| Maturity Level | Title | Best Practice | How can this be bypassed? | Technical solutions | How Phylum improves security posture |
| L3 | Verify the provenance of your OSS | Organizations need to be able to get an understanding of the provenance of the software they are leveraging from open source ecosystems. This includes information about the build & development processes applied during the production of said software. | Software developers installing packages without capturing additional data will inherently bypass this sort of control. | Phylum | Phylum collects development history and a large amount of additional data about the processes and people involved in the production of OSS packages, as well as both file hashes and statistical techniques to match artifacts up with their original sources. |
| L2 | Audit that developers are consuming OSS through the approved ingestion method | Organizations need to ensure that developers are leveraging appropriate tools to install packages safely, are not leveraging untrusted repositories, and that user education is applied to ensure compliance. | Software developers may inadvertently bypass controls if not VPNed during the development process, or if settings are misconfigured. Additionally, it is possible for them to bypass these controls by manual efforts. | No technical solution will be able to cover this holistically, but a combination of technical controls (including Phylum) can be leveraged to ensure compliance. | Phylum can be leveraged as part of the package installation process to ensure the security of OSS being utilized. |
| L2 | Validate integrity of the OSS that you consume into your build | Organizations should capture hashes for utilized OSS, and compare them to expected values. | Development best-practices must be adhered to - including the use of CI pipelines with defined stages. The ability for developers to bypass these stages would enable the controls to be effectively bypassed. Lack of adherence to these processes will lead to a lack of visibility in what software is being leveraged in the build processes. | Phylum can provide a partial solution in conjunction with other products or build scripts to provide running checks of package hashes throughout the development process. | Phylum provides hashes for scanned packages to enable integrity verification. |
| L4 | Validate SBOMs of OSS that you consume into your build | Organizations should set policy to ensure that the SBOMs of consumed OSS do not contain issues, and that they match with the produced deliverables. | Development best-practices must be adhered to - including the use of CI pipelines with defined stages. The ability for developers to bypass these stages would enable the controls to be effectively bypassed. Lack of adherence to these processes will lead to a lack of visibility in what software is being leveraged in the build processes. | No technical solution exists to provide a holistic solution here. Phylum can provide some capability to enforce policy, but no products provide a full solution to validate that the SBOM matches delivered software artifacts. | Phylum can ingest and process SBOMs, enforcing policy and providing insights into the supply chain risks of consumed OSS components. |
| Practice: Enforce it | |||||
|---|---|---|---|---|---|
| Maturity Level | Title | Best Practice | How can this be bypassed? | Technical solutions | How Phylum improves security posture |
| L2 | Securely configure your package source files (i.e. nuget.config, .npmrc, pip.conf, pom.xml, etc.) | It is highly recommended to ensure that software developers are locking software dependencies during development, to ensure that the software libraries used will be deterministic. | Developers should be required to lock package dependencies during the development process. The exact steps to do this vary from tech stack to tech stack. | No technical solution exists (outside of the package managers themselves) to fully cover this control. Developers need to be trained to ensure that they understand the need for generating lock files, and that these best practices are adhered to throughout the process. Not only will this prevent inadvertent risk exposures, but it will also greatly improve the performance of OSS scanning tools & help reduce false positives. | N/A |
| L3 | Enforce usage of a curated OSS feed that enhances the trust of your OSS | Organizations should keep track of emerging threats in the OSS ecosystems. | N/A | Phylum | Phylum provides threat feed data and enforces defined policy at developer workstations and within the context of CI/CD. |
