Generating an SBOM is the easy part. Getting the right SBOM to the right consumer at the right time, with current vulnerability context layered on top, is where most programs quietly fall over. The last twelve months have moved the industry from "produce an SBOM" toward "operate an SBOM distribution surface," and the difference is consequential.
This post is a working engineer's view of what is actually deployed in production today. We cover the Transparency Exchange API (TEA), the maturing VEX ecosystem around CSAF and OpenVEX, and the sidecar attestation patterns that have stabilized into something approaching a default. Where the specs leave room, we flag the choices that have held up under operational load.
Why is direct SBOM attachment failing at scale?
The original distribution model, ship the SBOM alongside the artifact in the registry, works fine for a single team with a handful of images. It collapses when a regulated customer needs every SBOM for every running version across a fleet, and when those SBOMs need to be re-evaluated against new CVEs published last night. The artifact is immutable; the security context attached to it is not. Pulling a 40MB CycloneDX document from a registry every time a scanner needs to recheck reachability is wasteful and brittle.
The deeper failure is that the registry was never designed to be a security inventory. It indexes by digest, not by package or CVE, so any query like "which of our running services contain log4j 2.x" requires fetching every SBOM and parsing it client-side. At fleet scale that is minutes of latency per query, and it forces every consumer to reimplement the same indexing logic.
What does TEA actually solve?
The Transparency Exchange API, now in late draft at OWASP, provides a standardized HTTP surface for fetching SBOMs, VEX statements, attestations, and related metadata for a given product or component. The shape is deliberately narrow: a producer exposes a TEA endpoint, a consumer queries by product identifier, and the response is a discoverable index of available documents with their content types, signatures, and freshness metadata.
What TEA gets right is the separation between artifact identity and security metadata lifecycle. A vendor can update VEX statements for a shipped product without re-releasing the artifact, and consumers get a single endpoint to poll. It also handles the common case where one product is composed of many components, each with their own SBOM, by exposing a hierarchical index rather than a flat document dump. Early adopters in the medical device and automotive sectors have been driving the spec, and the pattern is now leaking into general enterprise software.
How are VEX statements being structured in practice?
VEX has converged on two serialization formats that matter: CSAF VEX for regulated and government-adjacent producers, and OpenVEX for the broader open-source and cloud-native world. The semantic content is similar, a statement that a given product is or is not affected by a given vulnerability, with a justification, but the operational ergonomics differ. CSAF carries the formality and tooling depth of the OASIS process; OpenVEX is lighter and integrates more naturally with cosign and in-toto attestation flows.
The pattern that has held up is generating VEX statements as a side effect of triage rather than as a separate authoring step. When a security engineer marks a CVE as not-affected in the issue tracker with a justification of "code-not-present" or "vulnerable-code-not-in-execute-path," a small automation emits the corresponding OpenVEX document and attaches it to the product's TEA index. The cost of generating VEX should be near zero per CVE, and any workflow that adds friction will collapse under sustained CVE volume.
What about sidecar attestations and signing?
Sidecar attestations, SBOMs and VEX statements signed and stored separately from the artifact they describe, are now the default pattern for any serious supply chain program. Sigstore's cosign attest workflow, with the SBOM as predicate and the image digest as subject, gives you a verifiable chain back to the build identity recorded in Rekor. Consumers verify the signature, check Rekor inclusion, and then trust the SBOM as authentic.
The operational gotcha is key rotation and revocation. Long-lived signing keys are a liability; the keyless flow with Fulcio short-lived certificates tied to OIDC build identity has emerged as the path of least regret for CI-generated SBOMs. For artifacts signed by humans or by long-running release engineering systems, hardware-backed keys with documented rotation procedures are still required. Mixing the two models in one product line is fine; just make sure your verification policy is explicit about which subjects accept which trust roots.
How do consumers query across thousands of products?
Large consumers, the kind with thousands of upstream suppliers, have converged on a pull-through indexing pattern. A central security platform polls each supplier's TEA endpoint on a schedule, ingests the SBOMs and VEX statements, and maintains a flat searchable index keyed by component PURL and CVE identifier. The index supports the queries the registry never could: which products contain which components, which CVEs are unaddressed across the fleet, which suppliers have stale VEX coverage.
This indexing layer is where the value of SBOM distribution actually accrues. Without it, you have a pile of documents that nobody queries. With it, you have a supply chain inventory that drives incident response, procurement, and renewal decisions.
How Safeguard Helps
Safeguard ingests SBOMs from registries, TEA endpoints, and direct uploads, normalizing CycloneDX, SPDX, and the various vendor variants into a single indexed view. Griffin AI runs reachability analysis on every ingested SBOM so consumers see the CVEs that actually matter for their deployed services rather than the full noise of the dependency tree. We consume OpenVEX and CSAF VEX statements automatically, suppressing not-affected findings without manual triage. Policy gates block builds that introduce reachable critical CVEs, and our TPRM scoring tracks supplier SBOM freshness and VEX coverage over time. The result is a supply chain inventory you can actually query, not a folder of documents you cannot.