Comment by zingar 10 hours ago
In hearing the SBOM term for the first time from that article and the linked Wikipedia page. For the ignorant like me: what is it that SBOM is used for that lockfiles aren’t? Everything in the article is something that I’m used to seeing automated scanners using lockfiles for.
Is it just that the two are used by different communities? What is the SBOM community?
In many cases the lock files are for one part of the stack. Like npm and composer and $other_lang thing. sBOM is when all are together and version-pinned. (I've over simplified).
Edit: for my domain we have Alpine, Debian, PHP, JS, Go in the stack. So our BOM has all that (and dependencies). It's a big list. Some is just necessary base (Alpine, Debian) but some are core stack and other are edge (dependency on python lib when we're mostly Rust (or something)).
Mirror/Vendor all these things for supply-chain integrity (it's what they tell me)
SBOMs are a solution intended to help solve a couple of problems:
1) help identify and remediate software that has been built with vulnerable packages (think log4j).
2) help protect against supply chain compromise as the SBOM contains hashes that allow packages to be verified
https://www.ntia.gov/sites/default/files/publications/sbom_m...
Depending on who you ask an SBOM might not need a hash. NTIA only recommend a hash.
Thats an important point. You can't tell if the software you use is vulnerable to something like log4j without the vendor telling you, or doing lots of manual investigation.
SBOMs are supposed to help with software composition analysis. Basically, you as an enterprise have an inventory of what software you use, and their SBOMs (i.e. dependencies). I can then use this to automatically check which software is impacted by severe vulnerabilities when they are announced.
Think of the SBOM as a "table of contents" for the software you are receiving. Another metaphors that has been used is the "nutrition label" that you get in all packaged food.
So, it's a list of the "software components" that are inside a piece of software. And then you add metadata about each of these components: what's its name? its version? its hash? Up to now we're in lockfile territory.
But you want more information: what is the license? who supplied it? what is the security status? does it have known CVEs? are they relevant?
And then you go to special cases, like "AI" software: oh, it's a model? how was it trained? on which data? Or like software that has to be certified, to be used when safety is important.
An SBOM is capable of providing all this information. Take a look at the different parts that SPDX provides, and it's an ever expanding area.