Turn SBOM and VEX records into patch decisions

The same vulnerability identifier can describe different decisions

An SBOM and a VEX statement answer different questions. The SBOM describes software components and their relationships. VEX supplies an assertion about a particular product's status with respect to a vulnerability. A patch decision needs those records to match the software actually deployed and needs the consumer to evaluate the assertion's scope. The presence of a machine-readable not-affected statement is not, by itself, a reason to suppress every finding with the same vulnerability identifier. ^[1][2][3]

Consider two hypothetical container images that contain a package with the same name. A supplier issues a VEX statement covering one product version and build variant. The second image uses another build or enables a feature outside the statement's conditions. Matching only the package name or vulnerability identifier would erase that distinction. The consumer should keep the second image unresolved until the statement's identity and applicability are established, rather than inheriting the first product's conclusion.

This guide focuses on that applicability decision. It does not replace a vulnerability-priority queue, exploit evidence or an organization's patch policy. Once a finding is known to apply, other evidence can determine urgency. Conversely, a statement that a product is not affected needs its own supported scope even when the vulnerability is widely exploited elsewhere. Keep product applicability and remediation priority connected but separate.

The practical outcome is a reviewable decision record. It should identify the deployed artifact, vulnerability, statement, issuer, supporting reason, local conditions, decision owner and re-evaluation trigger. These fields make it possible to explain why a finding was retained, rejected or treated as not affecting a particular deployment. They also make it possible to reopen the decision when the software or evidence changes.

Use the formats as structured evidence, not as substitutes for technical judgment. CISA's VEX guidance explicitly recognizes that consumers can accept or reject assertions. A parser can confirm that a document follows a schema, while the application owner still needs to determine whether its statement is credible and relevant to the deployed product. Treat those as different checks in the workflow. ^[2]

Match the statement to the software you actually run

Begin with artifact identity. A product name and a moving release label may not distinguish the exact build under review. Record the image digest, package version, build identifier or other stable artifact reference available for the deployment, and connect it to the supplier's product identifier. The appropriate identifier depends on the distribution model. Do not invent a common identifier that every VEX format or package ecosystem is guaranteed to understand. ^[1][3]

An SBOM helps establish component presence and relationships, but its usefulness depends on scope and completeness. Determine which artifact the inventory describes and how it was produced. An inventory for a source repository, a build output and a deployed runtime may describe different sets of components. CISA's SBOM FAQ distinguishes inventory information from the additional vulnerability context supplied by VEX. Keep that distinction visible when a scanner finding and a supplier statement appear to disagree. ^[3]

Package URLs provide structured coordinates such as package type, namespace, name, version and qualifiers. Those coordinates are useful for matching, but the ecosystem rules still matter. A name alone can be ambiguous, and qualifiers or build variants can change which artifact a statement covers. Use the Package URL specification to interpret the identifier rather than stripping fields until two records appear equal. A normalized match should preserve relevant distinctions, not remove inconvenient evidence. ^[7]

Vulnerability version ranges need equally careful interpretation. The OSV schema represents affected packages and ranges using documented ecosystem and range semantics. A consumer should evaluate those fields in their intended context, rather than treating every version as an ordinary string that can be compared lexicographically. The article does not supply a universal version-comparison algorithm. Use the supported ecosystem-aware tooling and retain the matching inputs so the decision can be reproduced. ^[8]

The hypothetical two-image case exposes a useful acceptance check. Ask whether the statement identifies the actual product version or artifact, whether the component match uses the correct ecosystem and whether any build or configuration condition is preserved. If one answer is unknown, record the gap instead of converting it into a negative finding. An unresolved identity match is not the same as proof that a product is unaffected.

Also distinguish absence from incomplete inventory. If a component is not listed, the consumer needs to understand the SBOM's coverage before concluding that the component is absent from the delivered product. That does not mean every SBOM must be distrusted. It means that a statement based on component absence should be evaluated against the inventory and build evidence that supports that particular claim, with any limitations retained in the record.

