Add SLSA + SBOM blogpost

Signed-off-by: Brandon Lum <lumjjb@gmail.com>

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
+---
+
+<!-- markdownlint-disable-next-line MD033 -->
+<center>
+<img src="https://user-images.githubusercontent.com/3060102/165816019-184fdd3d-1fa6-4d33-933f-49c1642006c0.png"
+width="300" /></center>
+
+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.