Software bill of materials (SBOM)

What is in an SBOM?

An SBOM lists every component in a build and enough identifying data to match each one against vulnerability and license databases. Executive Order 14028 compares it to the ingredient list on food packaging, which is accurate: it tells you what is inside, not whether any of it will hurt you.

The baseline for "enough data" is the NTIA's Minimum Elements for a Software Bill of Materials, published July 12, 2021 under EO 14028. Its seven data fields are supplier name, component name, version, other unique identifiers, dependency relationship, author of the SBOM data, and timestamp. It also required automation support (a machine-readable format) and set practices for how often SBOMs are regenerated, how deep they go, and how known unknowns are marked.

On July 29, 2026, CISA and seventeen partner agencies, including the NSA, FBI, Germany's BSI and France's ANSSI, published the 2026 Minimum Elements, which replaces the NTIA document. It keeps the 2021 core and adds, among others:

• Component hash value and algorithm, so a component can be matched by content and not only by a name that anyone can claim.
• Component license.
• SBOM tool name and version, data format name and version, and author signature.
• SBOM generation context, the lifecycle phase the SBOM was produced in, such as "before build" from source or "after build" from binary analysis. The two can list different components.

It also drops the separate Access Controls element, folding it into Distribution and Delivery.

SPDX vs CycloneDX: which format?

Both are machine-readable and both satisfy the minimum elements, so choose by what your consumers and tools accept. SPDX, from the Linux Foundation, started as a license-compliance format and is an ISO standard (ISO/IEC 5962:2021); SPDX 3.0 is the current major version. CycloneDX, an OWASP project, started from security use cases, is standardized as ECMA-424, and reached version 1.7 in October 2025. CycloneDX also carries VEX, services and hardware in the same schema.

A minimal CycloneDX document with one component, using an invented package:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.7",
  "serialNumber": "urn:uuid:00000000-0000-4000-8000-000000000001",
  "version": 1,
  "metadata": {
    "timestamp": "2026-09-01T12:00:00Z",
    "lifecycles": [{ "phase": "build" }],
    "component": { "type": "application", "bom-ref": "demo-app", "name": "demo-app", "version": "2.4.0" }
  },
  "components": [
    {
      "type": "library",
      "bom-ref": "pkg:npm/example-yaml-parser@1.8.2",
      "supplier": { "name": "Example Parsers Project" },
      "name": "example-yaml-parser",
      "version": "1.8.2",
      "purl": "pkg:npm/example-yaml-parser@1.8.2",
      "hashes": [{ "alg": "SHA-256", "content": "<sha-256 of the package tarball>" }],
      "licenses": [{ "license": { "id": "MIT" } }]
    }
  ],
  "dependencies": [
    { "ref": "demo-app", "dependsOn": ["pkg:npm/example-yaml-parser@1.8.2"] }
  ]
}

The purl (package URL) is the field that does the work: vulnerability databases such as OSV key advisories by ecosystem and package name, and a correct purl is what lets a scanner match this component to them.

What do EO 14028 and the Cyber Resilience Act require?

United States. EO 14028, signed May 12, 2021, directed guidance that includes "providing a purchaser a Software Bill of Materials (SBOM) for each product directly or by publishing it on a public website" (Sec. 4(e)(vii)). OMB memo M-22-18 turned that guidance into a secure-development self-attestation requirement for federal software vendors and let agencies ask for SBOMs. On January 23, 2026, OMB memo M-26-05 rescinded M-22-18 and M-23-16, so there is no longer a single government-wide requirement; an agency may still require an SBOM by contract when its own risk assessment calls for one.

European Union. The Cyber Resilience Act, Regulation (EU) 2024/2847, entered into force December 10, 2024. Annex I, Part II requires manufacturers of products with digital elements to "identify and document vulnerabilities and components," including by drawing up an SBOM "in a commonly used and machine-readable format covering at the very least the top-level dependencies." The dates, from Article 71:

The CRA does not require publishing the SBOM. It goes in the technical documentation and is handed to a market surveillance authority on a reasoned request; sharing it with users is the manufacturer's choice.

What is VEX?

VEX (Vulnerability Exploitability eXchange) is a statement from the supplier about whether a known vulnerability in a listed component affects the product. An SBOM scan of a large application returns many CVE matches; VEX is how the vendor says which ones matter.

OpenVEX defines four statuses: not_affected, affected, fixed and under_investigation. A not_affected statement must carry either a free-text impact statement or, preferably for automation, a justification label: one of component_not_present, vulnerable_code_not_present, vulnerable_code_not_in_execute_path, vulnerable_code_cannot_be_controlled_by_adversary or inline_mitigations_already_exist. The third is usually established with reachability analysis.

{
  "vulnerability": { "name": "CVE-0000-00000" },
  "products": [{ "@id": "pkg:npm/demo-app@2.4.0" }],
  "status": "not_affected",
  "justification": "vulnerable_code_not_in_execute_path",
  "impact_statement": "demo-app never calls the parser's custom tag loader."
}

What does an SBOM not tell you?

An SBOM is an inventory. It says nothing on its own about:

• Exploitability. A listed component with a CVE may never be reached. Pair the SBOM with VEX, reachability data, EPSS and the KEV catalog to decide what to fix first.
• Your own code. First-party vulnerabilities, business logic flaws and misconfiguration do not appear in a component list.
• What actually shipped, unless the SBOM was generated from the final artifact. A source-time SBOM can miss vendored files, statically linked code and packages installed in a Dockerfile.
• Whether the component is genuine. A name and version prove nothing; hashes and signed build provenance do.
• Completeness. Tools disagree, especially on transitive, native and container-layer dependencies. Generate from more than one point in the build and compare.
• Runtime and SaaS dependencies. The services and APIs your software calls at runtime are outside a classic package SBOM.

Written by Parameter · Last reviewed September 27, 2026