What is an SBOM?
An SBOM is a machine-readable list of all the software components in an artifact. Think of it as an ingredient label for software: it tells you exactly what’s inside, at what version, and where it came from. SBOMs are increasingly required for compliance (NTIA minimum elements, Executive Order 14028, NIST guidance) and are the foundation of supply chain transparency.Why Root’s SBOMs Matter
Root doesn’t just generate SBOMs from an initial scan — it updates them continuously as Root Patches are applied. When a vulnerability is patched, the SBOM reflects the new state of the artifact: the patched component version, the change that was made, and when it was applied. This means Root SBOMs always represent the current, post-remediation state of the artifact — not a snapshot from when it was first built.What Root SBOMs Include
- Complete component inventory — every OS package, language runtime, and installed library
- Version information for every component
- Patch records — which components were modified by Root, and how
- Dependency relationships — transitive dependencies are included, not just direct ones
Supported Formats
Root generates SBOMs in two industry-standard formats:| Format | Version | Notes |
|---|---|---|
| SPDX | 2.3 | Widely supported; used for compliance and government requirements |
| CycloneDX | 1.5 | Rich VEX integration; preferred for toolchain ingestion |
Accessing SBOMs
For container images (RIC): SBOMs are available via API or in the UI using the unique image id (rrtID):
Via the Root platform UI: Navigate to any subscribed image and download the SBOM directly.
Via the Root API: See API Reference for the /images/tags/{rrtID}/sbom endpoint.
Integrating Root SBOMs with Your Toolchain
Root SBOMs can be ingested by major vulnerability scanners and SBOM management platforms:- Grype / Syft — use Root’s SPDX or CycloneDX SBOM as input
- Trivy — supports SBOM input for offline scanning
- Dependency-Track — ingest CycloneDX SBOMs for continuous tracking
- Anchore — supports both formats