Software Bill of Materials

What an SBOM Contains

At minimum, an SBOM lists each component with enough detail to identify it reliably, typically including the supplier, component name, version, a unique identifier, its relationship to other components, the author of the SBOM data and a timestamp. More detailed SBOMs add licenses, hashes and the full dependency tree, including transitive dependencies.

Common SBOM Formats

• SPDX. A Linux Foundation standard, also published as an international ISO/IEC standard.
• CycloneDX. An OWASP standard designed for security use cases, including vulnerability and dependency data.

Both are machine-readable, so SBOMs can be generated in CI, stored with each release and queried by tools.

Why SBOMs Matter

When a widely used library is found to be vulnerable, the first question is "where do we use it?" Without an inventory, answering that means searching repositories by hand. With SBOMs, it becomes a query. SBOMs also support procurement and compliance, and U.S. government guidance has pushed software suppliers to provide them.

SBOM Limitations

An SBOM tells you a component is present, not whether its vulnerable code is used. A long SBOM can still produce a long list of theoretical exposures, so it works best paired with reachability analysis and a way to track remediation. It also needs to be regenerated with every build, because a stale SBOM is a false sense of coverage.

How Nullify Uses Component Inventory

Nullify brings supply chain risks into the same prioritized backlog as code, secrets, cloud and pentest findings, and can run campaigns such as upgrading CVE-affected dependencies across many repositories. See how Nullify runs dependency campaigns.