[pipingdog]

The lack of consensus is on what an SBOM is for. Even the NIST recommendation which came out of Executive Order 14028 had little guidance on how to apply SBOM .

At any sort of scale, it isn't clear how an SBOM shipped with each package can be consumed to any great effect.

A central database of all dependencies, on which queries and analysis can be performed, however, can be very useful, and in a large software shop, I've seen it used to rapidly get a very real sense of the company's exposure to events like the Log4j debacle.

[eichin]

A Debian/Ubuntu status file is a good start (of course you need to dig further for build depends) and helpful enough for "provenance" that I've found it useful at a couple of startups to deploy code as debs packages specifically to be part of that graph - obviously not perfect, but often good enough to go automatically from CVE -> USM -> upstream package -> what part of our code cares about that - someone still has to think about the vulnerability, but it reduces a lot of obvious noise and helps drill down quicker.

[candiddevmike]

Additionally, from what I can tell a lot of SBOM tooling is manual/honor based, and the automated ones don't recurse dependencies well.

Trusting the current state of SBOMs seems sketchy

[Veserv]

A SBOM is for the producer at this time, not the consumer. It is about requiring the producers to at least try to figure out what they put into your soup. The sort of engineering 101 processes that almost all software development lacks. It is about making it possible, though not necessarily easy, for somebody to know what they are making.

The next step is exhaustiveness and automated production. At this point it will be accurate and exhaustive, but not necessarily easy to use. This is about making it possible, though not necessarily easy, for the consumer to know what they are getting.

The next step is then regularity and consistency to make it easy for the consumer to know what they are getting since it follows common, standard rules.

After that point we may get to a full reproducible build/linking manifest that allows automated validation that the SBOM matches the delivery. But this step has a good chance of fizzling out as a standard practice in general industry.

The first three are clearly where this is all going and constitute a very minor cost relative to a very outsized benefit. We might not even get to the third step, but even then at least general software development would have reached engineering 101 process sophistication which is a massive improvement over the status quo.

[ploxiln]

> A SBOM is for the producer at this time, not the consumer. It is about requiring the producers to at least try to figure out what they put into your soup.

> The next step is exhaustiveness and automated production.

There are lots of vendors selling automated SBOM generation tools/services, my company's security team is using it. Is the output correct? I don't know, they don't know, nobody looks at it. But we have SBOMs [checkmark]

[Veserv]

Yep, that is the point of the first phase. The next phase is going to be attaching liability for incomplete SBOMs.

The way it will likely play out is that if you were breached due to a undisclosed component in a purchased product the product will either be deemed defective or the vendor will be liable. If CISA succeeds at pushing that you will see the SBOMs becoming correct and exhaustive real fast, though likely excessive due to ass-covering.

But at this point the goal is clearly just establishing a paper trail so that it can eventually be audited for consequences. Maybe they will fail at the next step due to industry pushback against actual consequences for shoddy work, but that is clearly where it is trying to go.

[beams_of_light]

https://security.googleblog.com/2022/06/sbom-in-action-findi...