diff --git a/docs/_posts/2022-04-28-slsa-sbom.md b/docs/_posts/2022-04-28-slsa-sbom.md new file mode 100644 index 000000000..4c2793cb9 --- /dev/null +++ b/docs/_posts/2022-04-28-slsa-sbom.md @@ -0,0 +1,175 @@ +--- +title: "SBOM + SLSA: Accelerating SBOM success with the help of SLSA" +author: "Brandon Lum, Isaac Hepworth, Meder Kydyraliev" +layout: post +--- + + +
+
+ +If you’re trying to build and run secure software today, you’ve probably heard +of an [SBOM, or a Software Bill of Materials](https://ntia.gov/SBOM). 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](https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-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 enough information to help users respond to + build tampering and attacks like + [Solarwinds](https://www.zdnet.com/article/microsoft-fireeye-confirm-solarwinds-supply-chain-attack/) + and [Codecov](https://about.codecov.io/security-update/); +- There’s no well-established ecosystem to easily distribute and verify SBOM + documents; +- The most common method of generating SBOMs using audit tools after the + software’s creation can result in less accurate SBOMs. + +We believe that [SLSA (Supply-chain Levels for Software +Artifacts)](http://slsa.dev/), 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. + +SLSA offers the same trust by 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 protect +against: + +- 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](https://www.cisecurity.org/log4j-zero-day-vulnerability-response) (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](https://csrc.nist.gov/Projects/ssdf)?” + +## 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 current approaches 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. + +![SBOM and SLSA in supply +chain](https://user-images.githubusercontent.com/3060102/165816534-653cc8dd-3ae9-4c75-ab14-47f376f9a32f.png) + +*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)](https://spdx.dev/), 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. **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.