An Intro to SBOMs(anonymoushash.vmbrasseur.com)
anonymoushash.vmbrasseur.com
An Intro to SBOMs
https://anonymoushash.vmbrasseur.com/2023/04/24/software-bill-of-materials-sbom
8 comments
You are starting more companies that are US Gov contractors invest in SBOM generation and software provenance solutions due to https://www.nist.gov/itl/executive-order-14028-improving-nat...
Are SBOMs a "thing" yet? Is anybody using SBOMs in their day to day workflows?
The current tooling for generating them seems to have matured, but tools for storing and managing an SBOM inventory seem non-existent with exception for OWASP Dependency-Track.
The current tooling for generating them seems to have matured, but tools for storing and managing an SBOM inventory seem non-existent with exception for OWASP Dependency-Track.
I use them. With the Microsoft SBOM tool[0] I generate a SBOM (which is unfortunately missing license information) and then feed them to Google OSV scanner to check for vulnerabilities. Not unlike Github Advanced Security does.
[0]: https://github.com/microsoft/sbom-tool [1]: https://github.com/google/osv-scanner
[0]: https://github.com/microsoft/sbom-tool [1]: https://github.com/google/osv-scanner
My company is using them in an internal artifact scanning tool that runs as part of CICD build pipelines. It's technically opt-in for dev teams but most have done so, and in my experience most engineers - while they may know "there's some scanning job running at build" - don't necessarily know that it's parsing SBOMs as part of its internal logic.
In other words: I suspect many engineers who are leveraging SBOMs may not know they are.
(To be clear, the SBOMs come from other tools - not directly from the teams - the main reason our internal tool ingests them is that it's much much less work than getting the same metadata from multiple language environments in different formats. We lean on other tooling that gets it for its own purposes & happens to also generate SBOMs, then we just have a single piece of logic to parse that & use it ourselves. We do also lean on Grype/Syft to augment that).
In other words: I suspect many engineers who are leveraging SBOMs may not know they are.
(To be clear, the SBOMs come from other tools - not directly from the teams - the main reason our internal tool ingests them is that it's much much less work than getting the same metadata from multiple language environments in different formats. We lean on other tooling that gets it for its own purposes & happens to also generate SBOMs, then we just have a single piece of logic to parse that & use it ourselves. We do also lean on Grype/Syft to augment that).
I despise the SPDX format, it feels like it was designed by the same people who created the current disaster that is NVD.
What would make the format better in your opinion?