SBOM

An SBOM lists components at a defined level of detail — typically name, version, supplier and relationship to other components — in a machine-readable format such as SPDX or CycloneDX. The CRA requires manufacturers to produce an SBOM covering top-level dependencies as part of technical documentation, and to maintain a process for identifying and remediating vulnerabilities in those components.

Why it has to be operational, not archival

• It must be regenerated when dependencies change, not produced once at release and left static.
• It must be queryable quickly enough to answer 'which shipped products contain this component version' within a reporting window measured in hours.
• It feeds vulnerability monitoring, matching component versions against disclosed CVEs.
• It supports customer and downstream due diligence, particularly for products embedded in other manufacturers' products.

A common failure is generating the SBOM as a compliance artefact disconnected from the build pipeline, so it drifts from what is actually shipped. An SBOM that cannot be trusted to reflect the current build is close to useless for incident response, whatever its documentation value.

Depth of detail should match risk: critical or frequently updated components warrant deeper visibility than stable, low-risk dependencies.