Frequently asked questions

sbom-tools is an open-source Rust CLI that diffs, enriches, and scores Software, Cryptographic, and AI Bills of Materials. It runs locally, has no telemetry, and is designed to slot into any CI pipeline in under a minute.

CycloneDX (JSON and XML) and SPDX (JSON, YAML, and tag-value), including the CBOM, ML-BOM, and SPDX 3.0 AI profiles. Both formats can be diffed against each other semantically.

cargo install sbom-tools, or grab a prebuilt binary for Linux, macOS, or Windows from the GitHub Releases page. cargo binstall sbom-tools also works in CI.

Yes. sbom-tools is dual-licensed under MIT and Apache-2.0. Source, issues, and releases live on GitHub.

Prebuilt binaries ship for x86_64 and aarch64 on Linux, macOS, and Windows. There is no runtime dependency — it is a single statically-linked binary.

An SBOM inventories software components and dependencies. A CBOM inventories cryptographic assets — algorithms, key sizes, protocols, and certificates — so you can assess post-quantum readiness. An AI BOM inventories models, datasets, and training artifacts, following CycloneDX ML-BOM or SPDX 3.0 AI.

NIST has finalized post-quantum algorithms and regulators are beginning to require migration plans. A CBOM lets you enumerate every RSA, ECDSA, and legacy hash usage in your stack so you can plan and prove migration progress.

Semantic diff understands PURLs, dependency edges, and version semantics, so it reports added, removed, upgraded, downgraded, and re-scoped components — not reordered JSON keys. That is what makes the output useful in a pull-request review.

Anything that emits valid CycloneDX or SPDX: syft, cdxgen, cargo-cyclonedx, npm sbom, mvn cyclonedx, trivy sbom, and language-native tools all work.

NTIA minimum elements, US EO 14028, EU Cyber Resilience Act (CRA), FDA premarket guidance, NIST SSDF, and PQC readiness profiles. Each profile can gate CI independently.

Each profile is a weighted checklist of required fields and relationships (supplier, version, hashes, license, dependency edges, etc.). sbom-tools reports a score plus per-check evidence so weak SBOMs fail review with a clear reason.

Yes. Exit codes and SARIF output let you fail a build on new criticals, KEV hits, EOL runtimes, missing NTIA fields, or a drop in the CRA/PQC score. See the CI/CD section on the home page for a ready-to-copy GitHub Actions snippet.

It consumes CycloneDX VEX to suppress non-exploitable findings during enrichment, and emits VEX-compatible statements in the diff report.

No. There is no telemetry, no crash reporting, and no phone-home. Nothing leaves your machine unless you explicitly run a command that queries an external API.

No. SBOMs are parsed and analyzed locally. Only component identifiers (PURLs, CVE IDs) are sent to public APIs during enrichment, and those requests go direct — sbom-tools does not proxy them.

Only the ones you opt into: osv.dev for OSV vulnerability data, CISA KEV for the Known Exploited Vulnerabilities catalog, and optionally Hugging Face for AI BOM enrichment.

Releases ship with SLSA provenance, Sigstore keyless signatures, and GitHub attestations. You can verify any release in 30 seconds and inspect the raw evidence in-browser on the Trust page.

Use GitHub Security Advisories on the sbom-tool/sbom-tools repository for private disclosure. Details are on the Trust page.