Read the assertion and its supporting conditions

Read the VEX statement as a relationship among an issuer, product, vulnerability and status, with the metadata needed to interpret it. CISA's minimum requirements describe those elements and the supporting information associated with status. The statement's timestamp and identifiers matter because a later version can change the conclusion or scope. Preserve the exact statement version or an equivalent stable reference rather than storing only the latest page URL. ^[1]

OpenVEX v0.2.0 uses statuses including affected, not_affected, fixed and under_investigation. These are not interchangeable decisions. Under investigation means the status is unresolved; fixed refers to a product state in which a vulnerability has been addressed; not affected is an assertion about the specified product's relationship to the vulnerability. A local workflow should not collapse all non-affected labels into one generic suppression category. ^[4]

Supporting information is conditional. CISA's minimum requirements state that a not-affected status needs an impact statement when no justification is provided. OpenVEX's normative field rules likewise allow a justification or an impact statement for not_affected. Apply the actual rule in the relevant specification instead of relying on an oversimplified summary row or assuming that every status must contain identical fields. The format validator and the consumer's evidence policy may impose different checks. ^[1][4]

A justification can explain why the vulnerable component or code is absent, why the relevant code is not in an execution path, or why another documented condition prevents the vulnerability from affecting the product. CISA's status-justification guidance defines these categories. The consumer still needs to understand the assertion's factual basis. A concise machine-readable reason is useful for automation, but it should not hide a condition that the local deployment does not satisfy. ^[2]

Formats express these concepts differently. CycloneDX supports vulnerability exploitability information associated with the software context, while CSAF provides an advisory framework and a VEX profile. OpenVEX has its own document and statement structure. Do not assume that changing a status field name is sufficient to translate every record between formats. Use the relevant specification and preserve identifiers, scope and supporting detail when a tool transforms the information. ^[4][5][6][9]

Treat authenticity and applicability separately. A statement from an accepted issuer can still describe a different product version or a supported configuration unlike the one deployed locally. Conversely, a technically plausible claim from an unknown source may not meet the organization's evidence policy. Record both judgments. CISA's consumer-acceptance framing allows the workflow to distinguish trusted provenance from a technical conclusion the consumer has actually evaluated. ^[2]

If the supplier's detailed analysis is unavailable, say what evidence the organization accepted and why. The article does not require pretending that every consumer can independently reproduce every supplier assessment. It requires an honest record of the reliance placed on the assertion, the local checks performed and the uncertainty retained. A risk acceptance based on limited evidence should not be relabeled as an independently proven absence of vulnerability.

Follow two builds through the same assertion

Use a deliberately synthetic case to follow the decision. Example Preview Supplier distributes version 2.4.1 in two builds, standard and extended. Both inventories list preview-parser 4.2. The invented vulnerability identifier EXAMPLE-VULN-01 concerns a legacy import function. Statement version 7 names only the standard build and asserts not_affected with the justification vulnerable_code_not_present. The package, versions, issuer and vulnerability in this case are fictional; they do not describe a real advisory or supplier assessment.

The release owner first maps the supplier's standard-build identifier to the immutable digest of deployed image A. The inventory belongs to that image, not merely its source repository. The supplier statement says the standard build excludes the legacy import function during compilation. The reviewer records that specific reason and the supplier build evidence it relies on. The statement is not interpreted as saying that every product containing preview-parser 4.2 is unaffected. CISA's justification categories distinguish an included component from the presence of its vulnerable code. ^[1][2]

For image A, the example organization's issuer policy accepts this supplier, and the application owner confirms the deployed digest matches the named build. The resulting decision is a scoped acceptance of the supplier assertion for A and EXAMPLE-VULN-01. It is not an independent reproduction of the supplier's technical assessment. If that build evidence were unavailable under the organization's evidence policy, the decision would remain unresolved. The same machine-readable status can therefore lead to different local decisions depending on the evidence the consumer actually has.

