|
|
|
|
|
by Veserv
935 days ago
|
|
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. |
|
> 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]