What an SBOM is β€” in plain English

A Software Bill of Materials (SBOM) is a structured, machine-readable list of every component that makes up a piece of software. Think of it as an ingredients label for your application. It lists each open-source library, framework, runtime, and operating system package your software depends on β€” along with the version number, the licence, and a unique identifier for each component.

When someone asks "do you have an SBOM for this product?", they're asking: can you tell me exactly what is inside your software, in a format I can process programmatically? The answer should be a file β€” usually JSON β€” that can be ingested by vulnerability scanners, compliance tools, and procurement systems.

The food analogy: If your software were a jar of pasta sauce, the SBOM would be the ingredients list on the back. Not just "contains tomatoes" β€” but "San Marzano tomatoes (Italy, batch #4821), oregano (Turkey, organic certified), ..." Every component, traceable to its source.

A typical SBOM entry for one component looks like this:

CycloneDX component entry (simplified)json
{
  "type": "library",
  "name": "express",
  "version": "4.18.2",
  "purl": "pkg:npm/[email protected]",
  "hashes": [{
    "alg": "SHA-256",
    "content": "3f4cc6..."
  }],
  "licenses": [{ "license": { "id": "MIT" } }],
  "supplier": { "name": "TJ Holowaychuk" }
}

Why it matters for software security

Most modern applications consist of 5–20% original code and 80–95% open-source dependencies. A vulnerability in any one of those dependencies affects your application. Without an SBOM, you have no systematic way to know which of your applications are affected by a newly published CVE.

With an SBOM, the answer to "are we affected by CVE-2024-XXXX in library Y?" takes seconds: query your SBOM store, cross-reference against the CVE's affected versions, and get a list of every application and version that contains the vulnerable component.

The Log4Shell example: why SBOMs matter in practice

In December 2021, CVE-2021-44228 (Log4Shell) was published β€” a critical remote code execution vulnerability in Apache Log4j 2, a Java logging library used by a significant fraction of all Java applications in the world. CVSS score: 10.0. Actively exploited within hours.

The immediate question for every security team: which of our applications use Log4j 2.x? For organisations without SBOMs, answering this took days to weeks of manual investigation β€” trawling Maven dependency trees, asking individual teams, searching source code. For organisations with SBOMs, the answer took minutes: query the SBOM for any component matching pkg:maven/org.apache.logging.log4j/log4j-core with a version between 2.0 and 2.14.1.

Log4Shell changed everything. In the six months after Log4Shell, the number of enterprise software teams generating SBOMs grew faster than at any point since the term was coined. The pain of not knowing what was inside their applications was concrete and expensive.

CycloneDX vs SPDX: which format should you use?

There are two dominant SBOM formats. Both represent the same information but with different emphasis:

  • CycloneDX (OWASP) β€” designed for security use cases. Native support for vulnerability data, VEX statements, and service dependencies. Most vulnerability management tools (Grype, Trivy, OWASP Dependency-Track) consume CycloneDX natively. Available as JSON, XML, or Protobuf. Use this for security workflows.
  • SPDX (Linux Foundation / ISO 5962) β€” designed for licence compliance. The ISO standard, required by many government contracts and the EU Cyber Resilience Act. More mature tooling for licence analysis. SPDX 3.0 adds security profiles. Use this for regulatory submissions.

You can generate both at once. Syft and cdxgen can produce CycloneDX and SPDX from a single scan. Most teams generate CycloneDX internally and SPDX for external distribution.

Generate your first SBOM in under 5 minutes

Generate SBOM with Syftshell
# Install Syft
$ brew install syft
# or: curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh

# Generate from your source directory
$ syft dir:. -o cyclonedx-json > sbom.cdx.json

# Generate from a Docker image
$ syft myapp:latest -o cyclonedx-json > sbom-image.cdx.json

# Generate in SPDX format (for compliance)
$ syft dir:. -o spdx-json > sbom.spdx.json

# See what was found
$ cat sbom.cdx.json | jq '.components | length'
247   # 247 components found

# Immediately scan the SBOM for vulnerabilities
$ grype sbom:./sbom.cdx.json

SBOM compliance requirements you need to know

  • US Executive Order 14028 (2021): Requires SBOM for software sold to the US federal government. The NTIA published minimum element requirements: supplier name, component name, version, unique identifiers, dependency relationships, SBOM author, and timestamp.
  • EU Cyber Resilience Act (2024): Products with digital elements sold in the EU must include an SBOM. SPDX is the preferred format for regulatory submissions.
  • FDA medical device guidance: Medical devices with software must provide an SBOM as part of premarket submissions. CycloneDX recommended.
  • Customer contracts: Enterprise buyers increasingly include SBOM requirements in vendor security questionnaires and contract SLAs.

What to do with an SBOM after generating it

  1. Scan it for vulnerabilities immediately using Grype: grype sbom:./sbom.cdx.json. You'll likely find findings on day one.
  2. Store it alongside your release as a build artefact. Future vulnerability disclosures can be checked against historical SBOMs without rebuilding.
  3. Generate on every build in CI and diff against the previous SBOM to detect new dependencies being introduced.
  4. Publish to customers and regulators as required. OWASP Dependency-Track provides a hosted portal for SBOM management and distribution.

Generate and manage SBOMs automatically

AquilaX generates CycloneDX and SPDX SBOMs for every build, matches components against OSV and NVD, and provides VEX-aware vulnerability reports β€” all from a single CI integration.

Explore SCA and SBOM β†’