SBOM and coordinated vulnerability handling

What an SBOM actually needs to do

An SBOM lists the components — libraries, modules, firmware, and their versions — that make up a product. Its value is realised at the moment a new vulnerability is disclosed in a widely used component: an organisation with an accurate, queryable SBOM can determine within minutes which products and versions are affected. An organisation without one has to reconstruct this manually, product by product, which is slow, error-prone and difficult to defend under regulatory scrutiny.

The CRA requires the SBOM to be in a commonly used machine-readable format; formats such as SPDX and CycloneDX are widely used for this purpose. The choice of format matters less than whether the SBOM is generated automatically as part of the build process and kept synchronised with what is actually shipped, since a manually maintained SBOM tends to drift from the real product within a few release cycles.

Building SBOM generation into the pipeline

• Generate the SBOM automatically at build time from the dependency manifest and build artefacts, not from a manually maintained spreadsheet.
• Include transitive dependencies, not only direct dependencies, since many exploited vulnerabilities sit several layers down the dependency tree.
• Version the SBOM alongside the release it describes, so historical shipped versions remain queryable.
• Cover firmware and embedded third-party components, not only application-layer software, for embedded and industrial products.
• Validate SBOM completeness periodically against a manual audit of a sample release.

Coordinated vulnerability handling

Vulnerability handling is the process by which a manufacturer receives, triages, fixes and discloses information about vulnerabilities in its products, ideally in coordination with the reporter and before public disclosure where practical. The CRA requires manufacturers to establish a point of contact for vulnerability reports, to handle and remediate vulnerabilities without imposing unreasonable conditions on reporters, and to apply coordinated disclosure practice.

• A published, monitored point of contact for vulnerability reports, ideally supporting a standard format such as security.txt.
• A documented triage process with severity criteria that distinguishes routine findings from those requiring urgent action.
• A defined path from triage to a fix, a release, and — where the vulnerability is exploited or severe — a regulatory notification.
• A disclosure policy that sets reasonable timelines for reporters and the organisation, and that has been agreed and published rather than improvised per case.
• Records of past intake, triage and resolution decisions, which double as evidence that the process operates.

Connecting SBOM and vulnerability handling to the reporting obligations

From 11 September 2026, manufacturers must be able to report actively exploited vulnerabilities and severe incidents within 24-hour early warning and 72-hour notification windows. This is the point where SBOM accuracy and vulnerability handling process maturity are tested under real time pressure: the 72-hour notification needs to state, with reasonable confidence, which products and versions are affected and what mitigation exists. Organisations that treat the SBOM as a static compliance artefact discover during a real vulnerability event that it cannot answer this question quickly.

Common failure modes

The most common failure is an SBOM that exists but is not queryable in the format needed during an incident — for example, a document rather than a searchable dataset. The second is a vulnerability handling process that exists on paper but has never been exercised, so the people responsible do not know their part of the process under pressure. The third is unclear ownership of the decision to notify authorities, which stalls the clock at the most time-critical point.

A tabletop exercise — walking a realistic vulnerability scenario through intake, triage, SBOM lookup, remediation planning and notification drafting — is one of the more effective ways to surface these gaps before they are tested by a real event.

Frequently asked questions