SBOMs tell you which components are present. VEX tells you whether a supplier says a product is affected. Neither can prove whether a vulnerable path executed in your cluster, which is why platform teams should separate supply-chain assertions from runtime evidence.
Senior Platform Engineer
SBOM and VEX data improve software transparency, but they answer supplier and component questions more reliably than deployment questions. For Kubernetes operators, the missing step is proving how a vulnerable component behaves inside a live cluster: whether the code is present in the running image, reachable by real traffic, and exposed through the service graph that exists in production.
An SBOM is an inventory of software components. It gives security and platform teams a structured way to identify which packages, versions, and dependencies may exist in an image or product and to connect newly disclosed CVEs back to affected software.
VEX adds a supplier assertion on top of that inventory. It can say a product is affected, fixed, under investigation, or not affected, and formats such as OpenVEX and CycloneDX VEX make those statements machine-readable enough to reduce false-positive triage when the supplier has already completed impact analysis.
Kubernetes risk is shaped by deployment context that an SBOM or supplier-issued VEX document does not fully capture on its own. A package can exist in an image but stay outside the executed path, or a component marked not affected upstream can still require local review if your downstream packaging, configuration, or service exposure differs from the supplier's assumptions.
CISA's guidance on when to issue VEX explicitly warns consumers to evaluate whether upstream status can be inherited downstream. That matters in clusters because the exploit question is rarely just whether a dependency exists. It is whether the vulnerable code is reachable in this workload, under this configuration, on this network path, with this identity and traffic pattern.
The same vulnerable library can have very different operational risk across two namespaces. One workload may never invoke the vulnerable function, while another may expose it on an internet-facing request path behind a broadly scoped service account. SBOM and VEX data are still useful in both cases, but neither replaces the need to verify what the workload actually does after start.
This is where runtime evidence becomes the deciding layer. Process lineage, loaded libraries, outbound connections, and service-to-service paths help teams distinguish a dormant dependency from a reachable one. That distinction is what keeps patch urgency, compensating controls, and release decisions tied to production reality instead of generic supply-chain metadata.
Use SBOM data to establish component inventory and affected-image scope. Use VEX to ingest supplier analysis and reduce known false positives. Then add runtime validation for the smaller set of findings that matter operationally: internet-facing services, high-value internal paths, privileged workloads, and incident-driven investigations.
The main goal is not to replace supply-chain practices. It is to keep each source of truth in its lane. Inventory should answer what is present. Supplier statements should answer what a producer believes about product impact. Runtime evidence should answer what your cluster executed, exposed, and can realistically propagate.
Read Next
Security
Pod Security Admission, CEL policies, and admission webhooks can reject unsafe manifests before they land in etcd. They still do not tell you what a workload executed after startup, which is why platform teams should separate preventive policy from runtime evidence.
Read article
Engineering
We instrumented 14 production clusters across three cloud providers to measure the real CPU and memory cost of eBPF-based runtime telemetry. Here is what we found — and where the numbers get interesting.
Read article
Security
A CVE with a 9.8 score that never executes in your environment is less dangerous than a 5.3 that runs on every request. We built a scoring model around this idea.
Read article
