A Software Bill of Materials is the ingredient list of a software product: a structured, machine-readable inventory of every component, its version, its supplier, its license and its relationship to other components. The concept rose to prominence after the Log4Shell incident in December 2021, and the United States formalised it through Executive Order 14028 on 12 May 2021. The EU is now following suit, but goes further in one important respect: the SBOM obligation is embedded in a regulation, not an executive directive, and it is enforced through fines of up to 15 million euros or 2.5 percent of worldwide annual turnover.
The relevant text sits in Annex I, Part II, point 1 of the Cyber Resilience Act (Regulation (EU) 2024/2847): manufacturers must identify and document the components contained in products with digital elements, including by drawing up an SBOM in a commonly used and machine-readable format that covers at least the top-level dependencies of the products. That sentence sounds narrow. In operational practice it forces manufacturers to rebuild their release pipeline so that SBOMs are produced, signed, stored and queryable on demand.
Legal basis: Regulation (EU) 2024/2847, Annex I Part II point 1
Full CRA application: 11 December 2027
Reporting obligations (trigger for SBOM queries): 11 September 2026
Dominant formats: CycloneDX (OWASP) and SPDX (Linux Foundation, ISO/IEC 5962:2021)
Minimum required content: top-level dependencies, machine-readable
Best practice: full transitive dependency graph with package hashes
US EO 14028 (12 May 2021) established the SBOM baseline for federal suppliers
What belongs in an SBOM
The European Commission's draft implementing act and the widely used NTIA Minimum Elements for an SBOM converge on the same core fields. Each component must carry an identifier (name and version), a supplier, a unique package identifier (Package-URL / purl or CPE), a cryptographic hash such as SHA-256, and a license type. Relationships between components must be captured — which component depends on which.
The CRA text itself strictly requires only top-level dependencies. In practice this minimum is insufficient. When a critical vulnerability appears in a transitive dependency (a dependency of a dependency), the manufacturer still has to answer, within 24 hours, whether the product is affected. Without a full transitive SBOM that answer cannot be produced in time.
The pragmatic solution is to deliver a top-level SBOM to customers as the formal artefact while maintaining a complete internal dependency graph that feeds vulnerability monitoring tools. The shipped SBOM satisfies the letter of the regulation; the internal graph satisfies the 24-hour reporting window.
CycloneDX versus SPDX
Two SBOM formats dominate the market. CycloneDX was created by the OWASP Foundation and is deliberately compact; it also covers Vulnerability Disclosure (VEX), services, and machine-learning model bills of materials. SPDX is older, originated at the Linux Foundation, and was standardised as ISO/IEC 5962 in 2021. Its strongest feature is detailed license and copyright metadata.
Under the CRA both formats are acceptable as long as they are commonly used and machine-readable. The decision typically follows the existing toolchain. Teams already running Syft, Trivy or cdxgen usually end up on CycloneDX. Teams with heavy Yocto-based embedded Linux builds usually stay on SPDX, which the Yocto project has adopted as its native format.
Conversion between the two is possible using tools like cyclonedx-spdx-cli, but it is not lossless. Greenfield projects should pick CycloneDX: its VEX integration is noticeably cleaner for vulnerability handling, which is exactly the workflow the CRA makes mandatory.
Running SBOM management in CI/CD
An SBOM that is maintained manually is worthless. The operating principle: generate the SBOM on every build, sign it alongside the release artefact, store it next to the artefact in the registry, and ship it with the product as a detachable file or as an OCI artefact in a container registry.
Proven toolchains exist for every ecosystem. For containers, Syft generates SBOMs and Grype or Trivy scans them continuously for known vulnerabilities. For Java, Gradle and Maven there are official CycloneDX plugins. For Node.js there is cdxgen. For Python there is cyclonedx-python. Signed SBOMs are typically produced with cosign and pushed into the same OCI registry as the container images, which makes verification straightforward for downstream consumers.
Generating the SBOM is only half the obligation. Under the CRA the SBOM must be preserved for the product's entire support period — generally at least five years and aligned with the expected useful life. That retention obligation usually belongs to release management rather than to CI, and it is a detail that catches many teams by surprise during their first CRA gap assessment.
Now: add an SBOM generator (Syft, cdxgen, Trivy) to CI pipelines
Q1 2026: choose format (CycloneDX or SPDX), define naming and versioning scheme
Q2-Q3 2026: ship SBOMs alongside release artefacts, wire into vulnerability scanners
11 September 2026: CRA vulnerability reporting becomes live — SBOM must feed into CSIRT reports
11 December 2027: full CRA application — SBOM mandatory, technical documentation under Annex II complete
The tool landscape in one honest paragraph
The SBOM tool market is split. Open-source generators like Syft, cdxgen, Trivy, and the reference CycloneDX and SPDX implementations are free, well maintained, and sufficient for many mid-market manufacturers. Commercial SBOM management platforms — Snyk, Sonatype Lifecycle, JFrog Xray, FOSSA, Anchore Enterprise, and Dependency-Track on the open-source side — add central management, diffing, vulnerability correlation, VEX workflow and alerting on top of the raw generators.
The right question is not which tool is best. It is whether the organisation can answer, within 24 hours, the following: a critical vulnerability has just been disclosed in a component we use — which of our products are affected, which versions, which customers run them, and what is our exposure. Teams that can answer this question cleanly have SBOM management. Everything else is tooling detail.
Frequently asked questions
What is an SBOM?
A Software Bill of Materials (SBOM) is a structured, machine-readable inventory of the components that make up a software product, including each component's name, version, supplier, license, cryptographic hash and its relationships to other components. The concept became mandatory for US federal suppliers through Executive Order 14028 in May 2021, and under the EU Cyber Resilience Act it becomes obligatory for any product with digital elements placed on the EU market from 11 December 2027.
Which SBOM formats does the CRA accept?
The CRA requires a commonly used, machine-readable format without naming a specific standard. In practice that means CycloneDX from the OWASP Foundation or SPDX from the Linux Foundation, the latter standardised as ISO/IEC 5962:2021. CycloneDX is dominant in cloud-native and DevSecOps pipelines and integrates cleanly with VEX (Vulnerability Exploitability eXchange); SPDX has the most detailed license metadata and is the native format of the Yocto project.
Who has to produce an SBOM under the CRA?
Every manufacturer placing a product with digital elements on the EU market must produce an SBOM. That covers hardware with embedded software, standalone software, firmware and SaaS components that ship as part of a locally installed product. Importers and distributors can inherit the obligation in certain cases. Cloud-only SaaS services and products already regulated elsewhere (medical devices, vehicles, aviation) are out of scope.
What must an SBOM contain?
At minimum the CRA requires top-level dependencies. Best practice is to include the full transitive graph. Each component should carry a name, a version, a unique identifier (purl or CPE), a supplier, a license, and a cryptographic hash. The SBOM should also include a creation section that records when it was generated and by which tool, so that downstream consumers can verify freshness and provenance.
How often must an SBOM be updated?
An SBOM is bound to a specific build. It is regenerated on every release. Once a version ships, its SBOM stays fixed — it documents that version. When a new vulnerability is later discovered in a component, the SBOM itself is not modified. Instead, a VEX statement is published alongside it, declaring whether the product is actually exploitable given how the component is used. That separation is what keeps SBOMs auditable over the lifetime of a product.
Which tools work best for SBOM management?
For generation, Syft, cdxgen, Trivy and the CycloneDX or SPDX reference implementations for Java, Python, Node and Go are the proven choices. For central management in larger organisations, commercial platforms such as Snyk, Sonatype Lifecycle, JFrog Xray, FOSSA and Anchore Enterprise add diffing, vulnerability correlation and VEX workflows on top of raw generators. Dependency-Track, an OWASP project, provides a free alternative for teams that want to self-host SBOM management.