Software Supply Chain Security / Component Assurance

Software Bill of Materials (SBOM) & VEX

A modern software artifact rarely consists solely of proprietary code; it is an assembly of open-source libraries, third-party frameworks, and transitively inherited dependencies. A Software Bill of Materials (SBOM) provides a machine-readable inventory of software components and their supply-chain relationships. However, possession of an SBOM alone does not equal vulnerability management—actionable remediation requires continuous vulnerability correlation and Vulnerability Exploitability eXchange (VEX) status assertions.

SBOM and VEX architecture: minimum-element baselines, SPDX and CycloneDX formats, purl identifiers, and exploitability assertions

Minimum elements: the NTIA 2021 baseline and its CISA 2026 replacement

In response to Executive Order 14028, the National Telecommunications and Information Administration (NTIA) published the 2021 Minimum Elements for an SBOM. Its seven data fields are the part most often quoted:

1. Supplier name: organization or author creating the software component.
2. Component name: standardized title of the library or module.
3. Component version: precise build or semantic version tag.
4. Other unique identifiers: Package URL (purl), CPE (Common Platform Enumeration), or cryptographic hash.
5. Dependency relationship: explicit graph mapping showing direct and transitive relationships (e.g. component A depends on component B).
6. SBOM author: entity or tool generating the SBOM metadata record.
7. Timestamp: date and time of SBOM generation.

Those seven fields are one of three NTIA elements, not the whole baseline. The other two are automation support (expressing the data in predictable, machine-readable formats so it scales across organizational boundaries) and practices and processes (how SBOMs are requested, generated, distributed, and updated). Shipping all seven fields satisfies one element of three.

On 29 July 2026, CISA, the NSA, the FBI, and sixteen international partner agencies published the 2026 Minimum Elements for a Software Bill of Materials. Its own version history records the NTIA 2021 document as version 1.0 of the same lineage and this as version 2.1, so it supersedes rather than supplements the 2021 baseline — while stating that it preserves that document’s core principles.

Read the strength correctly. The document is written in recommendation voice: “should” appears roughly 150 times, “shall” not at all, and the two uses of “must” are descriptive rather than normative. These are elements an SBOM should meet, published as joint guidance. A binding obligation to produce them comes from a contract or a regulation — the EU Cyber Resilience Act, for example — not from this document.

The structure changed. The 2026 elements define two areas rather than NTIA’s three:

• Data fields — the data making up the SBOM document. Appendix A lists 17, up from NTIA’s seven.
• Practices and processes — how an entity engages with and documents the SBOM data.

Automation support is no longer a top-level area: it became machine-processable data and moved under practices and processes, and SWID tags were dropped from the list of data formats. The standalone access control element was removed, absorbed into distribution and delivery.

Ten data fields are new: component hash value, component hash algorithm, component license, and seven describing the SBOM document itself — SBOM author signature, SBOM tool name, SBOM tool version, SBOM data format name, SBOM data format version, SBOM version, and SBOM generation context (the lifecycle phase and data available when the SBOM was generated).

Four renames matter when mapping older tooling:

Two further changes affect how gaps are read. Known unknowns became explicitly identifying unknown information: where a data field is not populated, the SBOM author should state whether the value is unknown to them or is being deliberately withheld — the two now mean different things to a recipient. And timestamps should follow RFC 9557.

Both CycloneDX and SPDX provide native fields for nearly all of these, though the mapping differs by format.

SPDX vs. CycloneDX format comparison

Two open standards dominate industry adoption, originating from distinct engineering requirements. Both are now published international standards, through different bodies:

Note the version boundary: a requirement that cites “ISO/IEC 5962:2021” is naming SPDX 2.2.1 specifically, not the 3.x line.

Package URLs (purl) & universal identification

To eliminate ambiguity across ecosystem package managers (e.g. distinguishing a Python requests package from an npm requests package), SBOMs rely on Package URLs (purl):

pkg:type/namespace/name@version?qualifiers#subpath

Example: pkg:npm/%40angular/core@16.2.0

The npm scope @ prefix is always percent-encoded as %40, which leaves exactly one literal @ in the string — unambiguously the version separator. Package URLs provide a standardized string scheme for identifying software packages across heterogeneous ecosystems (npm, PyPI, Maven, Cargo, Go, Debian, RPM).

purl was standardized by Ecma International as ECMA-427 in December 2025, and the CISA 2026 elements cite that standard rather than the original repository. Treat ECMA-427 as the authority where a specification reference is needed.

Vulnerability Exploitability eXchange (VEX)

Scanning an SBOM against vulnerability databases (NVD, OSV) often yields dozens of CVE matches, leading to false-positive noise. A component may be present in the binary but its vulnerable code paths are never called or reachable.

VEX (Vulnerability Exploitability eXchange) is a class of machine-readable assertion that lets a software producer publish an authoritative exploitability status for a specific CVE in a specific product. It is not a single file format: the same statuses and justifications are carried by CSAF VEX, OpenVEX, and CycloneDX VEX. Choose the format your consumers’ tooling already ingests.

One CVE match against one SBOM component, and how each VEX status resolves it

The four VEX statuses

1. NOT_AFFECTED: the vulnerability is present in a component, but the product is not affected. A statement carrying this status must supply one of five defined justifications:
   • component_not_present
   • vulnerable_code_not_present
   • vulnerable_code_not_in_execute_path
   • vulnerable_code_cannot_be_controlled_by_adversary
   • inline_mitigations_already_exist
2. AFFECTED: the product is exploitable; the statement should carry an action statement describing the required remediation.
3. FIXED: a patched release exists. Confirm the version actually deployed is at or above it before closing the finding.
4. UNDER_INVESTIGATION: the producer is still analyzing. This is a temporary state, not an outcome — re-query it, and treat a stale one as unresolved rather than benign.

These status values and justification identifiers are consumed programmatically by deployment policy, so they must be written exactly as spelled above; a near-miss string silently matches nothing.

What an SBOM does not tell you

An SBOM is an inventory produced at one moment by one tool, and its limitations matter as much as its contents:

• Generation phase changes the answer. A build-time SBOM sees the dependency resolver’s view; a binary-analysis SBOM sees what actually shipped, including vendored and statically linked code the manifest never listed. The two disagree routinely. This is why the CISA 2026 elements record generation context and renamed “depth” to “coverage.”
• Transitive depth varies by ecosystem. Lock-file ecosystems yield near-complete graphs; C and C++ builds frequently do not, and system libraries pulled from a base image are often absent entirely.
• An identifier is not a match. Correlation quality depends on whether components carry a purl or CPE that the vulnerability database recognizes. Unmatched components produce silent false negatives, which are invisible in a way false positives are not.
• A VEX suppression is only as good as the producer’s analysis. An incorrect NOT_AFFECTED hides a real exposure indefinitely, and consumers have no independent way to check the reasoning behind it.
• An SBOM is a snapshot. It describes the artifact as built. It says nothing about what has been discovered since, which is why the correlation step belongs on a schedule rather than only at release time.

SBOM & VEX diagnostic checklist

The checklist below is a journal working model, not a published audit standard. When implementing an SBOM and component management program, evaluate these six criteria:

Primary references

• 2026 Minimum Elements for a Software Bill of Materials (SBOM) — read in full (v2.1, 29 July 2026, 23pp). Verified against the source document: the publication date and version history, the two-area structure, the 17 data fields in Appendix A Table 1, the ten new elements, the four renames, the removal of Access Control, the move of automation support to machine-processable data, RFC 9557 for timestamps, and the document’s use of “should” rather than mandatory language throughout.
• NTIA Minimum Elements for an SBOM (2021) — verified the seven data fields and the three-element structure of the original baseline.
• OpenVEX specification — verified the four status values and the five not_affected justification identifiers exactly as spelled.
• ECMA-424: CycloneDX Bill of Materials Specification — verified CycloneDX’s standardization status and the December 2025 edition.
• ECMA-427: Package URL (PURL) Specification — verified that purl is now an Ecma standard, as cited by the CISA 2026 elements.