Tooling
SBOM generators, language libraries, converters and validators, consumers — and a sane pipeline you can ship.
FOSS Tooling
The standards only matter if something produces and consumes them. Below is a working map of the SBOM tool landscape: what generates BOMs, what converts and validates them, and what consumes them.
Version snapshot — latest releases retrieved 2026-09-20: Syft
v1.52.0(2026-09-17), Trivyv0.74.0(2026-08-14), Dependency-Track5.1.0(2026-08-27), OSS Review Toolkit94.1.0(2026-09-17), SPDX tools-pythonv0.8.5(2026-03-13), Microsoft SBOM Toolv4.1.5(2025-12-15). Format support per tool changes quickly — check the tool's own docs for the SPDX major version and CycloneDX spec version it emits.
Generators
| Tool | Best at | Emits |
|---|---|---|
| Syft (Anchore) | Container images and filesystems; very broad ecosystem coverage. | CycloneDX (JSON/XML), SPDX (JSON, tag:value) |
| Trivy (Aqua Security) | Images, filesystems, IaC, and repos; generation plus scanning in one binary. | CycloneDX, SPDX JSON |
| cdxgen (OWASP) | Multi-language source tree scanning across 20+ ecosystems. | CycloneDX |
| OSS Review Toolkit (ORT) | Source-tree analysis with an opinionated licence and policy workflow; strong for OSPO-style review. | SPDX, CycloneDX, custom evaluator reports |
| Microsoft SBOM Tool | Windows-oriented, CI-friendly generation during build. | SPDX (and CycloneDX in recent releases) |
| SPDX SBOM Generator | Lightweight, language-package-manager-driven SPDX output. | SPDX |
| ScanCode Toolkit | Licence and copyright detection — the right tool when the licence data itself is unknown. | SPDX, CycloneDX |
| FOSSology | Server-side licence and copyright clearing for OSPO workflows. | SPDX (and report formats) |
Language libraries & build plugins
CycloneDX's biggest practical advantage is official, maintained libraries for each ecosystem. Wiring a BOM into the build is usually a one-line plugin rather than a post-hoc scan.
| Ecosystem | Option |
|---|---|
| Java / JVM | cyclonedx-maven-plugin, cyclonedx-gradle-plugin, cyclonedx-core-java |
| JavaScript / Node | @cyclonedx/cyclonedx-npm, @cyclonedx/cyclonedx-library |
| Python | cyclonedx-python-lib |
| Go | cyclonedx-go |
| .NET | CycloneDX .NET library |
| Rust | cyclonedx-bom crate |
| SPDX | spdx-tools (Python) and language-specific SPDX libraries; broader support exists for 2.x than for 3.x |
Converters & validators
cyclonedx-cli— the official CLI. Converts between CycloneDX formats and versions (including downgrading a 1.7 document to 1.6 for legacy consumers), validates against the schema, and merges/diffs BOMs.- SPDX tools — official Python tooling for generating, parsing, converting, and validating SPDX documents across formats.
- General SBOM conversion libraries — for programmatic pipelines that need to move between SPDX, CycloneDX, and intermediate graph representations. See the conversion caveats before relying on round-trips.
- Schema validation — validate against the published JSON Schema for your target version (SPDX: the spec
site's schema; CycloneDX:
cyclonedx.org/schema/bom-<version>.schema.json). Schema validity is necessary but not sufficient — it will not tell you the BOM is complete.
Consumers
| Tool | Role |
|---|---|
| Dependency-Track (OWASP) | The reference SBOM platform: continuous ingestion, component/vulnerability analysis across a portfolio, policy violations, and VEX management. |
| Grype (Anchore) | Vulnerability scanner that consumes an SBOM directly. |
| Trivy | Can scan from an SBOM instead of re-scanning an image — faster, and consistent with what you published. |
| Commercial platforms | Most supply-chain security and ASPM products ingest CycloneDX and SPDX; check whether they accept SPDX 3.x or only 2.3. |
A sane pipeline
- Generate during the build, not afterwards. Use the ecosystem plugin where one exists so the BOM reflects resolution, not a guess. Scan images/filesystems as a fallback.
- Enrich with the fields scanners miss: supplier, licence conclusions from a clearing tool, internal
component IDs, and the primary component in
metadata. - Assert completeness — fill in
compositions(CycloneDX) or completeness (SPDX). An SBOM that silently omits transitive dependencies is worse than no SBOM, because it reads as authoritative. - Validate against the schema and a minimum-elements check (supplier, version, purl, dependency edges, author, timestamp) in CI.
- Attach VEX as a separate document. Keep the inventory and the exploitability judgement decoupled — the inventory changes on every build, the VEX changes when analysts learn something.
- Publish and pin — ship the BOM with the artefact, version it, state the spec version explicitly, and (CycloneDX 1.7) set a TLP classification if it crosses an organisational boundary.
- Generate both formats from the same enriched source if you have more than one consumer, and re-generate rather than convert when you can.
Common failure mode: teams ship a scanner's raw output as their SBOM. It typically has no supplier, no completeness assertion, unresolved licences, and no author attribution — which means it fails the NTIA minimum elements and will not survive an audit. The enrichment step above is not optional.
Tool lists are representative, not exhaustive — the CycloneDX project tracks 220+ supporting tools. Versions retrieved from upstream release feeds on 2026-09-20.