From SBOM to Actionable Signal: Which Vulnerabilities Should You Actually Fix?

Last month, I watched a team burn an entire sprint on a scanner report. Forty-seven CVEs across three services. They patched what they could reach, filed the rest as accepted risk with no expiry, and moved on. Two weeks later, the one finding that mattered was still in production, unpatched — a deserialization path through jackson-databind@2.13.1 in a service processing external webhooks. Nobody had checked whether the vulnerable code was reachable.

The scanner did its job: it matched component versions to known vulnerabilities. What it could not answer was which artifacts were deployed, which code paths were reachable, or which services an attacker could actually reach. An SBOMSoftware Bill of MaterialsA machine-readable inventory of the components and dependencies included in a software product. is inventory, not a security tool. Treating inventory as a verdict is how you patch the wrong things and miss the right ones.

An inventory is not a security decision

The NTIA minimum-elements report from 2021 defines an SBOM as a formal record of software components and their supply-chain relationships. CISA’s 2026 SBOM guidance extends the definition to include coverage, known unknowns, update frequency, and validation. Both describe inventory practices. Neither tells you whether a flagged component is the artifact running in production right now.

A scanner match answers one question: does the available inventory associate a component version with a known vulnerability? Before you can act, you need five more answers:

1. Artifact and deployment. Is this the exact artifact that was built, and where is it running?
2. Exposure. Can an attacker reach the relevant service or input?
3. Exploitability. Can the vulnerable code execute in this configuration, and are exploit preconditions present?
4. Controls. Is a compensating control effective and still active?
5. Accountability. Who is making this decision, on what evidence, and when does it expire?

Treating the scanner match as if it answered all five creates noise you cannot act on. Treating an unresolved match as safe creates a gap you cannot see. I’ve seen both failure modes cost more than the vulnerability itself.

From inventory to decision

Here is the operating model I use to connect those questions. It is practical guidance built from the standards and research cited throughout this article, not a scoring engine or a proof of safety.

Each row answers a different question. No single input is a verdict. unknown is a valid outcome when a required join or assessment is missing.

Six evidence classes

Identity, provenance, and deployment

1. Component identity. Start with package identity, version, supplier, dependency relationship, and the SBOM’s generation context. Record declared coverage and known unknowns. If a finding’s component cannot be matched reliably, keep it unresolved rather than suppressing it.

2. Artifact identity and provenance. Bind the component to an immutable artifact digest, then verify provenance: check its signature, subject digest, builder identity, and trusted roots. SLSA Build L3 gives you confidence that provenance came from a hosted, hardened build platform with isolation and signing-secret protection. It does not certify that source code is secure, dependencies are benign, or the artifact is safe to run. SLSA’s verification guidance makes the trust boundary explicit: assurance depends on trust in the build platform itself. The question is not “Do we have an L3 label?” It is “Did we verify provenance for this digest against a builder we trust?”

3. Deployment evidence. Observe which digest is running, in which environment, on which asset, at what time. Use deployment or runtime inventory as an independent source rather than assuming a registry tag or release manifest represents current production state. This step varies across containers, hosts, serverless functions, mobile applications, embedded devices, and SaaS services. Record the observation mechanism and timestamp so reviewers know what the evidence covers.

Exposure, supplier context, and reachability

4. Exposure evidence. Describe how an adversary could interact with the deployed artifact: ingress paths, authentication boundaries, service privileges, configuration, data flows, and network controls. Exposure is not permanent. A routing change, new integration, or disabled control can invalidate a previous assessment. Preserve these assumptions as reassessment triggers rather than burying them in ticket comments.

5. Vulnerability status and VEXVulnerability Exploitability eXchangeA security advisory that communicates whether vulnerabilities affect a specific product and why.. CSAF 2.1 defines VEX product-status assertions: fixed, known_affected, known_not_affected, and under_investigation, with bounded justifications such as component absence, vulnerable code absence, or inline mitigations. VEX adds attributable, product-specific context. Schema conformance does not prove the producer’s assessment is true or current — I examine these justification flags in VEX: Documenting “Not Exploitable”. Before using an assertion, match the product and version and retain its issuer, timestamp, status, justification, and revision history. Different justifications demand different review triggers: “component not present” is a different commitment than “inline mitigation exists,” where the vulnerable code is still installed.

