SBOM guide for the CRA: formats, minimum content and operations
The Cyber Resilience Act requires manufacturers to identify and document the components in their products, including by drawing up a software bill of materials in a machine-readable format covering at least the top-level dependencies. The SBOM is not published; it is part of the technical documentation and the foundation of vulnerability handling.
By the Vellaci teamPublished Updated 4 min readOperational guidance, not legal advice
Key facts
- Requirement
- Annex I Part II(1): SBOM in a commonly used, machine-readable format, at least top-level dependencies
- Formats
- CycloneDX (ECMA-424) or SPDX (ISO/IEC 5962)
- Publication
- Not required. Part of the technical documentation; provided to market surveillance authorities on request
- Granularity
- One SBOM per product version placed on the market
- Identifier
- Package URL (purl) per component for reliable vulnerability matching
- Companion
- VEX statements to communicate exploitability per vulnerability
Why the CRA cares about SBOMs
Annex I Part II requires manufacturers to identify and document vulnerabilities and components, including by drawing up an SBOM covering at least the top-level dependencies. The SBOM is the foundation of vulnerability handling: without an accurate inventory, exposure is guesswork, Article 14 reviews start from scratch, and the due-diligence duty for third-party components in Article 13(5) cannot be evidenced. Annex VII lists the SBOM among the contents of the technical documentation.
CycloneDX or SPDX
Both are machine-readable, both are accepted by every serious consumer, and both can be generated automatically. Choose the one your build tooling produces reliably; do not hand-edit either.
| CycloneDX | SPDX | |
|---|---|---|
| Origin / standard | OWASP; ECMA-424 | Linux Foundation; ISO/IEC 5962:2021 |
| Encodings | JSON, XML, protobuf | JSON, tag/value, YAML, RDF |
| Strengths | Security-tooling ecosystem, native VEX, services and hardware, dependency graph | Licence compliance, distributions, GitHub dependency-graph export, mature tooling for C/C++ and Yocto |
| Vulnerability matching | purl, CPE, SWID | purl and CPE via external references |
| Versions Vellaci ingests | 1.2 – 1.6 | 2.2 – 2.3 |
Minimum content that makes an SBOM useful
The regulation says 'at least top-level dependencies'. The NTIA minimum elements and practical vulnerability matching argue for more:
- Supplier, component name and version for every component.
- A package URL (purl) for every component — the single most important field for matching against OSV and advisory databases.
- Dependency relationships, so direct and transitive components are distinguishable and impact can be traced.
- Hashes where available; they tie the inventory to the artefact actually shipped.
- Licences; not a CRA requirement but the same document serves licence due diligence.
- Author of the SBOM and timestamp, plus the tool that produced it — provenance for auditors.
- For firmware and hardware products: the operating system, bootloader and vendor SDK components, which are the ones most often missed.
Generating SBOMs per ecosystem
Generate the SBOM in the pipeline that builds the release artefact, not afterwards from source. Typical tooling:
| Ecosystem | Common generators |
|---|---|
| Any container image or filesystem | Syft, Trivy, cdxgen |
| JVM (Maven, Gradle) | CycloneDX Maven / Gradle plugins, cdxgen |
| JavaScript / TypeScript | @cyclonedx/cyclonedx-npm, cdxgen, GitHub dependency graph |
| Python | cyclonedx-bom, pip-audit --format cyclonedx, cdxgen |
| .NET | CycloneDX .NET tool, Microsoft sbom-tool (SPDX) |
| Go, Rust | cyclonedx-gomod, cargo-cyclonedx, Syft |
| Embedded Linux (Yocto) | create-spdx class (SPDX), meta-doubleopen |
| Firmware images | Binary analysis tools plus manually curated vendor SDK inventories |
Operational rules
- Produce a new SBOM per release and never overwrite historical documents; a reporting case refers to what a specific version shipped.
- Bind each SBOM to a product version, store the original file with a checksum, and keep parse warnings.
- Re-match against vulnerability intelligence continuously, not only at upload time. New advisories and exploitation evidence arrive daily.
- Diff SBOMs between releases; new components and version changes are where regressions and licence surprises hide.
- Publish VEX statements for the vulnerabilities that do not affect your product, with justifications, so customers can suppress false positives.
- Keep the SBOM in the technical documentation and be ready to hand it to a market surveillance authority; decide separately, per customer, whether to share it commercially.
Common mistakes
- Generating from source instead of from the built artefact, so the SBOM lists what was declared rather than what shipped.
- No purls — matching falls back to name heuristics.
- One SBOM per product instead of per version.
- Missing the runtime: the base image, operating system packages, vendor SDKs and firmware components.
- Treating the SBOM as a compliance artefact produced once instead of a living input to triage.
Frequently asked questions
- Is an SBOM required for products already on the market?
- The essential requirements, including Annex I Part II, apply to products placed on the market from 11 December 2027 and to earlier products when they are substantially modified. Building the SBOM pipeline now is what makes the Article 14 duty — which applies from September 2026 to all products — operable.
- How deep must the SBOM go?
- The legal floor is top-level dependencies. Operationally, transitive dependencies are where most exploited vulnerabilities live (log4j was rarely a direct dependency), so include the full graph your tooling can resolve and be explicit about known gaps.
- Do we need one SBOM for hardware and one for software?
- One SBOM per product version that covers all software elements, including firmware; hardware components can be listed in CycloneDX. What matters is that every shipped software component appears somewhere and can be matched.