The minimum viable SBOM for CRA compliance

What the law actually requires

Annex I Part II(1) requires manufacturers to 'identify and document vulnerabilities and components' including 'drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies'.

Read that twice: top-level dependencies, machine-readable, commonly used format. You do not need a full transitive graph with hashes to be compliant on day one (though it is better, and free to produce). You need CycloneDX or SPDX, generated reliably, per release.

The SBOM does not have to be public. It must exist, be accurate, and be available to market surveillance authorities on request.

Pick CycloneDX unless you have a reason not to

Both CycloneDX and SPDX satisfy the regulation. CycloneDX has better tooling coverage for application ecosystems and is what most scanners expect. SPDX shines for license-compliance-heavy contexts. When in doubt: CycloneDX JSON.

The one-liner per ecosystem

Run in CI on every tagged release, upload as a build artifact:

• ▸Anything (universal): syft . -o cyclonedx-json > sbom.cdx.json
• ▸npm/pnpm/yarn: cdxgen -o sbom.cdx.json (or syft)
• ▸Python: cyclonedx-py environment or syft
• ▸Go: syft handles go.mod natively; cyclonedx-gomod for deeper module data
• ▸Rust: cargo cyclonedx
• ▸Containers: syft your-image:tag -o cyclonedx-json

Now make it useful (this is the compliance multiplier)

A stored SBOM satisfies the letter of Annex I Part II(1). Scanning it continuously satisfies Part II(2)-(3) — 'address and remediate vulnerabilities without delay'. The pipeline is: SBOM per release → match against OSV/NVD continuously → alert → patch → advisory.

You can assemble this from open source (Dependency-Track self-hosted) or let a service run it. Either way, the evidence trail — SBOM, scan results, remediation dates — is exactly what an auditor or market surveillance authority will ask for.

Common mistakes

• ▸Generating the SBOM manually, once. It drifts from reality on the next release; auditors notice mismatched versions immediately.
• ▸SBOM of the repo instead of the artifact: scan what you ship (the built image/bundle), not just the lockfile.
• ▸Forgetting vendored code and binary blobs — the stuff not in the package manager is the stuff that ages worst.
• ▸Treating 'no known vulnerabilities today' as done. The obligation is continuous; new CVEs land against old versions weekly.