Secure the software supply chain
The security of a workload depends on the security of all the components in that workload. An attacker who compromises one vulnerable component of a workload can often take over the whole workload (and often many others in the organization using lateral traversal techniques).
Today, the vast majority of software projects are built using third-party components (both commercial and open source). When selecting third-party components to use, it’s important to understand the impact that a security vulnerability in them could have to the security of the larger system into which they are integrated and you should always be more selective when using high-risk components, and consider a thorough analysis before using them. There are a myriad of ways that developers consume OSS today: git clone, wget, copy & pasted source, checking-in the binary into the repo, direct from public package managers, repackaging the OSS into a .zip, curl, apt-get, git submodule, and more. Securing the OSS supply chain in any organization is going to be near impossible if developer teams don’t follow a uniform process for consuming OSS. Enforcing an effective secure OSS supply chain strategy necessitates standardizing your OSS consumption process across the various developer teams throughout your organization, so all developers consume OSS using governed workflows.
5.1 Establish a secure open source software ingestion process - The Secure Supply Chain Consumption Framework (S2C2F) is a security assurance and risk reduction process that is focused on securing how developers consume open source software.
- Microsoft: OSS Secure Supply Chain Framework (microsoft.com)
- GitHub Docs: Securing your end-to-end supply chain
- GitHub: GitHub Advanced Security
5.2 Understand dependencies in your environment - Many software projects depend on open-source software projects, and many of these have dependencies on other open source projects. It’s essential to inventory use of open source, including dependencies to be able to update these if a vulnerability is discovered.
- GitHub Docs: Securing your end-to-end supply chain
- GitHub Docs: About the dependency graph
- GitHub Docs: About dependency review
- GitHub Docs: About Dependabot alerts
- GitHub Docs: Configuring Dependabot security updates
5.3 Produce software bill of materials (SBOM) - SBOMs contribute software transparency and integrity. An SBOM is a machine-readable document that lists all of the components, including open source components used to create a product and helps better inventory software and therefore helps organizations to understand license and vulnerability risk. SBOMs also contain package and file checksums to help validate hashes, which is useful when signatures aren’t provided by other means.
- GitHub: SBOM Tool
- Microsoft DevBlogs: Announcement: Open Sourcing of SBOM Tool
5.4 Signing and attesting artifacts – A Core aspect of software integrity is signing and validating its components. This applies to SBOMs just as much as artifacts created by tools integrated into your lifecycle, Artifact attestations establish a verifiable trail, enabling you to trace the integrity and prove the provenance of the artifact throughout the lifecycle.
- GitHub: Microsoft COSE Sign tool
- GitHub: Github Artifact Attestation using Sigstore