SBOM export: fix CycloneDX metadata.component naming and close completeness gaps

[bomly-guy]

Running independent SBOM quality/compliance validation (sbom-tools v0.1.22, checksum-verified release binary; sbomqs-compatible scoring) against Bomly's own output surfaced several export gaps. Test input: bomly scan --path <bomly-cli checkout> -o cyclonedx=out.cdx.json -o spdx=out.spdx.json at v0.21.1-era main, no --enrich (343 components).

Findings

Correctness

1. CycloneDX metadata.component is named .github/workflows/auto-version.yml (a workflow manifest) instead of the scanned project. The SPDX document from the same scan names it bomly-dependencies. Cross-format semantic similarity between our own two exports measured only 44.7% — primary-component selection and cross-format identity consistency need investigation.
2. Dependency relationships: only 188/344 components carry edges in the CDX dependencies section; graph analysis of the export reported 3 cycles, 3 islands, and 1 orphan. Verify whether the full consolidated graph is emitted and whether the cycles are real or an export artifact.

Completeness (drove a 43.4/100 score on the validator's standard profile)
3. No serialNumber on the CycloneDX document (the SPDX export does get a namespace ID).
4. metadata.tools lacks a version — emit Bomly's version.
5. Zero components carry hashes, supplier, or description. Decide which are cheaply fillable (e.g. Go module hashes from go.sum where available).

Compliance posture
6. NTIA minimum elements: passes (0 errors) today — keep it that way (consider a CI self-check gating releases on scoring our own SBOMs).
7. EU-CRA profile errors on missing manufacturer/organization identification, security contact / vulnerability-disclosure reference, and support end date — consider optional config knobs for these document-level fields.

Reproduction

Download sbom-tools v0.1.22 from its GitHub releases (verify checksums.sha256), then:

sbom-tools quality out.cdx.json --output json
sbom-tools validate out.cdx.json --standard ntia
sbom-tools validate out.cdx.json --standard cra
sbom-tools diff out.cdx.json out.spdx.json --output summary

Notes

Relevant code: internal/sbom/, internal/cli/render (WriteSBOMDocument). Changing SBOM output shape will require smoke golden regeneration and make generate if config fields are added; the interop assurance suite (test/assurance) should gain cases for items 1–4.

🤖 Generated with Claude Code

[bomly-guy]

Correction to the compliance-posture section: under sbom-tools v0.2.0 (released 2026-08-01, which reworked its compliance engine to remove lenient passes), the "NTIA minimum elements: passes (0 errors)" observation no longer holds — the same SBOM now reports NON-COMPLIANT with 346 errors, dominated by per-component supplier information (reclassified from warnings to errors). The v0.1.22 pass was an artifact of the validator's leniency, not of our completeness.

Updated targets for this issue: (a) treat the new cisa-2026 profile as the forward-looking bar (successor to NTIA 2021; currently 1,035 errors on main's output, 729 on PR #364's), and (b) supplier population is the dominant remaining gap — likely needs enrichment-derived data (deps.dev/registry metadata) or config, and can be split into its own issue if out of scope here. PR #364 measurably improves everything else (see measurement comment there).

🤖 Generated with Claude Code