Under the Cyber Resilience Act (Regulation (EU) 2024/2847, "CRA"), every product with digital elements needs a software bill of materials (SBOM). The good news: generating one is free and takes seconds. The less good news: the SBOM is the starting point of the CRA's vulnerability handling, not the end of it. This guide compares the four best-known free generators and shows what is still left for you to do.
What the CRA actually requires
Annex I, Part II, point 1: manufacturers must identify and document vulnerabilities and components contained in the product, "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".
Three things follow from that sentence:
- Format: "commonly used and machine-readable". In practice that means CycloneDX or SPDX in JSON. The CRA does not name a format; the Commission may specify the format and elements by implementing act (Art. 13(24)).
- Depth: at least top-level dependencies. Most tools give you transitive dependencies too, which is what you need to answer "are we affected?" when a new CVE appears.
- Place: the SBOM is part of the technical documentation (Annex VII, point 2) and must be handed to a market surveillance authority on reasoned request (Annex VII, point 8). You do not have to publish it. Keep it, like the rest of the documentation, for 10 years or the support period, whichever is longer (Art. 13(13)).
A useful benchmark while there is no EU format rule: Germany's BSI Technical Guideline TR-03183-2 (version 2.1.0, August 2025) asks for CycloneDX 1.6 or higher, or SPDX 3.0.1 or higher, with the SBOM creator, a timestamp, and for each component its creator, name, version, filename, hash and licence. It is not EU law, but it is the most detailed public description of a CRA-ready SBOM so far.
The four tools at a glance
| Syft | Trivy | cdxgen | Microsoft SBOM Tool | |
|---|---|---|---|---|
| Maintained by | Anchore | Aqua Security | CycloneDX project (OWASP) | Microsoft |
| Licence | Apache-2.0 | Apache-2.0 | Apache-2.0 | MIT |
| Output | CycloneDX JSON, SPDX JSON, Syft JSON; converts between formats | CycloneDX JSON, SPDX (tag-value and JSON) | CycloneDX 1.6 and 1.7 (older on request); export to SPDX 3.0.1 | SPDX 2.2 by default, SPDX 3.0 |
| Scans | Container images, directories, archives | Directories, container images, VM images, Kubernetes, IaC | Source repositories, lock files, container images | Build output and source, via Component Detection |
| Also finds vulnerabilities | No - pairs with Grype | Yes (trivy sbom, --scanners vuln) | No | No |
| Best for | One tool for everything, mixed stacks | Teams that already use Trivy for scanning | Deep, accurate dependency trees from source | .NET and Azure DevOps pipelines |
All four cover the common ecosystems: JavaScript/npm, Python, Java, Go, Rust, PHP and .NET.
Strengths and catches
Syft handles dozens of package ecosystems, from Alpine, Debian and RPM packages to npm, PyPI, Maven, Go modules, Composer and Cargo, and works on container images as well as plain directories. It can produce signed SBOM attestations. The catch: it reads what is on disk and in manifests, and does not resolve dependency trees as deeply as language-specific tools.
Trivy generates an SBOM and scans it in one tool, which makes it popular in CI. One warning: on 19 March 2026, attackers published a backdoored Trivy release (v0.69.4) and rewrote version tags of the trivy-action and setup-trivy GitHub Actions to steal CI secrets - the second compromise of Trivy's infrastructure in under three weeks. If you use it, check which versions you pulled and pin GitHub Actions to full commit SHAs, not tags. That advice applies to every tool in this list.
cdxgen focuses on accuracy: it resolves dependency trees from lock files and package managers and can add evidence of where a component was found. It targets current CycloneDX versions and can convert to SPDX 3.0.1, which matches the BSI benchmark above. The catch: it is CycloneDX-first, and runs on Node.js unless you use the standalone binary or container.
Microsoft SBOM Tool is built for build pipelines, validates its output, and fills licence data from the ClearlyDefined service. The catch: it produces only SPDX, defaults to SPDX 2.2, and its ecosystem coverage is narrower than Syft's.
A first SBOM in one line
From the root of your repository, after installing the tool:
syft dir:. -o cyclonedx-json=sbom.cdx.json
trivy fs --format cyclonedx --output sbom.cdx.json .
cdxgen -o sbom.cdx.json .Run it on the code you actually ship. For a plugin, that is the release package with its bundled libraries; for a container, the image; for firmware, the root filesystem. Commit the SBOM next to the release, or store it with your release artefacts.
Firmware and C/C++ need extra work. Generators find components through package managers and lock files. Libraries copied into the source tree, vendor SDKs and statically linked code often have neither. Expect to add those components to the SBOM by hand, or from your build system's own manifest.
What no generator does for you
The CRA's vulnerability handling (Annex I, Part II) and reporting (Art. 14) start where the SBOM ends:
| The CRA asks you to | What the free tools give you | What is left to you |
|---|---|---|
| Keep an SBOM for each release | A file, when someone runs the command | Run it at every release, keep each version for 10 years |
| Address vulnerabilities without delay | A list of CVEs on the day you scan (Trivy, Grype) | Scan again every day; decide which CVEs actually affect you |
| Know if a vulnerability is actively exploited | Nothing directly | Watch exploited-vulnerability sources such as ENISA's European Vulnerability Database (EUVD) |
| Report an exploited vulnerability within 24 hours, notify within 72 hours | Nothing | Write and submit the early warning and notification (how) |
| Publish a disclosure policy and a contact address | Nothing | Write the policy, publish security.txt, answer reports |
| Document all of it in the technical documentation | The SBOM only | Write and update the documentation (what goes in it) |
The SBOM tells you what is inside. The daily routine around it is what the CRA really asks for - and it is the part that slips in a company of three, because nobody notices a missed day until a customer does.
An honest note: if you have a developer who enjoys this, the free tools plus a scheduled CI job and a daily look at the results can get you most of the way. Many teams start like that.
Not sure what the CRA asks of you?
Take the free "Does the CRA apply to me and what must I do by December 2027" check: 8 questions, about 3 minutes, result on screen and checklist by e-mail. Take the free check
If you would rather not own the routine, Earlybell does it for you: connect your repository, and we generate the SBOM with every release, check all your dependencies daily, flag what is actively exploited, draft your 24-hour and 72-hour reports for you to submit, and keep your disclosure policy and security.txt up to date. 49 EUR per product per month.
This article is based on Regulation (EU) 2024/2847 (Cyber Resilience Act), the tools' own documentation and public reports, as of October 2026. Tool features change between releases; check the current documentation. It is not legal advice.