What is an SBOM, and what is VEX?

Every application is mostly other people's code: open source libraries, the packages in its base image, the runtime it ships with. When a serious flaw turns up in one of those components, the first question is always the same: do we use it, and where? A software bill of materials answers the first half. VEX answers the question that comes after it: are we actually affected?

What an SBOM is

A software bill of materials, or SBOM, is a machine-readable list of the components that make up a piece of software, with their versions and the relationships between them, much like the parts list for a physical product.

The US National Telecommunications and Information Administration set out the minimum elements of an SBOM in 2021, following a US executive order on software supply chain security. For each component, an SBOM should name:

• the supplier;
• the component name and version;
• other unique identifiers, such as a package URL;
• its dependency relationships;
• the author of the SBOM data, and a timestamp.

It should also be generated automatically, in a machine-readable format, and kept current as the software changes. CISA now leads much of the community work on SBOMs.

SPDX and CycloneDX

Two formats dominate:

• SPDX, from the Linux Foundation, began as a way to record licenses and grew into a full SBOM format. Version 2.2.1 is published as an international standard, ISO/IEC 5962:2021, and SPDX 3 adds profiles for security and other uses.
• CycloneDX, from OWASP, was designed for security use from the start and also describes services, hardware and vulnerabilities. It is standardized by Ecma International as ECMA-424.

Both carry the minimum elements. Which one you need usually depends on who asks for it.

Where SBOMs come from

An SBOM can describe software at different moments: from its source and lockfiles, from the build, or from what is actually installed and running. The later the moment, the closer the list is to what is really deployed, and the more it can say about which components are actually used.

What VEX is

An SBOM alone creates a new problem. Compare its components with a vulnerability database and you get a long list of matches, many of which don't affect you: the vulnerable function is never called, the affected feature is switched off, or the component is present but never loaded.

VEX, the Vulnerability Exploitability eXchange, is a way to say so, in a machine-readable statement about one vulnerability in one product. CISA's minimum requirements for VEX define four statuses:

VEX can be written as OpenVEX, a small format built for exactly this, inside CycloneDX, or in SPDX 3's security profile.

Why both matter

Together, an SBOM and VEX let a supplier publish what is in a product and what they know about its exposure, and let a customer's tools filter out what doesn't apply. The quality of the VEX statements is what makes the difference: a "not affected" without evidence is a claim, not an answer.

How Tracix handles it

Software inventory in Tracix builds the list from what is running.

• From running applications. On Linux hosts, in containers and Kubernetes pods as well as host services, the collector reads each application's own package metadata and files: OS packages, Go and Rust binaries, Node.js, Python, Java, .NET, Ruby, PHP and more, and SBOMs that ship with the application. It never runs what it inspects and downloads nothing, and anything it can't read is reported as a coverage gap, never as "no components".
• Runtime evidence. Each component carries labels for what was observed: whether a process mapped it, loaded it or opened its files, whether execution reached a probe, or whether it appeared in a CPU profile. "Not observed in this window" never means unused or safe.
• Matches against advisories. Tracix checks every release in the inventory against OSV advisories, with KEV and EPSS beside each CVE, and shows each match with the runtime evidence of the affected components. Evidence can raise a match; nothing observed never lowers one.
• VEX written by people. A match is not a VEX statement. Your team writes each assessment for one vulnerability in one exact build, picking from its matched advisories, and only a not affected or fixed assessment closes a match. Runtime evidence can support an assessment but never decides it.
• Exports. A service's inventory exports as CycloneDX 1.7, SPDX 2.3 or SPDX 3.0.1, with VEX as OpenVEX 0.2.0, CycloneDX VEX or the SPDX 3.0.1 security profile. An SBOM with VEX lists the matched advisories, without analysis, beside your statements. Every document is checked against its format's schema before it downloads, and Tracix never produces an empty VEX document, because it would read as a clean result.

The limits, plainly: Tracix matches the inventory the collector reads, and doesn't scan images or registries. It doesn't check yet whether the vulnerable function runs. Packages from distributions OSV doesn't cover, such as Fedora and Amazon Linux, read not assessed, never clean.

Software inventory and SBOM export covers turning it on, reading matches and writing assessments.