[wallrat]

Are SBOMs a "thing" yet? Is anybody using SBOMs in their day to day workflows?

The current tooling for generating them seems to have matured, but tools for storing and managing an SBOM inventory seem non-existent with exception for OWASP Dependency-Track.

[lucideer]

My company is using them in an internal artifact scanning tool that runs as part of CICD build pipelines. It's technically opt-in for dev teams but most have done so, and in my experience most engineers - while they may know "there's some scanning job running at build" - don't necessarily know that it's parsing SBOMs as part of its internal logic.

In other words: I suspect many engineers who are leveraging SBOMs may not know they are.

(To be clear, the SBOMs come from other tools - not directly from the teams - the main reason our internal tool ingests them is that it's much much less work than getting the same metadata from multiple language environments in different formats. We lean on other tooling that gets it for its own purposes & happens to also generate SBOMs, then we just have a single piece of logic to parse that & use it ourselves. We do also lean on Grype/Syft to augment that).

[wallrat]

Interesting. Do you keep the SBOMs around after the build to track what's running in production?

[lucideer]

Currently only an optimised representation in a DB, but I guess they could be re-generated from that.

[sebazzz]

I use them. With the Microsoft SBOM tool[0] I generate a SBOM (which is unfortunately missing license information) and then feed them to Google OSV scanner to check for vulnerabilities. Not unlike Github Advanced Security does.

[0]: https://github.com/microsoft/sbom-tool [1]: https://github.com/google/osv-scanner