SBOM management
SBOMs that stay attached to the version they describe.
Upload → validate → parse → normalise → persist → match → summarise. Original files are preserved with checksums; historical facts are never rewritten when a newer SBOM arrives. The inventory is the foundation of vulnerability handling under CRA Annex I Part II — without an accurate one, exposure is guesswork.
Direct answer · regulation
What does the CRA require from a product SBOM?
Annex I Part II(1) calls for a machine-readable SBOM covering at least the product’s top-level dependencies, as part of identifying and documenting components and vulnerabilities. The CRA does not require manufacturers to publish the SBOM routinely.
- Applicability
- The CRA generally applies from 11 December 2027. Article 14 reporting applies earlier, from 11 September 2026.
- Operational workflow
- Generate and retain an SBOM for each released product version, preserve its provenance, resolve components with stable identifiers such as purls, and match those components against vulnerability data over the support period.
What is an SBOM? A software bill of materials is a machine-readable inventory of the components in a software product and, when supplied, their versions, suppliers and dependency relationships. Under the EU Cyber Resilience Act (Regulation (EU) 2024/2847), Annex I Part II(1) calls for an SBOM in a commonly used, machine-readable format covering at least top-level dependencies.
Formats and identifiers. CycloneDX and SPDX are established exchange formats; a package URL (purl) identifies a package by type, namespace, name and version, for example pkg:npm/express@4.18.2. Purls help connect SBOM components to vulnerability records. See the CI/CD generation examples, CycloneDX specification, SPDX 2.3 specification and Package URL specification.
Have a file ready? Check its structure and component identifiers in the free SBOM validator before attaching it to a release. Building the pipeline now? See the CI/CD SBOM implementation guide. For product scope and manufacturer obligations, read the Cyber Resilience Act guide, plus the guidance for software manufacturers and connected products.
Formats
CycloneDX 1.2–1.6 (JSON, XML) and SPDX 2.2–2.3 (JSON, tag/value), including GitHub dependency-graph exports and CI-generated documents from Syft, Trivy, cdxgen and the SPDX tools.
Normalised components
Name, version, package URL (purl), CPE, supplier, ecosystem, licences, hashes, direct/transitive status and dependency relationships — one schema regardless of source format.
Deduplication
Components are deduplicated by canonical purl within your organisation while product/version relationships are preserved, so 'which products ship log4j-core 2.14.1?' is one query.
Explicit errors
Invalid or unsupported documents are reported with the reason and a retry — never silently dropped. Resource caps protect the parser against hostile inputs.
Automatic matching
Each parsed SBOM is matched against OSV and GitHub advisories, enriched with CISA KEV and EPSS, and re-checked daily. New exploitation evidence reaches the product page without a re-upload.
Scale
Designed for hundreds of products, thousands of versions and hundreds of thousands of components with server-side pagination, bulk actions and SBOM diff between versions.
How ingestion works
From a file in CI to a vulnerability decision.
- Step 1
Produce per release
Generate the SBOM in the same pipeline that builds the release artefact, with purls and the dependency graph. Upload it through the UI, the public API or the CLI (vellaci sbom upload).
- Step 2
Validate and parse
Vellaci checks size, MIME type and magic bytes, detects the format and spec version, parses to a normalised component model and records parse warnings.
- Step 3
Bind and preserve
The document is bound to a product version, the original file is stored privately with a SHA-256 checksum, and the component catalogue is updated without touching earlier versions.
- Step 4
Match and monitor
Components are matched against OSV, GitHub advisories, KEV and EPSS. Findings appear in triage with exposure context; the CRA review asks whether Article 14 could apply.
What a CRA-oriented SBOM contains
Minimum content, and what makes matching reliable.
| Element | Why it matters | Source |
|---|---|---|
| Supplier, component name, version | The NTIA minimum elements; the baseline every consumer expects. | NTIA 2021 |
| Package URL (purl) | Deterministic matching against OSV and advisory databases. Without it, matching falls back to fuzzy names and produces both misses and noise. | purl-spec |
| Dependency relationships | Direct vs transitive determines who can fix it and how fast; Annex I Part II asks for at least top-level dependencies. | CRA Annex I II(1) |
| Hashes | Integrity verification and evidence that the inventory describes the artefact actually shipped. | CycloneDX / SPDX |
| Licences | Not a CRA requirement, but the same document serves licence due diligence; Vellaci extracts them. | SPDX licence list |
| Author and timestamp | Provenance for the technical documentation and for auditors asking ‘as of when?’. | NTIA 2021 |
FAQ
SBOM questions we hear most.
- Does the CRA require an SBOM?
- Yes. Annex I Part II(1) of Regulation (EU) 2024/2847 requires manufacturers to identify and document vulnerabilities and components, including a software bill of materials in a commonly used and machine-readable format covering at least the top-level dependencies. This general requirement applies from 11 December 2027; Article 14 reporting is already applicable from 11 September 2026. The SBOM is part of technical documentation and does not have to be published, but market surveillance authorities may request it.
- CycloneDX or SPDX?
- Both are machine-readable and both are accepted by Vellaci. CycloneDX (OWASP, ECMA-424) is common in application-security tooling and carries VEX natively; SPDX (ISO/IEC 5962) is common in licence-compliance and Linux-distribution workflows. Choose the one your build tooling produces reliably per release and make sure every component carries a package URL.
- Why does Vellaci keep old SBOMs instead of replacing them?
- Because a CRA reporting case, a customer question or an audit refers to a specific version placed on the market at a specific time. Overwriting the SBOM of version 2.3 with the SBOM of version 2.4 destroys the evidence of what 2.3 actually shipped. Vellaci binds each document to a product version, stores the original file with a SHA-256 checksum and never rewrites historical facts.
- What happens when an SBOM fails to parse?
- The upload is rejected with a specific reason — unsupported spec version, invalid JSON or XML, missing components array, file too large — and can be retried. Nothing is silently dropped or partially imported; a partially imported inventory is worse than none, because it produces false confidence.
- How often are components re-matched against vulnerability intelligence?
- At upload and then continuously by background jobs: OSV and GitHub Security Advisories for new advisories, the CISA KEV catalogue for exploitation evidence, and FIRST EPSS for daily exploitation probability. A component that was clean at upload and becomes exploited six months later surfaces on the product without anyone re-uploading anything.
Read next
- Guide
SBOM guide for the CRA: formats, minimum content and operations
CycloneDX versus SPDX, what a CRA-oriented SBOM must contain, which tools generate one per ecosystem, how to keep it current per release, how to share it, and how it feeds vulnerability handling and VEX.
- Guide
VEX vs SBOM: component inventory and exploitability context
A concise technical comparison of SBOM and VEX, how component matching leads to product-specific exploitability statements, and what each artifact can and cannot establish.
- Guide
CRA Article 14 reporting obligations: a practical guide for manufacturers
What must be reported under Article 14 of the Cyber Resilience Act, by whom, to whom and when — the 24-hour early warning, 72-hour notification and final report — and how to operationalise it now that the obligation is in force (since 11 September 2026).
- Guide
CRA readiness checklist for software and connected-product manufacturers
A practical CRA checklist across governance, SBOM, vulnerability handling, disclosure, incidents, reporting, support period and documentation, with evidence to keep and current transition milestones.
- Docs
SBOM ingestion
Upload, GitHub, GitLab, CI/CD and the API.
- Docs
CI/CD SBOM ingestion
GitHub Actions, GitLab CI, Jenkins, CircleCI examples.
- Docs
VEX
Per-product exploitability statements and signed CycloneDX VEX documents.
- Free tool
SBOM quality checker
Inspect CycloneDX or SPDX structure, identifiers, metadata and dependency graph locally in your browser.
Upload one SBOM and see the chain.
Components, vulnerabilities, product exposure and CRA review — connected in minutes.