Vulnerability analysis & SBOM
The CRA turns your software bill of materials into a living obligation: know what is in your product, watch those components for new vulnerabilities, and fix and report them within Article 14's deadlines. This page walks the loop, and the free tool that runs it.
Generate an SBOM
Produce a machine-readable software bill of materials covering at least your top-level dependencies. This is a hard requirement, not a best practice.
How to generate it ↓Monitor for vulnerabilities
Continuously cross-reference every component against live vulnerability data (NVD, EUVD). Batched notification digests do not meet the 24-hour window.
Why digests fall short ↓Assess, fix & report
Document exploitability, ship a fix, and report actively exploited vulnerabilities to ENISA and the CSIRT on the 24h / 72h / 14-day timeline.
The tool that does this ↓CRA Vulnerability Analyzer
Upload your SBOM and active-vulnerability list. The Analyzer cross-references every component against the National Vulnerability Database (NVD) and the EU Vulnerability Database (EUVD), flags End-of-Life components, and generates a compliance report you can attach to your technical file.
How-to guides
Generate a compliant SBOM
A software bill of materials is a hard legal requirement under Annex I, Part II, Point (1). This guide covers the mandatory scope and format, how to generate one, and how it feeds the monitoring loop.
1 · Legal basis
Annex I, Part II ("Vulnerability Handling Requirements"), Point (1) requires manufacturers to "identify and document vulnerabilities and components … including by drawing up a software bill of materials in a commonly used and machine-readable format covering at least the top-level dependencies of the product."
Unlike some CRA provisions that allow interpretive flexibility, the obligation to produce a machine-readable SBOM covering at least top-level dependencies does not permit alternative approaches.
2 · Mandatory scope and format
Component coverage. The SBOM must document all top-level dependencies, the legal floor rather than the recommended target. Map transitive (indirect) dependencies wherever feasible; a shallow SBOM satisfies the letter of the law but is often insufficient for effective vulnerability management.
Format. The CRA mandates a "commonly used, machine-readable format". Accepted formats include:
- SPDX (ISO/IEC 5962:2021): widely adopted, licence-focused, suited to compliance documentation.
- CycloneDX: security-centric, well-suited to vulnerability-management workflows.
- Other structured formats (JSON, XML) from recognised tooling are generally acceptable under the baseline requirement.
Do not store SBOMs as PDF. PDF may be challenged as non-machine-readable by market surveillance authorities. Store the native JSON, XML or tag-value output from your toolchain.
Required metadata fields
| Field | Description |
|---|---|
| Component name | Unique identifier for the library, package or module |
| Version | Exact version string; version ranges are insufficient |
| Supplier / origin | Publisher, vendor or open-source project name |
| Dependency relationships | Direct vs. transitive; dependency graph where feasible |
| Cryptographic hash | SHA-256 or stronger integrity check per component |
| Licence identifier | SPDX licence expression (e.g. Apache-2.0, MIT) |
3 · Generating your SBOM
Most modern platforms can generate SBOMs automatically at build time at no additional cost:
- GitHub / Actions: Dependency Graph → Export SBOM (Settings → Code security). Outputs SPDX JSON.
- GitLab: CycloneDX reports are generated natively by the dependency-scanning CI/CD job.
- Syft (Anchore): open-source CLI producing SPDX and CycloneDX for container images, filesystems and package manifests.
- cdxgen: CycloneDX SBOMs across npm, Maven, pip, Go, Rust and more.
Vulnerability screening. Before finalising any SBOM, screen every component against known-vulnerability databases. Both GitHub's scanner and Syft integrate with Grype for this. Including a component with a known, already-patched vulnerability is a direct violation of Annex I and carries no interpretive flexibility.
If a patched version of a component exists, you must use it. There is no "risk-accepted" category under the CRA for resolved vulnerabilities. Act on every finding before placing the product on the market.
4 · Lifecycle maintenance and retention
An SBOM is a living artefact, updated continuously across the product's supported lifecycle to reflect patched components, new dependencies, removed end-of-life components and supply-chain changes. All versions of the technical documentation, including SBOMs, must be retained for at least 10 years from first market placement…
Sections 4–9: lifecycle, penalties, BSI TR-03183-2 & the readiness checklist
The rest of the guide covers the 10-year retention duty, confidentiality and supply-chain disclosure, integration with Article 14 vulnerability reporting, monitoring frequency, Germany's stricter BSI rules, the fines (up to €15M or 2.5% of turnover), and a ready-to-use readiness checklist.
Related tools & analysis
Compliance matrix
Every lifecycle obligation with its article reference; track your progress and download the full checklist.
Current state of play
Where the CRA stands today: implementing acts, harmonised standards and the road to December 2027.
Cost calculator
An indicative estimate of what reaching and maintaining compliance is likely to cost.