Image B uses the extended build. Its package name and version match the inventory entry in A, but its digest differs and its build includes the legacy import function. Statement version 7 does not name B. The workflow stops at the identity and scope check, before considering suppression. B remains an open finding for investigation or remediation. Its exclusion from the statement does not prove that B is exploitable; it establishes that this particular assertion cannot close B's finding.

Now change one input. A later deployment replaces A with a newly built standard image, while keeping the friendly release label 2.4.1. The earlier decision cannot silently follow the label. The new artifact needs a match to the statement or updated supplier evidence, even if the package inventory looks unchanged. Similarly, a statement whose reason depends on configuration needs review when that configuration changes. A build-based assertion and a configuration-based assertion need different reopening conditions.

Assign the handoff explicitly. The release owner supplies artifact identity, the application owner supplies local build or configuration context, and the vulnerability owner records acceptance or the unresolved gap. In the synthetic example, A goes to the queue with a scoped not-affected decision and B remains open. Neither outcome suppresses EXAMPLE-VULN-01 globally. A parser can help match the records, but it cannot create missing scope evidence or decide which supplier reliance the organization accepts. ^[2]

This trace gives the decision tree a concrete use. Reject a mismatched statement, investigate an uncertain match, and evaluate supporting conditions only after the product relationship is established. Automation should preserve those different outcomes rather than emitting a single suppress flag. Otherwise, an ordinary rebuild or corrected statement can leave the consumer unable to identify which earlier decisions need to be reopened.

Source. CISA VEX minimum requirements ^[1]; CISA VEX status justifications ^[2]; OpenVEX specification ^[4]. Sources checked August 28, 2026.

Method. Original conceptual model synthesized from the cited documentation. The relationships and proposed tests explain design choices; they are not measured results or a claim about a deployed environment.

Accessible table and figure data

Figure 1 accessible table

Question	If yes	If no
Does the statement match the exact artifact and vulnerability?	Check statement currency and issuer	Do not inherit the assertion
Is the issuer acceptable and the statement current?	Read status and supporting evidence	Reject or investigate
Does the status carry sufficient justification or impact information?	Check local deployment conditions	Request evidence or investigate
Do local conditions satisfy the statement's scope?	Record a scoped decision and recheck trigger	Keep the finding open or reject suppression

Figure 1 accessible table

Question	If yes	If no
Does the statement match the exact artifact and vulnerability?	Check statement currency and issuer	Do not inherit the assertion
Is the issuer acceptable and the statement current?	Read status and supporting evidence	Reject or investigate
Does the status carry sufficient justification or impact information?	Check local deployment conditions	Request evidence or investigate
Do local conditions satisfy the statement's scope?	Record a scoped decision and recheck trigger	Keep the finding open or reject suppression

Download imageDownload table CSV

Retain the decision and its reopening condition

The following record continues the synthetic example. It is an editorial decision-record format, not an OpenVEX document, CSAF advisory or scanner import file. The repeated-character digests are fictional identifiers used to make the two artifacts visibly different. The supplier URL uses the reserved example domain. No sample status below is a measured result, and none of these values should be copied into a real exception. A production record would retain the actual immutable source and deployment references.

The record deliberately keeps supplier status separate from consumer decision. Image A carries an accepted assertion with a stated reliance on supplier build evidence. Image B records that the same statement is out of scope and leaves the finding open. This prevents a downstream report from representing an unmatched artifact as not affected simply because the supplier document contained that label. The decision owner and reason should remain available even when a dashboard displays a shorter summary. ^[1][2]

Reopening follows the premise behind each decision. Replace image A, revise statement 7, or receive evidence contradicting the excluded-code claim, and the scoped acceptance needs review. Do not invent a universal expiration period that every VEX format supposedly requires. The organization can add a scheduled review when reliance is incomplete or evidence is evolving, but it should describe that as its own policy. An artifact change is a meaningful trigger even when a calendar deadline has not arrived.

