SBOM for CRA: short answer
The CRA requires manufacturers to identify and document the components of a product with digital elements and to handle vulnerabilities throughout the support period. An SBOM is the practical inventory that makes this possible.
An SBOM is not a one-off PDF. It must be tied to a product release, cover transitive dependencies and connect to a vulnerability process that can find, triage and fix affected components.
Minimum SBOM fields
| Field | Why it matters |
|---|---|
| Component name and version | Identifies what is actually shipped. |
| Supplier | Shows who owns the component and where to escalate. |
| Package identifiers | purl or CPE lets tools match advisories reliably. |
| Dependency relationship | Separates direct from transitive components. |
| Product and release | Ties the SBOM to the version customers run. |
| Timestamp and author | Shows when and by which build the SBOM was produced. |
| License | Supports legal review and redistribution checks. |
SPDX, CycloneDX or a spreadsheet?
SPDX and CycloneDX are the common machine-readable formats. Choose one your build pipeline can generate and your customers can consume. A CSV is useful for a first inventory, but it is harder to validate and link to releases.
Whatever the format, keep a stable mapping between an internal component ID and the package identifier. That mapping is what lets you answer a new CVE without rebuilding the whole inventory.
A workable SBOM process
- Generate: produce the SBOM in the build pipeline, not after release.
- Enrich: add supplier, identifiers, licenses and dependency relationships.
- Store: keep each version with the product release and build metadata.
- Match: compare components with vulnerability feeds and advisories.
- Triage: assign an owner, exploitability and remediation deadline.
- Update: regenerate when a component changes; keep the old version for traceability.
- Share: provide the agreed extract to customers or authorities under contract.
Vulnerability matching in practice
A CVE feed alone is not enough. You need a component-to-advisory mapping, a triage decision and evidence of the fix. Track:
- Affected product and version range.
- Exploitability and exposure in your configuration.
- Severity and business impact.
- Remediation, workaround and release version.
- Customer communication and disclosure timing.
For actively exploited vulnerabilities, CRA reporting deadlines apply. Keep the SBOM and the incident record linked.
What to show a customer or regulator
- SBOM for the exact release, with a timestamp.
- Component identifiers and supplier contacts.
- Vulnerability policy, triage records and remediation SLAs.
- Evidence of the fix and the new SBOM version.
- Support-period statement and update mechanism.
- Disclosure and incident-reporting records.
Our Estonian SBOM guide includes a CSV template. A penetration test supports the technical evidence but does not replace the inventory.
Check an SBOM CSV
Upload the downloadable template or a file with the same headers. The checker looks for required fields, identifiers, duplicate component versions and placeholder values. The file stays in your browser.
The check is indicative and does not replace an SBOM quality audit.
Frequently asked questions
Is an SBOM mandatory under the CRA?
The CRA requires manufacturers to identify and document components and vulnerabilities. An SBOM is the practical way to meet that duty; the regulation does not prescribe one file format.
Which SBOM format should I use?
SPDX and CycloneDX are the most common machine-readable formats. Choose what your tooling and customers can consume, and keep the mapping to internal component IDs.
Should the SBOM be public?
Not necessarily. Regulators, customers and integrators may need an extract under contract. Publish only what you intend to disclose; the internal SBOM can remain confidential.
Does an SBOM include transitive dependencies?
A useful SBOM does. Direct components alone hide the dependency chain and the vulnerabilities that reach your product through third-party libraries.
How often should the SBOM be updated?
At every release and whenever a component changes materially. It must stay tied to the product version and support period.
Does an SBOM prove CRA compliance?
No. It is one evidence layer. Compliance also needs risk assessment, secure design, vulnerability handling, technical documentation, conformity assessment and support.