Your SBOM isn’t for the compliance team

What developers keep telling me

The pattern is consistent. A customer questionnaire or an audit asks for an SBOM. Someone adds a generator to the build, or runs one by hand before the deadline. The file is handed over, and from the development team’s point of view that is the end of it. Nobody comes back with a question the SBOM helped answer, so it never becomes part of how the team works. It joins the list of artefacts that exist for someone else.

If that is your experience, the scepticism is fair. A file nobody uses is a chore. The problem is not the SBOM; it is that the question it answers has rarely been asked under time pressure. That is what is changing.

The question an SBOM actually answers

Developers know what is in their product today. The lockfile and the dependency tree on main tell them. But customers do not run main. They run the version that was released last spring, or the one from two years ago that is still in its support period. The question that matters when a vulnerability is published is not “what do we depend on now?” but “which of the versions we shipped contain this component, at which version, and where are they running?”

Reconstructing that after the fact is slow. Tags have to be checked out, builds reproduced, transitive and bundled dependencies traced, container base images inspected. An SBOM generated for each release and kept with it is a record that answers the question directly, for every version at once.

Why the CRA reporting clock changes the conversation

Since 11 September 2026, manufacturers have to report actively exploited vulnerabilities in their products. The early warning is due within 24 hours of becoming aware of one. The CRA also requires an SBOM in its own right: Annex I, Part II asks for one in a machine-readable format, covering at least the top-level dependencies. But in my conversations it is the clock, not that line in the annex, that makes the SBOM real.

Think about the first hour after an advisory says a component is being exploited. The first question is not a compliance question. It is the developer’s question from above: are we affected, in which releases, and is the vulnerable code actually reachable in our product? The compliance team cannot answer it. The build records can. How the rest of the process works, from intake to the fix reaching customers, is something I described in Why vulnerability management is the engine of a secure-by-design product. Here I only want to stay with that first hour.

What it looks like when it works

To show this to teams, I built a small demo product: the Demo IoT Gateway, a fictitious Java application with deliberately old libraries. Its build pipeline generates a CycloneDX SBOM for every release and uploads it to OWASP Dependency-Track, which checks each component against public vulnerability databases and keeps watching after the release.

Release 1.0.0 contains nine components and about 33 known vulnerabilities. Two of them are on the CISA list of known exploited vulnerabilities: Log4Shell (CVE-2021-44228) and its follow-up, CVE-2021-45046. The question “which of our versions contain it?” takes seconds: 1.0.0 does. The triage decision is recorded in the tool, the reportability check says that in a real product this would start the 24-hour clock, and release 1.0.1, which changes nothing but the log4j version, removes both findings.

The same SBOM shows the other side, which developers usually find more convincing. Apache Commons Text 1.9 is flagged too, for CVE-2022-42889. But the vulnerable string interpolation is never called in this product. That decision is recorded once, as a VEX statement: not affected, code not reachable. No report, no emergency release, and a written reason the next time someone asks.

What separates a useful SBOM from a compliance export

• Generated by the build, for every release — not assembled by hand before an audit, so it describes what actually shipped.
• Exact versions and package identifiers (package URLs), so a vulnerability database can match each component without guesswork.
• Kept with the release it describes, for as long as that version is supported and in use.
• Watched continuously, because vulnerabilities are published every day for components you shipped years ago.
• Paired with VEX decisions, so “not affected” is decided once, with a reason, and travels with the product.

There is an honest gap as well. Components inside supplier firmware and embedded libraries are often missing from public databases, and sometimes from the SBOM itself. For those, the SBOM is only as good as what your suppliers give you, which is a conversation worth starting now rather than in the first hour of a case.

What I take from it

The developers I talk to are right about one thing: an SBOM produced for someone else is a chore. Explaining the regulation better will not change that. What changes it is the first time a team answers “are we affected?” in minutes, from its own SBOMs, while the clock is running. After that, nobody needs to be told why it is worth generating. The SBOM was never really for the compliance team. It is for the people who have to answer the question.