Retain the superseded statement and decision so the organization can explain its earlier action, while ensuring the current workflow uses the revised evidence. A historical acceptance is not continuing authority for a changed product. Stable references keep the record smaller than a copied SBOM while preserving the chain back to the inventory, supplier assertion and deployed artifact. Unknown fields remain unknown; a missing match must never default to not affected. ^[1][7][8]

{
  "exampleOnly": true,
  "recordFormat": "editorial-decision-example-not-vex",
  "vulnerability": "EXAMPLE-VULN-01",
  "statement": {
    "id": "https://supplier.example/vex/preview/7",
    "version": 7,
    "issuer": "Example Preview Supplier",
    "status": "not_affected",
    "justification": "vulnerable_code_not_present",
    "scope": "standard build only"
  },
  "decisions": [
    {
      "artifact": "sha256:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
      "build": "standard",
      "consumerDecision": "accept_for_this_artifact",
      "basis": "Matched build; accepted supplier evidence that legacy import code was excluded",
      "owner": "Example vulnerability owner",
      "reopenOn": [
        "artifact replacement",
        "statement revision",
        "contradicting build evidence"
      ]
    },
    {
      "artifact": "sha256:bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb",
      "build": "extended",
      "consumerDecision": "keep_finding_open",
      "basis": "Statement does not identify this build; no exploitability conclusion inferred",
      "owner": "Example application owner",
      "nextAction": "Obtain applicable evidence or evaluate supported remediation"
    }
  ]
}

Source. CISA VEX minimum requirements ^[1]; CISA VEX status justifications ^[2]; Package URL specification ^[7]; OpenSSF OSV schema ^[8]. Sources checked August 28, 2026.

Method. Original conceptual model synthesized from the cited documentation. The relationships and proposed tests explain design choices; they are not measured results or a claim about a deployed environment.

Accessible table and figure data

Figure 2 accessible table

Record field	Statement evidence	Deployment evidence	Review trigger
Artifact identity	Product identifiers and version	Deployed digest or build identity	Artifact replacement
Vulnerability scope	Vulnerability ID and affected range	Ecosystem-aware package match	Advisory revision
Issuer and status	Issuer, timestamp and status	Consumer acceptance owner	Issuer or status change
Justification	Reason or impact statement	Relevant configuration and code-path facts	Configuration or feature change
Decision	Accepted scope or unresolved issue	Named owner and retained evidence	Planned review or new exploit evidence

Figure 2 accessible table

Record field	Statement evidence	Deployment evidence	Review trigger
Artifact identity	Product identifiers and version	Deployed digest or build identity	Artifact replacement
Vulnerability scope	Vulnerability ID and affected range	Ecosystem-aware package match	Advisory revision
Issuer and status	Issuer, timestamp and status	Consumer acceptance owner	Issuer or status change
Justification	Reason or impact statement	Relevant configuration and code-path facts	Configuration or feature change
Decision	Accepted scope or unresolved issue	Named owner and retained evidence	Planned review or new exploit evidence

Download imageDownload table CSV

Hand an evidence-backed decision to the patch queue

Once applicability is resolved, hand the finding and its evidence to the remediation workflow. An affected artifact can be prioritized using the organization's exploit, exposure and operational context. A scoped not-affected decision should carry the statement and deployment conditions that support it. An unresolved match should remain visible as unresolved. This handoff prevents the patch queue from treating every scanner match as equivalent or every VEX status as an automatic override.

Keep provenance and vulnerability applicability connected without confusing them. A verified image digest or build attestation can establish which artifact was produced and deployed. It does not alone establish whether that artifact is affected by a particular vulnerability. VEX supplies another kind of assertion, and the consumer's applicability review supplies the local decision. Each evidence type contributes a different answer.

SBOM and VEX become operationally useful when a reviewer can follow that chain from software identity to a specific action. The desired outcome is not a smaller queue at any cost. It is a queue whose inclusions, exceptions and unresolved items can be explained from current evidence, with a clear route to reopen decisions when the software or the underlying claim changes.