sbom (sbom ecosystem)

Bomly uses this chain when it finds sbom evidence.

How sbom resolves

sbom-detector is a direct ingest — it accepts SPDX 2.3 JSON or CycloneDX 1.6 JSON as input and treats the SBOM as the source of truth for the graph. No subprocess runs, no other detector chains fire.

Format is auto-detected by content.

Network behavior

✅ Fully offline-safe. Ingest is a local read of the SBOM file.

Triggering ingest

Pass --sbom with --path pointing at the file:

bomly scan --sbom --path ./vendor.spdx.json

Without --sbom, files matching *.spdx, *.cdx.json, bom, etc. are still detected by their evidence patterns, but Bomly may run other detector chains on the surrounding directory. Use --sbom to be explicit.

--install-first

Not applicable.

Examples

Audit a vendor SBOM

bomly scan --sbom --path ./vendor.cdx.json \
  --enrich --audit --fail-on high

Convert SPDX to CycloneDX

bomly scan --sbom --path ./in.spdx.json -o cyclonedx=out.cdx.json

The scan pipeline is the conversion path; there is no separate convert command.

Diff two SBOMs

bomly diff --sbom --base ./v1.0.cdx.json --head ./v1.1.cdx.json

Reachability

Not applicable. Reachability analyzers need access to source code; an SBOM-only input cannot satisfy that. --analyze produces not_applicable for SBOM ingest.

Limitations

• Relationship fidelity depends on the source SBOM. If the SBOM was produced by a tool that emits a flat package list (no DEPENDS_ON / dependencies edges), Bomly's graph is also flat. bomly explain cannot show paths that aren't recorded.
• Vendor-specific extensions (custom properties, non-standard package types) are passed through to the JSON output but are not used for policy decisions.
• SBOM ingest is exclusive — combining --sbom with --container or --url is rejected with exit 4.
• Format versions other than SPDX 2.3 JSON and CycloneDX 1.6 JSON are rejected. SPDX 3.0 and CycloneDX 1.5 ingest are tracked for follow-up.
• Tag-Value SPDX and XML CycloneDX are not currently ingested.