Hacker News Reader

Comment by Ferret7446 | Hacker News Reader

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.

View on HN

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.

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.)

> 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.

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.

How does that work for high complexity dependencies like compression or cryptography? If HL7 wouldn’t catch xzutils is it really adding anything?

In the case of something like xzutils, you would perhaps have listed it as low risk, as it's shipped with your OS. After the backdoor incident, you'd have adjusted the risk assessment, and utilities like it. Once you hit a certain level you might question if you truly need the entire xzutils package or if you could replace it.

In other cases you might have a library you depend on, but it's no longer maintained, so it might score really high on risk, meaning that you should probably address that dependency in your next development cycle.

So the SBOM and risk assessment wouldn't necessarily catch vulnerabilities, but it makes it simple to check if you're affect and generally help you manage/reduce your attack surface.

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.

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

Reply on news.ycombinator.com