If you’re trying to build and run secure software today, you’ve probably heard of an SBOM, or a Software Bill of Materials. Acting as an “ingredient” label for software, SBOMs are documents that provide a nested list of packages and components included in a piece of software, and are supported by the White House in the 2021 Executive Order on Improving Cybersecurity as one aspect of a secure software supply chain.
SBOMs are well positioned to help consumers better manage the risks of the software they consume and to respond more easily to vulnerabilities. There’s currently a lot of work being put into SBOMs to pave the way for widespread adoption, and as with any industry-changing effort of this size there are difficult problems to solve along the way. For example:
- SBOMs currently don’t include or require enough information to help users respond to build tampering and attacks like Solarwinds and Codecov;
- There’s no well-established ecosystem to easily distribute and verify SBOM documents;
- The most common method of generating SBOMs using only audit tools after the software’s creation can result in less accurate SBOMs.
We believe that SLSA (Supply-chain Levels for Software Artifacts), a framework for creating a secure software supply chain, can address each of these potential areas for improvement when used in conjunction with SBOMs. This blog post explains the strengths of SBOMs and SLSA and how they fundamentally differ, and shows how SLSA principles can both support the generation of high-quality SBOMs and help consumers respond to supply chain attacks.
SLSA vs. SBOM
If an SBOM is like an ingredient list on a food product in the grocery store, then SLSA can be thought of as all the food safety handling guidelines that make that ingredient list credible. From standards for clean factory environments so contaminants aren’t introduced in packaging plants, to the requirement for tamper-proof seals on lids that ensure nobody changes the contents of items sitting on grocery store shelves, the entire food safety framework ensures that consumers can trust that the ingredient list matches what’s actually in the package they buy.
Likewise, the SLSA framework provides this trust by providing guidelines and evidence for securing each step of the software production process so that the final SBOM attached to a package can be considered credible. As a framework, SLSA lays out practices and guidelines to help you securely build and verify the integrity of software. These guidelines help mitigate against the risk of:
- Code modification (by adding a tamper-evident “seal” to code after source control);
- Uploaded artifacts that were not built by a CI/CD system (by marking artifacts with a factory “stamp” that verifies which build service created it);
- Threats against the build system (by providing “manufacturing facility” best practices for build system services).
SBOM and SLSA are helpful in different situations. In the same way that an ingredient list is useful if there’s a product recall so that affected items can be pulled from the store shelves, an SBOM helps answer the question: “Am I affected by log4j (or the next big vulnerability)?” SLSA, on the other hand, answers the broader question of: “Can I trust that this software was created using safe handling practices at each step of the production process?” Crucially, SLSA also helps answer the question: “Is my software ready to meet the requirements of the Secure Software Development Framework?”
SLSA and SBOM
SBOM and SLSA are complementary, and following certain SLSA principles can make it easier to generate SBOMs. In particular, a major SLSA principle is the need to generate tamper-proof provenance data—that is, metadata that attests to who performed the release process for an artifact, the materials used in production, and whether the artifact was protected from tampering. Since SBOMs hinge on accuracy, completeness, and trust, having SLSA provenance for an artifact improves the quality and integrity of its SBOM.
Accuracy and Completeness
Many tools’ current approach to creating an SBOM rely on guessing or using heuristics and information from an end product to generate an ingredient list after the fact. This approach has drawbacks, though, since if you try to generate an SBOM by scanning compiled artifacts, you may miss things like statically linked binaries that don’t include their dependency metadata. Similarly, generating an SBOM by making guesses based on file hashes will likely yield false positives for vulnerabilities that you’re not actually affected by, reducing trust in the overall vulnerability response process.
On the other hand, generating an SBOM with the additional help of SLSA attestations leads to a much more accurate SBOM. By using SLSA provenance and metadata generated during the build, you have high-fidelity information about what went into the artifact, including better dependency information so that you don’t have to make guesses after the fact.
Traditional sources of SBOM information are shown in green; using SLSA allows inclusion of build information in SBOMs as well. (Red triangles mark threats to the supply chain that are addressed by SLSA.)
SLSA’s accurate build metadata also helps provide tangible knowledge of how the software was built: build metadata specifies both the input materials and the factory that produced the artifact. If faulty goods are caused by poor quality control or machinery (such as compromised build systems or bugs in tools like compilers), an SBOM with this additional data will be more complete and help users respond to a supply chain compromise.
Trust
An SBOM generated from SLSA provenance data boosts users’ confidence in the accuracy of the SBOM, since they know it was created from high-fidelity build metadata: the ingredient list was generated by observing what was added while the product was made. The SLSA provenance also tells the user that the metadata comes from a verifiable build, and that the provenance data itself was captured and signed in a secure way. Referencing these provenance documents in SBOMs provides an additional level of assurance about the secure process used to produce the software.
The lessons learned by the SLSA community in creating this integrity could be useful to the Software Package Data Exchange (SPDX), an open standard for representation of SBOMs. The SPDX SBOM community is currently coming together to determine processes for integrity and signing of SBOM data. On top of that, it has kicked off its Canonicalization Committee to write a specification for a canonical serialization format for SPDX 3.0 data, which will be important for specifying how to verify signed documents. Another SBOM standard, CycloneDX, is also tackling this problem with its features around its authenticity, and provenance use cases. We believe that the SBOM community would benefit from drawing on the same tooling and practices as used for SLSA provenance: Sigstore (for OIDC-based ephemeral signing and transparency logs) and in-toto (for metadata format). These tools help to solve the problem of storing and distributing the metadata documents that need to accompany artifacts, and would help build the trust that users need in SBOMs.
Simplicity
Adopting SLSA concepts could also simplify the tooling updates needed to generate SBOMs. Enabling SBOM for all software being produced is a difficult problem since it requires integration with all tooling that produces software, such as compilers, packagers and builders. Many of these tools are maintained by volunteer open source communities who would need to update their tools to not only describe their process in an SBOM, but also retrieve and relay SBOMs of all their inputs.
Using SLSA’s approach to keep track of build metadata, though, means a tool would need only to generate a partial SBOM describing its own process to produce the software. One could then use the SLSA build metadata as “glue” to combine the appropriate partial SBOMs (“composable” SBOMs) into a complete and accurate SBOM for any given software. This would remove an enormous burden from build tool implementers, driving faster adoption of SBOM.
Collaboration
As both SLSA and SBOM are adopted more widely, they face many of the same challenges: scaling, tooling for widespread adoption across multiple ecosystems, and a desire to comply with executive order requirements. The SLSA and SBOM communities should join forces to work on these shared challenges, saving duplicate effort and time. Sharing resources and ideas can only lead to better solutions for both communities.
SLSA and SBOM—both the communities and the security concepts—will become stronger by working synergistically than either approach or community could in isolation. We look forward to seeing the results of these two communities coming together to achieve better vulnerability management and a safer supply chain for all software users.