VEX and SBOM context are replacing severity-only container decisions

At a glance

What this is: This is an Anchore analysis of why container security needs VEX and policy context, not just SBOMs and CVSS scores, to separate exploitable risk from noisy findings.

Why it matters: It matters because IAM, platform, and security teams increasingly need defensible decision logic for software supply chains, including how build-time findings map to runtime risk in containerised environments.

Context

Container security is not failing because teams cannot see vulnerabilities. It is failing because visibility alone does not explain whether a finding is exploitable in the way a workload is actually deployed, isolated, and used. That gap matters across software supply chains, where inherited layers, reused base images, and build-time scanning can create more data than decision-quality signal.

The article’s core concern is operational governance, not discovery. SBOMs tell teams what is present, but not whether a specific issue should block release, require exception handling, or be monitored in context. That is why the shift toward SBOM governance and VEX interpretation is material for security programmes that need consistent, auditable decisions rather than ad hoc judgments.

Key questions

Q: What breaks when container security relies on severity scores alone?

A: Severity-only controls fail because they ignore whether a vulnerability is actually reachable in the deployed workload. A critical issue may be harmless in a sealed code path, while a lower-severity flaw can sit in an exposed execution path. That mismatch leads to noisy build failures, missed risk, and inconsistent enforcement across container estates.

Q: When should teams prioritise VEX over raw vulnerability counts?

A: Teams should prioritise VEX when they need to decide whether a known issue is exploitable in the current runtime context. Raw counts are useful for inventory, but they do not show reachability, isolation, or configuration effects. VEX becomes most valuable when policy decisions must distinguish actionable risk from theoretical exposure.

Q: What do security teams get wrong about supplier SBOMs?

A: They often assume receipt equals assurance. In reality, many organisations receive SBOMs rarely or not at all, and even when they do, the data may lack depth, freshness, or consistent machine-readable structure. Supplier transparency has to be enforced, verified, and operationalised, not simply requested.

Q: How should organisations make container vulnerability decisions auditable?

A: They should record the evidence chain behind each decision, including the SBOM input, the VEX assertion, and the policy rule applied. That gives teams a defensible record for exceptions, reviews, and re-evaluation when runtime context changes. Auditable decisions are built from traceable logic, not from a final pass or fail label alone.

Technical breakdown

Why severity scoring breaks down in container workflows

CVSS and similar severity scores measure the technical seriousness of a vulnerability, not whether it can be exploited in a particular container deployment. In container environments, the same package may sit in an exposed execution path in one workload and remain unreachable in another because of runtime isolation, configuration, or application behaviour. That makes severity-only gating unreliable: it can over-block safe builds and understate risk where a lower-scored issue is actually reachable. The core technical problem is context loss. Scanners see the component, but they do not see the runtime path, trust boundary, or invocation pattern that determines exploitability. See the Container Security Guide.

Practical implication: Use exploitability context, not severity alone, when deciding whether a container vulnerability should block release.

How SBOMs become operational data rather than static inventory

An SBOM is most useful when treated as a living dataset that can be queried across build, deployment, and runtime stages. In this model, the SBOM is not just a compliance artifact listing dependencies. It becomes the reference layer that shows which components are reused across images, which inherited libraries are shared, and how vulnerabilities propagate through layered builds. That supports more consistent decision-making because teams can trace exposure across multiple workloads instead of evaluating each image in isolation. The technical shift is from one-off reporting to continuous correlation between component identity, vulnerable package presence, and deployment context. See the SBOM Guide.

Practical implication: Persist SBOM data across the pipeline so vulnerability decisions can be correlated to the exact image and workload context.

What VEX adds to the decision pipeline

VEX adds exploitability assertions to vulnerability data. It does not replace SBOMs or scans, but tells downstream policy engines whether a known issue is exploitable under specific conditions such as function reachability, isolation, or configuration. That makes VEX a context signal rather than a new finding source. In practical terms, VEX works best when evaluated at the decision point, not parked as separate metadata. Without that integration, teams still treat every vulnerability as equally actionable. The article’s SRIL layer is essentially a normalisation step that translates SBOM and VEX inputs into policy-readable output, so different pipelines can apply the same logic consistently. See the Software Supply Chain Security Guide.

