Add SLSA + SBOM blogpost #376
Conversation
✅ Deploy Preview for slsa ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
lumjjb
force-pushed
the
sbom-blogpost
branch
2 times, most recently
from
910bf5d to
b7758f1
Compare
|
Great post! |
docs/_posts/2022-04-28-slsa-sbom.md
Outdated
| 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 |
There was a problem hiding this comment.
I would cite it as the minimum elements for an SBOM don't require this information thus meaning you can't rely on it to include build information https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf
I state this because different SBOM tools and specifications CAN include build information but don't need to leading to you not being able to rely on it to contain that information
There was a problem hiding this comment.
Yup - I see where you're coming from. Yea I think from the current functional standpoint as well, most tooling doesn't do this, or at least most people are not thinking about it. Maybe, we can phrase it as:
"Today, SBOMs, don't include ..."
I am a bit hesitant to quote the minimum elements. I am afraid of going down the road of discussion of sbom minimum standards is going to be what's implemented, because today, for the most part we are doing much better than it. My view on the minimum elements is more for vendors of proprietary software that are very reluctant to put out information, that this is the absolute minimum to meet compliance.
docs/_posts/2022-04-28-slsa-sbom.md
Outdated
| 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 |
There was a problem hiding this comment.
I would word it a bit less concretely. It provides evidence allowing an end user to trust. I worry that it gives the wrong impression. I wouldn't say SLSA itself secures the step.
I like the wording below that the guidelines help providence confidence that you are protected against certain kinds of attacks.
There was a problem hiding this comment.
I would word it a bit less concretely. It provides evidence allowing an end user to trust. I worry that it gives the wrong impression. I wouldn't say SLSA itself secures the step.
Hmm, I'm trying to tease this apart between SLSA as the provenance document and as the framework. I think we were trying to encompass some of the broader goals of the SLSA framework around securing the build system, etc. - slsa4 hardening, etc. (i.e. the SSDF stuff).
Wondering how this can be worded to be clearer.
There was a problem hiding this comment.
How about "The SLSA framework provides this trust by providing guidelines and evidence for securing each step of the software production process..."
docs/_posts/2022-04-28-slsa-sbom.md
Outdated
| 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 |
There was a problem hiding this comment.
I would word it slightly differently to make sure that SLSA provides evidence of protections against certain attacks.
There was a problem hiding this comment.
Hmm, what do you think about taking the phrasing from https://slsa.dev/spec/v0.1/threats
to say "These guidelines mitigate against the risk"
There was a problem hiding this comment.
Good point. I think we might just want to highlight that it is both. That SLSA compared to alternatives provides attestations that you are performing those practices.
|
One thing I've done that I think is complementary and might prove to be valuable is I use SLSA attestations to provide provenance metadata for how my SBOM was built in the first place. So I would have SLSA attestation for my actual software and another one for how I generated my SBOM. I think it's valuable because it helps provide additional evidence as to what tool generated the SBOM as well as what the SBOM used as its "materials" for generation, e.g. did it build the SBOM from a container image, from a go mod file, from a binary analysis of the compiled software, etc. |
docs/_posts/2022-04-29-slsa-sbom.md
Outdated
|
|
||
| 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, |
There was a problem hiding this comment.
One thing to note, SBOMS, as defined by consensus through NTIA, are incompatible with reproducible builds. This should be addressed.
There was a problem hiding this comment.
Hmm, can you elaborate a bit more on this - it does sound like a much broader discussion. Think this is a good idea to bring up during the next SLSA call if there's room in the agenda.
I think from a content delivery perspective, the discussion around reproducible builds + SBOM deserves its own story and perhaps a different audience.
There was a problem hiding this comment.
From the NTIA minimum elements:
Timestamp records when the data is assembled -- the point of the SBOM creation.
For every build, even if most artifacts are reproducible, the SBOM created during a build must have a different timestamp. There are many audit and assurance reasons for this requirement.
The data about software components can be collected at different stages in the software lifecycle, including from the software source, at build time, or after build through a binary analysis tool. Due to unique features of each of these stages, the SBOM may have some differences depending on when and where the data was created.
Timestamps are obviously tied to "when", however, a component's point-of-origin may vary depending on build tool configuration, DNS, or repository proxying and mirroring.
The consensus among NTIA participants is that SBOM must be a non-reproducible artifact. It can be repeatable. It can be predictable, but it will not conform to reproducable builds.
Signed-off-by: Brandon Lum <lumjjb@gmail.com>
SLSA + SBOM blogpost
Signed-off-by: Brandon Lum lumjjb@gmail.com