6. Reachability and exploitability context. Reachability is a signal, not a verdict. A study on static vs. dynamic analysis of Java dependencies showed this clearly: static analysis missed dynamic behavior like reflection, while dynamic analysis only covered the paths exercised by existing tests. Neither method alone can prove exploitability or safety. For each result, record the method, analyzed artifact, environment, and coverage. Keep “unknown” as an honest outcome.

Outcomes

When the evidence supports a decision, the outcome is one of three.

Remediate when evidence shows vulnerable code in a deployed artifact and exposure makes delay unacceptable. Record the target artifact, owner, expected completion, validation plan, and rollback path. After the change, verify the newly deployed digest rather than closing the finding because a source branch changed.

Deprioritize with justification when current evidence supports lower urgency: the component is absent from the deployed artifact, or the vulnerable code does not execute under bounded analysis. This is not suppression. Store the evidence and specify what would reopen the decision: a new artifact, changed exposure, revised VEX, or expiry of the review period.

Temporarily accept risk when the risk remains but remediation is deferred for a documented reason. This needs an accountable owner, scope, rationale, controls, expiry date, and planned next action. Acceptance is a governance decision, not a claim that the vulnerability is harmless. It should expire into review rather than becoming an indefinite exception.

The decision record

A decision record binds all of this together. Here is what yours should contain:

Category	Fields
Identity	Decision ID, vulnerability/advisory ID, component identity, artifact digest
Provenance and deployment	Provenance reference, verification result, trusted builder, deployed asset, environment, observation time
Exposure and controls	Exposure evidence, compensating controls, VEX issuer, status, justification, version, timestamp
Reachability	Method, coverage
Decision	Rationale, accountable owner, timestamp, expiry or reassessment trigger, links to raw evidence

The operating workflow

From signal to evidence:

1. Normalize the finding. Resolve advisory and package identifiers without discarding ambiguity.
2. Bind to an artifact. Match the component to an immutable digest and verify provenance.
3. Confirm deployment. Establish whether that digest is running and where.
4. Evaluate exposure. Document attacker paths, privileges, configuration, and controls.

From evidence to decision:

1. Add attributable context. Match current VEX statements and threat intelligence to the precise product and version.
2. Assess reachability. Keep static possibility, runtime observation, and exploit preconditions separate.
3. Record the decision. Choose an owner, due date or expiry, and explicit review triggers.
4. Revalidate after change. Confirm the deployed digest and reopen decisions when their assumptions change.

Start with one production service and one vulnerability class. Building a DevSecOps Evidence Chain walks through the manual version of this for a single finding. Measure time from finding to evidence-backed decision, proportion of decisions with complete records, overdue acceptances, and decisions reopened when context changed. Do not borrow percentage promises from vendor case studies. Your own baseline is the only number that means anything.

Regulatory context requires a separate track

An evidence chain supports incident and vulnerability operations, but it does not determine legal scope or satisfy reporting obligations. The EU Cyber Resilience Act covers connected software and hardware products on the EU market, with a general application date of 11 December 2027 and Article 14 reporting duties applying from 11 September 2026, including for qualifying products already on the market. For actively exploited vulnerabilities in in-scope products, Article 14 sets staged notifications: early warning within 24 hours, vulnerability notification within 72 hours, and a final report no later than 14 days after a corrective measure becomes available. These are not generic remediation deadlines, and the vulnerability timeline should not be merged with the separate severe-incident timeline. This summary is informational, not legal advice. Product scope, triggers, and obligations require fact-specific legal review. Define an escalation path so that a potentially reportable case reaches qualified legal and security owners promptly. I cover the operational readiness implications in What the Cyber Resilience Act Changes for Software Vulnerability Management.

Where AI helps and where it does not

AI agents can correlate identifiers, summarize evidence, draft rationale, propose patches, and generate tests. In the peer-reviewed CVE-Bench study, the evaluated SWE-agent setup repaired at most 21% of 509 real-world CVEs in its benchmark environment. That demonstrates both assistance potential and substantial residual failure. It does not establish performance for every agent, production safety, regression rates, or cost savings.

Treat generated patches as candidates. You validate artifact identity, evidence freshness, threat assumptions, patch correctness, and regression tests before anything reaches production. An agent should not autonomously suppress a finding, attest non-exploitability, accept risk, or deploy a patch.

Pick the noisiest service in your portfolio and run its next vulnerability through the six evidence classes. If you cannot confirm which digest is deployed, start there. If you cannot describe the attacker’s path to the service, start there. Build one complete decision record and hand it to a colleague. If they can reconstruct what was known, what was uncertain, and what will trigger a re-review without asking you a single question, you have something worth scaling.