Practical implication: Feed VEX into policy enforcement at the point of decision, not as a separate record that teams interpret manually.

NHI Mgmt Group analysis

Severity-first container governance is a poor proxy for exploitable risk. The article shows that teams are still using scores to decide what matters, even though runtime context is what determines exposure. In practice, that creates both false positives and blind spots, especially where shared base images and layered dependencies obscure the real attack surface. The governance failure is not lack of data, but lack of decision logic that matches how containers are actually used. Practitioners should treat score-based gating as an input, not the control outcome.

Decision-centric security is the more defensible model for container programmes. SBOMs and VEX only create value when they support a repeatable, auditable decision chain from component to exploitability to policy action. That is the kind of governance structure compliance teams and engineering teams can both defend. The article’s strongest insight is that maturity is not more scanning, but better use of the artefacts already collected. Practitioners should build policy traceability around runtime context, not just scan output.

SBOM governance needs an interpretation layer, not just more inventory. The Safety Relevance Interpretation Layer is a useful named concept because it captures the real gap: organisations can generate SBOMs and ingest VEX, yet still lack a uniform way to turn that data into policy-actionable decisions. That gap is especially visible in container estates where identical components can carry different risk depending on workload context. Practitioners should standardise the translation from vulnerability evidence to enforcement logic.

Container security programmes should stop treating vulnerability context as an exception path. When exploitability is handled manually, teams create inconsistent outcomes across platforms, environments, and owners. The article argues for embedding context into normal policy flow, which is the right direction for scalable governance. That approach reduces exception sprawl and makes review decisions defensible over time. Practitioners should make contextual evaluation part of the default control plane rather than a manual override process.

From our research library:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• Read next: Software Supply Chain Security Guide

What this signals

Decision-centric container governance: the next phase of container security is not more vulnerability discovery but better evidence handling at the point of control. Teams that keep SBOM, VEX, and policy logic separate will continue to create inconsistent outcomes, especially where reused layers and shared base images blur the boundary between inventory and exposure.

The practical shift is toward controls that evaluate exploitability alongside deployment context, so policy engines can make the same decision every time the same evidence appears. That is why software supply chain security programmes increasingly need a traceable interpretation layer, not just another scan feed.

For practitioners

• Adopt context-aware build gating Base release decisions on exploitability context as well as severity, so unreachable vulnerabilities do not trigger unnecessary pipeline failures while reachable ones still block promotion.
• Persist SBOMs as queryable lifecycle artefacts Store SBOM data in a form that can be reused across build, deploy, and runtime decisions rather than treating it as a compliance snapshot created once per release.
• Encode vulnerability policy as code Move prioritisation rules into pipeline enforcement so teams apply the same thresholds and exception logic consistently across images, services, and environments.
• Preserve decision traceability Record the vulnerability data, VEX context, and policy rule that led to each allow or block outcome so later reviews can explain why a release passed.

Key takeaways

• Container security programs can see more than ever, but visibility alone does not tell teams which vulnerabilities are exploitable in a given runtime context.
• SBOMs become operationally useful when they are treated as persistent evidence that can be correlated across build, deployment, and runtime decisions.
• VEX and policy logic together reduce noise, improve prioritisation, and make vulnerability decisions easier to defend over time.

Related NHI Mgmt Group resources: Software Supply Chain Security Guide · SBOM Guide · CI/CD Pipeline Identity Security Guide · Container Security Guide

Key terms

• SBOM: A software bill of materials is an inventory of components, dependencies, and often transitive packages used in an application or build. It gives defenders visibility into what entered the software supply chain and helps spot risky or newly introduced dependencies.
• Vex: VEX, or Vulnerability Exploitability eXchange, is a way to state whether a known vulnerability is exploitable in a specific product, build, or deployment. It helps security teams avoid treating every matching CVE as equally urgent and improves prioritisation in software supply chains.
• Policy as Code: Policy as code stores authorization logic in version control and evaluates it through testable, reviewable rules. For agent governance, it makes runtime decisions reproducible and measurable, which is critical when actions can be triggered by untrusted content and executed at machine speed.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.