What the Regulation asks
Annex I, Part II, point (1) of Regulation (EU) 2024/2847: manufacturers shall “identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products”. This applies from 11 December 2027 (Article 71).
- The SBOM belongs to the technical documentation, with the vulnerability handling processes (Annex VII, point 2(b)).
- You give it to a market surveillance authority on a reasoned request (Annex VII, point 8). You do not have to make it public (recital 77).
- If you choose to make it available to users, the user information says where (Annex II, point 9).
- The Commission may set its format and elements by an implementing act (Article 13(24)). CycloneDX and SPDX are commonly used formats.
What this page writes
A CycloneDX 1.6 JSON file with your product as the main component, each package with its exact version and package URL (purl), and the product's top-level dependencies where the lock file says which they are. It reads:
- npm package-lock.json (lockfileVersion 2 or 3), Yarn yarn.lock (Yarn 1, 2 and later) and pnpm-lock.yaml (lockfileVersion 9.0); development-only packages are left out where the file says which they are;
- Python requirements.txt with every package pinned (name==version), as pip freeze or pip-compile write it;
- Rust Cargo.lock, version 3 or 4, and Go go.mod, with the indirect modules;
- the Maven dependency tree written by mvn dependency:tree -DoutputFile, and Gradle gradle.lockfile; test-scope packages are left out;
- PHP Composer composer.lock, without packages-dev, and NuGet packages.lock.json.
A file that does not follow its format is not read, with the line and the reason, rather than guessed at. A package from a source other than the public registry is listed without a package URL, so the file never points at a package you did not use.
Already have an SBOM from another tool? Open it as a CycloneDX JSON file, or as an SPDX JSON file such as the one GitHub's dependency graph exports (Export SBOM), to check its components on OSV.dev and against the KEV catalogue. It is read for the check only: to make a new SBOM, open the lock files. Where no lock file pins a version, GitHub's file gives a range such as ^4.17.0: those components are listed as not checked, so open the lock file to check them.
Known exploited vulnerabilities
The check marks each vulnerability found on OSV.dev whose CVE number is in the Known Exploited Vulnerabilities catalogue (KEV) of the US Cybersecurity and Infrastructure Security Agency (CISA), with the date CISA added it. CISA lists a vulnerability once there is reliable evidence that it has been exploited. From 11 September 2026, Article 14 of the CRA asks you to notify an actively exploited vulnerability contained in your product (Article 3(42)) within 24 hours of becoming aware of it. A KEV entry does not decide that for your product, but it is where to look first; the reporting deadlines page counts the hours.
What it does not cover
The SBOM lists what the lock files list. Code you copied into the product, operating system packages, firmware and libraries in other languages are not in them: add those to the file yourself. The vulnerability check uses OSV.dev, which lists published vulnerabilities only; it does not replace the assessment of vulnerabilities that Annex I, Part II asks for.
For the rest of the CRA files, the CRA document kit writes the technical documentation and the EU declaration of conformity. The CRA check tells you your product's class.