No because SBOMs are a hot mess and not standardized at all. They're "standardized" in the same sense as HL7 (ask someone in the healthcare industry, make sure to have some sedatives on hand first). A comprehensive SBOM for something like Chromium is many dozens of MBs compressed (I forget exactly, but it's patently ridiculous). Also SBOMs should be build artifacts, so them (also) being build inputs is problematic.

▲

zvr 4 hours ago | parent | next [-]

The format is standardized, to the highest level possible: ISO/IEC 5962:2021 defines SPDX v2.2.1. The actual standard text is available for free at the ISO website (and other places, like spdx.org).

The newer version, SPDX v3.0, will become ISO/IEC 5962:2026, and work is already underway for further versions.

What is not standardized at all are the integration of processes for producing/consuming/maintaining SBOMs in the software development world.

▲

Ferret7446 2 hours ago | parent [-]

Oh sure, the format is standardized. The semantics aren't however, in any practical sense. What happens when you vendor/patch/fork a dependency? What happens to vulnerabilities that are not in code paths not used by your software, or only under certain flags?

HTML is standardized too, how many documents do you think use the p or i tags properly? Heck, how many documents do you think are HTML5 compliant, even ignoring the semantics?

(And even if it were, it is still much too bulky of a tool to replace lockfiles. Having to add a kilobyte to your file every time a bunch of new vulnerabilities get reported in your deps recursively sounds like a great addition to your commit history.)

	▲	zvr 2 hours ago \| parent [-]
		> What happens when you vendor/patch/fork a dependency? You change the supplier property (and most probably the version). This is how you distinguish between OpenSSL 3.1.4 from OpenSSL project and OpenSSL 3.5.4-1~deb13u1 from Debian project. > What happens to vulnerabilities that are not in code paths not used by your software, or only under certain flags? You record this information in the SBOM, using structures like "this software has this vulnerability reported, but it's not affected by it in this case" (see, for example, VexNotAffectedVulnAssessmentRelationship in SPDXv3). I completely agree that its purpose is not to replace lockfiles.

▲

mrweasel 3 hours ago | parent | prev | next [-]

This might not be part of HL7, but I recall working on software for a healthcare product, and simply having a list of components want not enough. Each component had to be accompanied by a risk assessment. It's a really clever way of keeping your dependency count low.

▲

larusso 5 hours ago | parent | prev | next [-]

This year I had to create SBOM files for our Unity projects. Of course there is nothing. For all that don’t know: UPM (Unity Package Manager) is a way to easily install packages in Unity. And as a side note, for whatever reason they decided to built on top of npm not nuget for the package infrastructure and metadata format. Anyways: Most packages we use are simply wrapper packages for other packages. Like a wrapper for a .NET library. There is no clear dependency try but based on the package ID I’m able to see them. So I wrote the SBOM files based manually with an SBOM library and added pedigree statements to the original nuget package being wrapped. Idea was if the nuget package has a security issue the UPM package also gets flagged. Showed that one of the security engineers of the software we use. As wer was cool but that is not a standard. There is also no official package specification for UPM (I also made that up as part of the purl) So yes SBOM is a standard with a huge array of ways to declare said information. And it seems most companies consuming the files don’t built general parsers but expect specific formats for X.

▲

isodev 4 hours ago | parent | prev [-]

Oh dear, HL7, I may be suffering from a form of PTSD… my therapist has heard about this “standard” at length.

But I think SBOMs are better structured. I also feel that if package managers refocus their efforts on that, the standard and its implementations can be evolved. It’s the whole perk of using standards. I think it would be a good thing