Unverified Commit b4ad95e4 authored by Abhishek Arya's avatar Abhishek Arya Committed by GitHub
Browse files

Merge pull request #376 from lumjjb/sbom-blogpost

Add SLSA + SBOM blogpost
parents 2a5d5261 8f69a7fb
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 -->
<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
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
and [Codecov](https://about.codecov.io/security-update/);
- There’s no well-established ecosystem to easily distribute and verify SBOM
- 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)](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.
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
- Uploaded artifacts that were not built by a CI/CD system (by marking
artifacts with a factory “stamp” that verifies which build service created
- 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 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.
![SBOM and SLSA in supply
*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. Another SBOM
standard, [CycloneDX](https://cyclonedx.org/), 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.
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment