The most direct use of an SBOM is vulnerability management. With a component list in hand, affected assets can be looked up immediately when a new vulnerability is disclosed. But listing components in an SBOM brings along every past CVE for those components, creating a problem of exploding false positives. Vulnerability Exploitability eXchange (VEX) is what solves this problem.

SBOM-Based Vulnerability Tracking

The basic flow of tracking is simple. Each component in an SBOM is matched against vulnerability databases (NVD, CVE) using anidentifier such as PURL or CPE to map known vulnerabilities. A supplier can pre-map vulnerability information into an SBOM and provide customers with an enriched SBOM, while a consumer can link its own SBOM to vulnerability data through an API or data feed to set response priorities.

To increase effectiveness, a shift-left approach that moves checks earlier in development is recommended. Integrating security tools into the development pipeline and automatically analyzing SBOM data at early stages such as build and packaging catches vulnerabilities before release.

VEX: Sorting Out Exploitability

VEX is a document in which a manufacturer asserts “is this vulnerability actually exploitable in our product,” helping consumers make priority judgments. Where an SBOM answers “what is inside,” VEX answers “does a known vulnerability inside actually affect this product.” Even if a component has a vulnerability, it may be unexploitable if the affected code path is never invoked; VEX states this status explicitly, reducing unnecessary response effort.

A VEX document notates the vulnerability status of a specific product using the following four states.

• Not affected: No remediation is needed for this vulnerability.
• Affected: A fix or mitigating action is recommended.
• Fixed: The vulnerability fix is included in the given product version.
• Under Investigation: Whether the product is affected has not yet been confirmed and will be updated later.

VEX is not a single format; CSAF VEX, OpenVEX, and CycloneDX VEX coexist. CycloneDX is distinguished by expressing VEX natively within the format itself.

CSAF: Structuring Advisories

Common Security Advisory Framework (CSAF) 2.0 is a standard that structures security advisories in a machine-readable form, and it includes a VEX profile. OASIS approved it as a formal standard in November 2022. Where VEX communicates exploitability status, CSAF delivers a detailed advisory that includes a vulnerability description, affected versions, a severity assessment (CVSS score), and recommended mitigation steps.

The practical turning point for adoption was Red Hat. Red Hat’s Product Security team began publishing CSAF/VEX files for every CVE in its database in 2023, and has since moved to full production, publishing them on an ongoing basis.

Case Study: Log4Shell

The Log4j vulnerability (Log4Shell), disclosed in December 2021, is a case that shows how SBOM, VEX, and CSAF interlock.

Figure 1. The interplay of SBOM, VEX, and CSAF in the Log4Shell response(source: reconstructed from CERT-In technical guidelines. Retrieved 2026-06-14)

When the vulnerability was disclosed, maintainers issued a VEX stating the exploitable status, followed by a CSAF advisory containing the vulnerability description, affected versions, CVSS 10.0 (the highest severity), and mitigation steps. Organizations that included Log4j as a component integrated this VEX and CSAF data into their own SBOMs, identifying the affected parts of their systems and setting response priorities. The core point of this case is that, had an SBOM already been in place, “where is Log4j” could have been answered with a single query.

Sources

OASIS Open (2022).CSAF 2.0.https://www.oasis-open.org/2022/11/21/new-version-of-csaf-standard/. CISA.Vulnerability Exploitability eXchange (VEX).https://www.cisa.gov/sbom. OpenVEXhttps://github.com/openvex. NVD.CVE-2021-44228.https://nvd.nist.gov/vuln/detail/CVE-2021-44228. Red Hat (2023).VEX files now available. (All retrieved: 2026-06-14)

A Software Bill of Materials (SBOM) is a formal record of what components make up a piece of software and how those components connect within the supply chain. A US executive order compares it to the ingredient list on food packaging. Just as an ingredient list is the starting point for responding to allergies, an SBOM is the data layer on which vulnerability response, license management, and asset management all rest. An SBOM is not a security tool in itself, but without one, an organization cannot immediately answer the question, “Where in our product is this library used?”

This guide covers that data layer from beginning to end. Drawing on primary sources, it explains why SBOM has moved to the forefront of regulation and procurement, what standards and identifiers underpin it, in what order organizations adopt it and with what tools they automate it, how they manage vulnerabilities and licenses, and how they share it securely across the supply chain.

Intended Audience

• Security, development, procurement, and legal staff at organizations that develop or procure software
• Practitioners who must respond to the EU Cyber Resilience Act (CRA) or US federal procurement requirements
• Teams seeking to establish supply chain transparency and open source license compliance systems

Guide Structure

The guide is divided into eight sections. The earlier sections cover concepts, standards, and regulation, while the later sections cover the practicalities of adoption and operation. You can read only the sections you need.

Quick Starting Points

If you already understand SBOM and are looking for where to start, see4. Adoption Roadmap and8. Recommendations and Checklist first. If you are deciding which format and tools to use,2. Standards and Formats and5. Tools and Automation are good starting points. If your goal is regulatory compliance, check the jurisdiction-specific obligations in3. Regulatory Trends.

Sources and Editorial Basis

This guide is not a translation of any single document; it is a reconstruction that synthesizes current primary sources. It draws on the National Telecommunications and Information Administration (NTIA)’s 2021 minimum elements and its update by the Cybersecurity and Infrastructure Security Agency (CISA) — the 2024Framing Software Component Transparency, Third Edition, and the 2025 draft revision of the minimum elements — as well as the SPDX and CycloneDX standard specifications, the EU Cyber Resilience Act (Regulation (EU) 2024/2847), and the supply chain security guidelines of India’s CERT-In and Korea. The first edition began as a translation of CERT-In’s SBOM technical guidelines; the current edition updates that framework with the sources above and broadens it to a general practitioner’s perspective.

Every factual claim is cited to a primary source, and the materials cited were accessed on June 14, 2026.

Author :Haksung Jang