Secure Software Supply Chain Framework Practices
These practices are the high-level principles to secure an Open Source Software Supply Chain. The practices are solution-agnostic and can be applied to many scenarios and environments. A detailed implementation of these practices with recommended tools are described in our maturity model based implementation guide.
Our framework splits each practice into requirements, and each requirement maps to a specific maturity model level. This enables your organization to implement the framework and secure your Open Source Software Supply Chain in an incremental fashion.
Ingest
Level 1, Level 2
Saving a local copy of the OSS (Open Source Software) artifact helps mitigate against availability risks of the upstream package managers, and also protects against left-pad incidents – enabling developers to continue to build even if upstream resources are unavailable. This can be done by adopting an integrated package caching solution into your CI/CD infrastructure.
Level 3
Mirroring external source code repositories to an internal location is useful for many reasons, including Business Continuity and Disaster Recovery (BCDR) purposes, proactive security scans to look for backdoors and zero-day vulnerabilities, and contributing fixes back upstream.
Scan for vulnerabilities and malware
Level 1
It is recommended to scan for both known vulnerabilities (i.e. CVEs, GitHub Advisories, etc.) and licenses. For known vulnerabilities, choosing a tool that gets vulnerabilities from more places than just CVEs is important to ensure that you are being informed from across multiple vulnerability sources.
Level 2
For security purposes, no organization should take a dependency on software that is no longer receiving updates, so it is important to scan OSS to determine if it is end of life.
Level 3
There has been a rise in malicious OSS packages over the years. It is critical that OSS be scanned for malware prior to consumption. In addition, without doing proactive security analysis to look for zero-day vulnerabilities, there would be entire threat categories that would go unmitigated, such as back-doors.
Inventory
Level 1, Level 2
Establishing an inventory of all developer OSS dependencies is critical when responding to an incident. If a malicious component ever gets ingested, it needs to be deleted from the developer’s desktop, the package caching solution, and the software/service that in production that consumed the package. Knowing which projects are using which OSS components and their versions across your enterprise is vital toward supporting rapid Incident Response.
Update
Level 1, Level 2
Using tools that improve your mean time to remediate (MTTR) OSS vulnerabilities is required.
Audit provenance and integrity
Level 3, Level 4
Verify the provenance of all OSS components to ensure they come through the official supply chain, and hash validate each component to ensure that no man-in-the-middle attack altered their integrity since they had been consumed from the public package manager.
Enforce OSS consumption meets security policy
Level 2
Securing the configuration of how build pipelines consume OSS components is important to ensure there is determinism to protect against race conditions and dependency confusion threats.
Level 3
Enforcing teams to only consume packages from a curated feed enhances the trust of your OSS. Curated feeds enable you to scan for malware, validate metadata about the component, and enforce an allow/deny list; these enforce secure consumption of OSS packages within your organization overall.
Rebuild
Level 4
Prior to Level 4, we have assumed that we took our inputs at the beginning of the supply chain as-is: as the package, container, or other delivery vehicle provided by the author. For key artifacts that are business-critical and for all artifacts that are inputs to High Value Assets, this assumption may not be sufficient. Hence, the next step to secure the supply chain is creating a chain of custody from the original source code for every artifact used to create a production service/release. Rebuilding from source in a trusted build environment removes the risk of consuming a package that may have been victim to a CCleaner/SolarWinds style build-time attack.
Fix it + Upstream
Level 4
In extreme cases, when a newly discovered zero-day vulnerability is so severe, you should be prepared to deploy a private fix as a temporary risk reduction activity while you confidentially coordinate with the upstream maintainer to issue a public fix.