Generating an SBOM for your stack

The CRA Desk scan reads a software bill of materials (SBOM); it never generates one. Your build produces the inventory, the scan turns it into a Cyber Resilience Act (CRA) readiness report. Each ecosystem we watch has its own page with the generate step, the traps and the whole CI job - the scan step after it is the same everywhere.

CRA Desk reads CycloneDX 1.5, 1.6 and 1.7 and SPDX 2.3, JSON only. XML and SPDX tag-value are detected and explained rather than mis-parsed, so a file in the wrong format is reported, never silently treated as an empty inventory.

One generate step per ecosystem

Traps worth knowing before your first run

• sbom-path takes a comma-separated list and one * in the final segment (build/*.cdx.json). It reads the first match and never merges several files, so a build writing one SBOM per module needs an aggregating command rather than a wildcard.
• Several generators emit XML by default, or XML alongside JSON. The scan refuses XML deliberately, so point sbom-path at the .json file and pass the format flag where the tool has one.
• SPDX has to be JSON (--output spdx-json in syft). SPDX tag-value files are detected and explained rather than read.
• On GitLab, Dependency Scanning already produces CycloneDX: point sbom_path at gl-sbom-*.cdx.json instead of adding a generator of your own.

A generator that runs is not the same as coverage. Components with no purl, no version, or from an ecosystem outside the ones we watch are counted as gaps in every report rather than reported as clean.