How sbomify helps with the CRA
What sbomify does for each Cyber Resilience Act obligation, from SBOMs and vulnerability handling to support periods and Article 14 reporting, and what stays your responsibility.
The Cyber Resilience Act asks manufacturers to design secure products, assess their conformity, and then handle vulnerabilities for as long as each product is supported. sbomify is built for the second half of that: knowing what is in every release, finding and deciding on vulnerabilities, and telling customers and authorities about them.
sbomify will not make you CRA compliant on its own, and no tool can. The table below maps each obligation to what sbomify does, so you can see where it fits in your own process.
- Built in: sbomify does this
- Supports: sbomify gives you the data or the draft; you complete it
- Yours: outside sbomify's scope
Vulnerability handling (Annex I, Part II)
These requirements apply for the whole support period of a product. This is where sbomify does most of its work.
| Obligation | sbomify | What sbomify does |
|---|---|---|
| (1) Identify and document components, including an SBOM | Built in | Generates CycloneDX and SPDX SBOMs in CI, validates them against the official schemas and checks them against BSI TR-03183-2. Component SBOMs are pinned to product releases and merged into one SBOM per release. Stored SBOMs are never modified. |
| (2) Address and remediate vulnerabilities without delay | Supports | Rescans released SBOMs on a schedule with Google OSV and Dependency-Track, flags CISA KEV and EUVD entries, and shows which products and releases contain each vulnerability. Triage decisions are recorded as VEX, remediation status and fix deadlines are tracked, and fix prompts can be handed to your coding agents. Writing and shipping the fix is your work. |
| (3) Regular security tests and reviews | Yours | Penetration tests, code review and security testing happen outside sbomify. You can store the resulting reports alongside your SBOMs and share them through your Trust Center. |
| (4) Publicly disclose fixed vulnerabilities | Built in | Write security advisories that list affected products and releases, severity and remediation, then publish them in your Trust Center and as a CSAF 2.0 feed with provider-metadata.json and a ROLIE feed. Every change to an advisory is kept on its timeline. |
| (5) Coordinated vulnerability disclosure policy | Supports | The CRA Compliance Wizard drafts a vulnerability disclosure policy from your product details. Running the process it describes is up to you. |
| (6) Contact address for reporting vulnerabilities | Supports | Generates a security.txt file pointing researchers to your contact address, policy and advisories. You own the inbox and the response. |
| (7) Securely distribute updates | Yours | Signing and delivering software updates is part of your release infrastructure, not sbomify. |
| (8) Disseminate security updates with advisory messages | Supports | sbomify publishes the advisory that goes with each update, to people through the Trust Center and to machines through CSAF and the Transparency Exchange API. Shipping the update itself is yours. |
Other manufacturer obligations
Obligations around the product as a whole. sbomify supplies data and drafts for several of them; the decisions and signatures are yours.
| Obligation | sbomify | What sbomify does |
|---|---|---|
| Support period (Article 13(8)) | Built in | Records release, end-of-support and end-of-life dates for products, components and releases using the ECMA-428 Common Lifecycle Enumeration, and helps you publish an end-of-life notice when support ends. Choosing the support period is your decision. |
| Reporting actively exploited vulnerabilities and severe incidents (Article 14) | Supports | Drafts the 24-hour early warning, the 72-hour notification and the final report from the data you already hold, and flags known-exploited vulnerabilities. sbomify does not submit reports for you: they go through the ENISA Single Reporting Platform. |
| Technical documentation (Article 31, Annex VII) | Supports | The CRA Compliance Wizard exports one bundle with your SBOMs, an OSCAL assessment, the generated documents and a SHA-256 manifest, ready for you to sign. The parts about product design and testing come from you. |
| Cybersecurity risk assessment (Article 13(2)) | Supports | Provides a risk assessment template as part of the wizard. The assessment itself has to reflect your product and your threat model. |
| Information and instructions for users (Annex II) | Supports | Drafts user instructions and a secure decommissioning guide, and lets you share them, along with the SBOM, through your Trust Center. |
| EU declaration of conformity and CE marking (Articles 28 to 30) | Supports | Drafts the declaration of conformity from your product profile. Signing it, and affixing the CE marking, is a legal act by the manufacturer. |
| Essential cybersecurity requirements for the product (Annex I, Part I) | Yours | Secure by design and by default, access control, data protection, attack surface reduction and logging are properties of your product. sbomify doesn't build or test them. |
| Conformity assessment (Article 32) | Yours | Self-assessment or assessment by a notified body, depending on your product's class. sbomify's export bundle is evidence for that process, not a substitute for it. |
Plan availability
The free Community plan includes SBOM management, OSV scanning with weekly rescans and a public Trust Center. Paid plans add private documents, a Trust Center on your own domain, daily rescans and Dependency-Track. The CRA Compliance Wizard, with its generated documents and export bundle, is on Business and Enterprise. See pricing for details.
For the legal detail behind each obligation, deadlines and penalties, read our EU CRA guide.