An OpenVEX statement only changes a scanner’s output if its product, its subcomponents and the purls inside them match what the scanner found. In the go-vex library that Trivy v0.76.2 uses, the rules are short: the VEX purl is a pattern (no version means every version, and every qualifier it lists must be present), subcomponents narrow a statement to specific packages, and among matching statements the one with the newest timestamp wins. Most “VEX didn’t work” tickets come down to one of those three.

This article is about the identifiers and the matching. For what the statuses and justifications mean, see VEX explained. For converting CycloneDX VEX to OpenVEX, see the CycloneDX VEX mapping. For CSAF’s product tree, see CSAF VEX product_tree.

Products and subcomponents in the spec

The OpenVEX specification v0.2.0 defines a product as “a logical unit representing a piece of software”, broad enough that “anything that can be described in a Software Bill of Materials (SBOM) can be thought of as a product.” A subcomponent is “any components possibly included in the product where the vulnerability originates.” The spec adds that subcomponents “SHOULD also list software identifiers and they SHOULD also be listed in the product SBOM.”

Products and subcomponents share one structure, which the spec calls Component:

All three identifying fields are optional, but the spec says a valid statement “MUST identify a product.” It also says the product should list “as many software identifiers as possible to help VEX processors when matching the product.”

products itself is optional in a statement because it can be inherited from an encapsulating document, such as the subject of an in-toto attestation. Timestamps can be inherited too. The spec’s inheritance rules are: a statement timestamp overrides the document timestamp, which overrides the encapsulating document’s; a product ID in a statement overrides product data in the encapsulating document.

How go-vex matches a statement

Trivy loads OpenVEX documents with openvex/go-vex, pinned to v0.2.9 in Trivy v0.76.2’s go.mod. Its matching code is small enough to read in full. For a finding (CVE, product, optional subcomponent), a statement matches when all of these hold:

1. Vulnerability. The CVE ID equals the statement’s vulnerability.name, its @id, or one of its aliases.
2. Product. One entry in products matches the product identifier. A component matches if its @id equals the identifier exactly, or its @id is a purl that matches by the purl rules below, or any value in identifiers equals it (with purl matching for the purl key), or any value in hashes equals it.
3. Subcomponent. If that product entry has no subcomponents, or the caller passed no subcomponent, the product match is enough. Otherwise one listed subcomponent must match the subcomponent identifier by the same component rules.

The purl rules

go-vex’s PurlMatches(purl1, purl2) treats the VEX purl as the general one and the scanned purl as the specific one:

The function’s own comment says “Purl version ranges are not supported yet.” A statement covering versions 1.0 to 1.4 needs either one purl per version or no version at all. Leaving the version off is the broadest possible statement, so use it only when you mean every version. Trivy’s documentation notes that these matching rules come from a community discussion, not from the purl specification.

Which statement wins

go-vex collects every matching statement and sorts them by timestamp, using the document timestamp for any statement without its own. Trivy takes the last one. It removes the finding only if that statement’s status is not_affected or fixed; affected and under_investigation leave the finding in the report.

This is why the spec’s update example keeps the original document timestamp on the first statement when a second one is added. If you edit a document, bump timestamp and version at the document level, and the old statements lose their original time, the ordering of statements for the same CVE can change.

A tested example

The document below has two statements for CVE-2024-32002 on a container image (the first under_investigation with its own timestamp, the second not_affected inheriting the newer document timestamp) and one statement for a Go service. It validates against the OpenVEX JSON schema (openvex_json_schema.json from the spec repository, checked with Python jsonschema).

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://example.com/vex/app-2026-11-06",
  "author": "Example Security Team <security@example.com>",
  "timestamp": "2026-11-06T09:00:00Z",
  "version": 2,
  "statements": [
    {
      "vulnerability": {"name": "CVE-2024-32002"},
      "timestamp": "2026-11-01T10:00:00Z",
      "products": [
        {
          "@id": "pkg:oci/app?repository_url=ghcr.io%2Facme%2Fapp",
          "subcomponents": [{"@id": "pkg:apk/alpine/git"}]
        }
      ],
      "status": "under_investigation"
    },
    {
      "vulnerability": {"name": "CVE-2024-32002"},
      "products": [
        {
          "@id": "pkg:oci/app?repository_url=ghcr.io%2Facme%2Fapp",
          "subcomponents": [{"@id": "pkg:apk/alpine/git"}]
        }
      ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_in_execute_path",
      "status_notes": "git is installed for build-time use only; the runtime entrypoint never invokes git clone."
    },
    {
      "vulnerability": {"name": "CVE-2023-0001"},
      "products": [
        {
          "@id": "pkg:golang/example.com/svc@v1.4.0",
          "subcomponents": [{"@id": "pkg:golang/golang.org/x/net@v0.17.0"}]
        }
      ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_present"
    }
  ]
}

The image, service names and CVE-2023-0001 statement are illustrative. To check the matching without a registry or a real image, we wrote a Python port of go-vex v0.2.9’s PurlMatches, Component.Matches, Product.Matches, Statement.Matches and timestamp sort, using the packageurl-python parser, and ran it with Python 3 against the document. It is a port, not the Go library itself, so treat it as a reading aid. Output, with long purls shortened:

product                                    subcomponent                          result
pkg:oci/app?repository_url=…%2Fapp         pkg:apk/alpine/git@2.43.0-r0?arch=…   2 matches, effective=not_affected
pkg:oci/app?repository_url=…%2Fapp         pkg:apk/alpine/git-daemon@2.43.0-r0   no match
pkg:oci/app?repository_url=…%2Fapp         (none)                                2 matches, effective=not_affected
pkg:oci/app                                pkg:apk/alpine/git@2.43.0-r0          no match
pkg:oci/app?repository_url=…%2Fapp&tag=v2  pkg:apk/alpine/git@2.43.0-r0          2 matches, effective=not_affected
pkg:golang/example.com/svc@v1.4.0          pkg:golang/golang.org/x/net@v0.17.0   1 match,  effective=not_affected
pkg:golang/example.com/svc@v1.5.0          pkg:golang/golang.org/x/net@v0.17.0   no match
pkg:golang/example.com/svc@v1.4.0          pkg:golang/golang.org/x/net@v0.18.0   no match

What the rows show:

• Row 1: the versionless pkg:apk/alpine/git subcomponent covers the installed git@2.43.0-r0. Both statements match, and the not_affected one wins because it inherits the later document timestamp.
• Row 2: git-daemon is a different package name, so the statement does not cover it, even though it ships from the same source.
• Row 3: with no subcomponent passed, the product match alone is enough. Trivy does not hit this case for an image root (see below), but other consumers of go-vex may.
• Rows 4 and 5: the repository_url qualifier on the VEX side must be present on the scanned side. A scan purl without it fails; one with an extra tag qualifier passes.
• Rows 6 to 8: pinned versions on both product and subcomponent mean a new service release (v1.5.0) or a dependency bump (x/net v0.18.0) silently drops the statement. That is often what you want, since the reachability analysis was for that build, but it means the document needs updating each release.

How Trivy applies it to a dependency tree

Trivy’s VEX guide and its filterVulnerabilities code show how it feeds this matcher. For each finding it first asks whether the vulnerable package itself is a not-affected product (no subcomponent). If not, it walks up the dependency graph from the vulnerable package and asks, for each parent, whether “parent as product, vulnerable package as subcomponent” is not affected. The finding is removed only if no path reaches the root without passing a not-affected node.

Two consequences:

• A statement on an intermediate dependency can suppress a finding, but only if every path goes through it. Trivy’s documentation gives the example of Module C reached through both B and D: a VEX statement for B does not suppress the finding, because D might still be affected.
• A statement on the image with no subcomponents suppresses the CVE in every package in that image. Trivy’s docs call this out and recommend subcomponents for “reducing the risk of incorrect filtering.”

Trivy needs a purl on the scanned side. Its OpenVEX matcher returns nothing when the product has no purl, so cpe-only or hash-only VEX products are not matched by Trivy even though the spec allows them. Use the purls Trivy prints in its JSON report.

Writing statements that match

These are our recommendations, based on the rules above:

1. Copy purls from the scanner or SBOM output. Do not type them by hand; the type, namespace and name must match exactly. Our guide to CVE packageURL and SBOM purls covers common purl pitfalls.
2. Always add subcomponents for image-level or application-level products. A product with no subcomponents is a blanket statement.
3. Add a version only when the claim depends on the build. Reachability claims (vulnerable_code_not_in_execute_path) usually do. “This package never ships the vulnerable file” claims may not.
4. Be sparing with qualifiers in the VEX purl. Each one is a requirement. arch is useful if only one architecture is unaffected; otherwise leave it out.
5. Keep timestamps on old statements when you append new ones, and bump the document version. Use status_notes to record how the status was determined. Trivy does not read it, but reviewers do.
6. Track the result. Our prioritization workflow shows where a VEX decision sits between the CVE record and the ticket.

Limits of this article

• Matching behaviour is from go-vex v0.2.9 and Trivy v0.76.2 source and docs. Grype, vexctl and commercial scanners have their own matchers and may differ.
• Our test used a Python port of the go-vex rules, not the Go library or a Trivy scan. The port follows the source shown in the references; differences in purl parsing between packageurl-python and packageurl-go are possible for unusual purls.
• We did not cover OpenVEX attestations attached to OCI images (--vex oci) or VEX repositories.

Sources and verification

Scope. This is a field-level guide for engineers who consume vendor CSAF VEX files and need to apply them to their own SBOMs. We read the CSAF 2.0 prose and JSON schema in the OASIS CSAF TC’s GitHub repository, Red Hat’s July 2024 announcement of its CSAF VEX files, and Trivy’s CSAF matcher and documentation at tag v0.76.1. The example document and the Python script below are ours; we validated the document against the CSAF 2.0 JSON schema and ran the script with Python 3.13. The script is illustrative, not a production matcher.

The short answer

A CSAF VEX file never puts a purl next to a status. It says “product ID GW-4.2.1:LIB-1.8.0 is known_not_affected”, and you have to work out what that ID is:

1. Find the ID in the product_tree: at the end of a branches path, in full_product_names, or as the full_product_name of a relationships entry.
2. If it is a relationship, resolve both sides: product_reference (the component) and relates_to_product_reference (the product it sits in).
3. Read product_identification_helper.purl (or cpe) for each side.
4. Apply the status only when your SBOM contains the component and the parent matches the product you are assessing.
5. Collapse the eight product_status lists to the four VEX answers before you write anything to a ticket.

The rest of this article goes through each step, shows a schema-valid example, and gives a script that does the join.

What the VEX profile requires

CSAF 2.0 has been an OASIS Standard since 18 November 2022. The VEX profile is section 4.5. A document satisfies it when /document/category is csaf_vex and it contains:

• a product_tree “which lists all products referenced later on in the CSAF document regardless of their state”;
• vulnerabilities, each with notes and at least one of cve or ids;
• at least one of the fixed, known_affected, known_not_affected or under_investigation lists.

Two conditions are per product, and they are the ones consumers should check:

• Every product in known_not_affected needs an impact statement, either “as machine readable flag in /vulnerabilities[]/flags or as human readable justification in /vulnerabilities[]/threats” with category set to impact.
• Every product in known_affected needs “additional product specific information” in remediations “as an action statement”. The categories no_fix_planned and none_available count.

The five flag labels are the CISA justification codes: component_not_present, vulnerable_code_not_present, vulnerable_code_cannot_be_controlled_by_adversary, vulnerable_code_not_in_execute_path and inline_mitigations_already_exist. If you need the meaning of each one, the VEX explainer covers them. The CycloneDX VEX mapping guide covers converting between CSAF and other VEX formats. This article is about something they do not cover: finding the products a CSAF statement actually refers to.

Step 1: walk the product tree

The product_tree can name products in three places. A consumer has to read all three.

Every one of these is a “full product name”: name and product_id are required, and product_identification_helper is optional. That helper is where purl, cpe, hashes and SBOM URLs go. The CSAF schema only checks the purl against a loose pattern (^pkg:[A-Za-z\.\-\+][A-Za-z0-9\.\-\+]*/.+) and says it “does not completely evaluate whether a PURL is valid”, so validate purls yourself before matching on them.

There is also product_groups, which bundles product IDs under a group ID. Product status lists only hold product IDs, but flags, threats and remediations can reference groups through group_ids, so expand groups when you collect impact and action statements.

The spec recommends the vendor → product_name → product_version shape “whenever possible to support the identification and matching of products on the consumer side”. It also allows product_version_range branches, but recommends enumerating versions instead. If you meet a range branch, you need a version-range parser for whatever scheme it uses; the purl join below will not help.

Step 2: treat relationships as “component in product”

A relationship has four required fields: category, product_reference, relates_to_product_reference and full_product_name. The categories are default_component_of, external_component_of, installed_on, installed_with and optional_component_of. The spec gives the reason relationships exist: a product may be “vulnerable only when installed together with another”, or you may need “to describe operating system components”.

This is the part consumers get wrong. In our example below, LIB-1.8.0 is the library on its own and GW-4.2.1:LIB-1.8.0 is “libexample 1.8.0 as shipped in Example Gateway 4.2.1”. A vendor that marks the second ID known_not_affected is saying the gateway does not reach the vulnerable code. It is not saying libexample 1.8.0 is safe everywhere. If your matcher resolves the relationship ID to the component purl alone, you will suppress the CVE for every other image that ships libexample 1.8.0. That is the false negative VEX is supposed to prevent.

The rule we use: for a relationship ID, apply the status only when the component purl matches a component in the SBOM and the parent purl matches the SBOM’s subject (for CycloneDX, metadata.component).

Red Hat’s VEX files are a real case of this structure. Red Hat publishes one CSAF VEX file per CVE. Its July 2024 announcement says each file has a product_tree object listing “products, their components, and the relationships between them”. In the general-availability release Red Hat “extended the scope of the purl identifiers to unfixed components as well” for rpm, oci and rpmmod components. In the October 2023 beta, only fixed components carried a purl. Check which one you are parsing.

Step 3: collapse eight status lists into four answers

CSAF defines eight product_status lists. VEX consumers need four answers. The spec’s own test for contradicting statuses (section 6.1.6) gives the grouping, and the sets “MUST be pairwise disjoint” within one vulnerability:

If you find one product ID in two groups for the same CVE, the document fails the CSAF mandatory test. Reject the statement for that product rather than picking one.

For affected products, the remediation categories tell you what kind of action is available: vendor_fix, workaround, mitigation, none_available or no_fix_planned. vendor_fix cannot be combined with none_available or no_fix_planned for the same product.

A schema-valid example

This document is ours, written for this article. It has one product version where a library is not reachable and a later version where it was updated. It passes validation against the CSAF 2.0 JSON schema from the OASIS repository (Python jsonschema, Draft 2020-12, format checks on; 0 errors). Schema validation does not run CSAF’s mandatory tests, so it does not prove the profile rules are met. We checked those by hand.

{
  "document": {
    "category": "csaf_vex",
    "csaf_version": "2.0",
    "publisher": {"category": "vendor", "name": "Example Vendor", "namespace": "https://vendor.example"},
    "title": "Example Gateway: CVE-2099-0001 in libexample",
    "tracking": {"id": "EXV-2099-0001", "status": "final", "version": "2", "...": "..."}
  },
  "product_tree": {
    "branches": [{"category": "vendor", "name": "Example Vendor", "branches": [
      {"category": "product_name", "name": "Example Gateway", "branches": [
        {"category": "product_version", "name": "4.2.1",
         "product": {"name": "Example Gateway 4.2.1", "product_id": "GW-4.2.1",
           "product_identification_helper": {"purl": "pkg:oci/example-gateway@sha256%3A1111?tag=4.2.1"}}}
      ]},
      {"category": "product_name", "name": "libexample", "branches": [
        {"category": "product_version", "name": "1.8.0",
         "product": {"name": "libexample 1.8.0", "product_id": "LIB-1.8.0",
           "product_identification_helper": {"purl": "pkg:deb/debian/libexample@1.8.0-1"}}}
      ]}
    ]}],
    "relationships": [
      {"category": "default_component_of",
       "product_reference": "LIB-1.8.0",
       "relates_to_product_reference": "GW-4.2.1",
       "full_product_name": {"name": "libexample 1.8.0 in Example Gateway 4.2.1",
                             "product_id": "GW-4.2.1:LIB-1.8.0"}}
    ]
  },
  "vulnerabilities": [{
    "cve": "CVE-2099-0001",
    "notes": [{"category": "description", "text": "Illustrative vulnerability in libexample's XML parser."}],
    "product_status": {"known_not_affected": ["GW-4.2.1:LIB-1.8.0"], "fixed": ["GW-4.3.0:LIB-1.8.2"]},
    "flags": [{"label": "vulnerable_code_not_in_execute_path", "product_ids": ["GW-4.2.1:LIB-1.8.0"]}],
    "threats": [{"category": "impact", "details": "Example Gateway never calls the XML parser in libexample.",
                 "product_ids": ["GW-4.2.1:LIB-1.8.0"]}]
  }]
}

The excerpt trims the tracking block and the 4.3.0 / 1.8.2 branches and relationship, which follow the same pattern. The CVE ID is a placeholder.

Step 4: join to the SBOM

The script resolves every product ID in product_status to purls, follows relationships, and checks both sides against a CycloneDX SBOM. For purl comparison it uses the matching rules Trivy documents, which Trivy itself notes “are not formally defined within the current official PURL specification”: a VEX purl without a version matches every version; every qualifier in the VEX purl must be present in the SBOM purl; extra SBOM qualifiers are ignored.

#!/usr/bin/env python3
"""Resolve CSAF VEX product_status entries to purls and join them to a CycloneDX SBOM.
Illustrative: purl matching follows the rules in purl_match(); no version-range logic."""
import json, sys
from urllib.parse import unquote

def parse(p):
    """Split a purl into (type/namespace/name, version or None, qualifiers dict). Subpath ignored."""
    p = p.split("#")[0]
    core, _, q = p.partition("?")
    quals = dict(kv.split("=", 1) for kv in q.split("&") if "=" in kv)
    path, _, ver = core.rpartition("@") if "@" in core.rsplit("/", 1)[-1] else (core, "", "")
    return unquote(path).lower(), unquote(ver) or None, {k.lower(): unquote(v) for k, v in quals.items()}

def purl_match(vex_purl, sbom_purl):
    """Community matching rules (as documented by Trivy): a VEX purl without a version matches
    every version; VEX qualifiers must all be present in the SBOM purl; extra SBOM qualifiers are ignored."""
    vp, vv, vq = parse(vex_purl)
    sp, sv, sq = parse(sbom_purl)
    return vp == sp and (vv is None or vv == sv) and all(sq.get(k) == v for k, v in vq.items())

def walk_branches(branches, out):
    for b in branches or []:
        if "product" in b:
            fpn = b["product"]
            out[fpn["product_id"]] = fpn.get("product_identification_helper", {}).get("purl")
        walk_branches(b.get("branches"), out)

def load_products(doc):
    tree = doc["product_tree"]
    purls = {}
    walk_branches(tree.get("branches"), purls)
    for fpn in tree.get("full_product_names", []):
        purls[fpn["product_id"]] = fpn.get("product_identification_helper", {}).get("purl")
    rels = {}
    for r in tree.get("relationships", []):
        rels[r["full_product_name"]["product_id"]] = (
            r["category"], r["product_reference"], r["relates_to_product_reference"])
    groups = {g["group_id"]: g["product_ids"] for g in tree.get("product_groups", [])}
    return purls, rels, groups

def main(vex_path, sbom_path):
    doc = json.load(open(vex_path))
    assert doc["document"]["category"] == "csaf_vex", "not a VEX profile document"
    purls, rels, groups = load_products(doc)
    sbom = json.load(open(sbom_path))
    parent = sbom["metadata"]["component"]["purl"]
    inventory = [c["purl"] for c in sbom.get("components", []) if c.get("purl")]
    in_sbom = lambda vex_purl: any(purl_match(vex_purl, s) for s in inventory)

    for v in doc["vulnerabilities"]:
        flags = {pid: f["label"] for f in v.get("flags", [])
                 for pid in f.get("product_ids", []) + sum((groups[g] for g in f.get("group_ids", [])), [])}
        for status, pids in v.get("product_status", {}).items():
            for pid in pids:
                if pid in rels:                      # component-in-product: match BOTH sides
                    cat, comp, prod = rels[pid]
                    comp_p, prod_p = purls.get(comp), purls.get(prod)
                    hit = bool(comp_p and prod_p and purl_match(prod_p, parent) and in_sbom(comp_p))
                    target = f"{comp_p} {cat} {prod_p}"
                else:                                # standalone product
                    p = purls.get(pid)
                    hit = bool(p and (in_sbom(p) or purl_match(p, parent)))
                    target = p
                print(f"{v.get('cve')}\t{status}\t{flags.get(pid, '-')}\t{'MATCH' if hit else 'no match'}\t{target}")

if __name__ == "__main__":
    main(*sys.argv[1:3])

Test run

We ran it (python3 -I csaf_vex_join.py vex.json sbom.cdx.json) against the full example document and three small CycloneDX 1.6 SBOMs.

SBOM 1, image 4.2.1 (metadata.component.purl = pkg:oci/example-gateway@sha256%3A1111?tag=4.2.1), containing pkg:deb/debian/libexample@1.8.0-1?arch=amd64&distro=debian-12:

CVE-2099-0001  known_not_affected  vulnerable_code_not_in_execute_path  MATCH     pkg:deb/debian/libexample@1.8.0-1 default_component_of pkg:oci/example-gateway@sha256%3A1111?tag=4.2.1
CVE-2099-0001  fixed               -                                    no match  pkg:deb/debian/libexample@1.8.2-1 default_component_of pkg:oci/example-gateway@sha256%3A2222?tag=4.3.0

The SBOM’s extra arch and distro qualifiers did not block the match, because the VEX purl has none.

SBOM 2, image 4.3.0 with libexample 1.8.2: the results flip. The fixed statement matches and the known_not_affected one does not.

SBOM 3, the 4.2.1 SBOM again, but with the VEX component purl changed to ...libexample@1.8.0-1?arch=arm64: no match, because the VEX purl now requires a qualifier value the SBOM lacks.

What the script does not do: version ranges (product_version_range), CPE-only products, hashes, product_groups in status lists (the schema does not allow them there), or the mandatory-test checks. It also prints matches and nothing else; it does not decide what to do with a CVE your scanner found but the VEX file does not mention.

How Trivy applies CSAF VEX

Trivy is a common place engineers first meet CSAF VEX. At tag v0.76.1, its documentation says CSAF works for container images, filesystems, code repositories, VM images, Kubernetes and SBOM targets, passed with --vex. Its matcher (pkg/vex/csaf.go) shows three things worth knowing:

• Only two statuses act. The status map holds known_not_affected and fixed. A match on either filters the finding. known_affected and under_investigation statements never change the result.
• Matching is by purl. If the detected package has no purl, or the vulnerability has no product_status, nothing is filtered.
• Relationship categories are not distinguished. The documentation says “the specified relationship category is not taken into account” and that default_component_of, installed_on and installed_with “are treated internally as depends_on”. For a relationship, the code requires the parent purl to match a product higher in the dependency tree (such as the scanned image) and the component purl to match the sub-component, which is the both-sides rule from Step 2. external_component_of and optional_component_of relationships are skipped. A status on a plain product ID, with no relationship, is matched against the package’s own purl, so it applies wherever that package appears.

So if a vendor’s CSAF file uses optional_component_of for a component, Trivy will not apply that status through the relationship. That is safe in direction (no false suppression), but it can surprise you if you expect the finding to drop.

Common mistakes

• Matching the component alone. Covered above. It turns a statement about one product into a statement about all of them.
• Trusting known_not_affected with no impact statement. The profile requires a flag or an impact threat for each such product. If neither exists, the document does not satisfy the profile; send it back to the vendor rather than suppressing.
• Reading only branches. Products in full_product_names and relationships carry IDs too. A parser that only walks branches will report “unknown product” for most relationship-heavy files.
• Treating recommended as fixed. The spec allows recommending a version from the affected group.
• Ignoring tracking.version and current_release_date. VEX files are revised as investigations finish. Store the version you applied, and re-apply when it changes.

Where this fits

VEX is one input to a patch decision, not the decision. In our vulnerability prioritization workflow, a supplier VEX statement is the step that can close a ticket before KEV, EPSS or SSVC are weighed. For the SBOM side of the join, the SBOM minimum elements guide covers which identifiers your SBOM should carry in the first place. Without purls in the SBOM, none of this matching works.

Limits of this article

We read CSAF 2.0 from the OASIS TC’s GitHub repository (the editor’s draft prose, headed “OASIS Standard, 18 November 2022”, and the JSON schema) rather than the copy hosted on docs.oasis-open.org. CSAF 2.1 is still a draft in that repository and may change field names or add statuses. We did not download a Red Hat VEX file; Red Hat’s structure is described from its own announcements. The purl matching rules are a community convention, not part of the purl standard. Our test document is synthetic.

Sources and verification

Scope. This is a field-level mapping guide. We compared the CycloneDX JSON schemas for 1.6 and 1.7 (identical enums for the fields below), OpenVEX specification v0.2.0 and its JSON schema, and the CSAF 2.0 JSON schema and VEX profile text from the OASIS TC repository, then read how Trivy (main branch, commit 1d1ab074, November 2, 2026) consumes CycloneDX VEX. The converter below was run with Python 3.13; its output validated against the OpenVEX 0.2.0 JSON schema and its inputs against the CycloneDX 1.6 schema. Our VEX explainer covers what the statuses mean and how far to trust them; this article is only about moving statements between formats.

The short answer

If you receive CycloneDX VEX and your pipeline speaks OpenVEX or CSAF (or the reverse), the states map almost one-to-one, but the justifications do not.

Of CycloneDX’s nine justifications, only code_not_present and code_not_reachable have a clear counterpart among the five CISA-derived labels that OpenVEX and CSAF share. Convert those two; carry the other seven as text.

Where VEX sits in a CycloneDX document

CycloneDX has no separate VEX document type. VEX is the vulnerabilities array of a BOM, and the fields that matter are:

• id: the vulnerability identifier, such as a CVE ID.
• affects[].ref: what the statement is about. The schema allows a bom-ref in the same document or a BOM-Link element. A BOM-Link has the form urn:cdx:serialNumber/version#bom-ref, and the schema’s pattern requires the serial number UUID, a version of 1 or more, and a fragment.
• analysis.state: one of resolved, resolved_with_pedigree, exploitable, in_triage, false_positive, not_affected.
• analysis.justification: one of nine reasons, described below.
• analysis.response: zero or more of can_not_fix, will_not_fix, update, rollback, workaround_available.
• analysis.detail: free text. The schema says that if a vulnerability is not exploitable, “this field should include specific details on why the component or service is not impacted.”

A VEX statement can sit inside the SBOM itself or in a separate BOM that only has vulnerabilities and refers back to the SBOM by BOM-Link. That second pattern matters for tooling, below.

States: four clean pairs and two lossy ones

The CycloneDX schema defines the six states in its meta:enum. Four map directly:

• not_affected: “The component or service is not affected by the vulnerability. Justification should be specified for all not_affected cases.” This is OpenVEX not_affected and CSAF known_not_affected.
• exploitable: “The vulnerability may be directly or indirectly exploitable.” This is OpenVEX affected and CSAF known_affected.
• in_triage: “The vulnerability is being investigated.” This is under_investigation in both.
• resolved: “The vulnerability has been remediated.” This is fixed in both.

Two lose meaning:

• false_positive: “The vulnerability is not specific to the component or service and was falsely identified or associated.” OpenVEX and CSAF have no status for “the scanner was wrong”. The safe target is not_affected, which is also what Trivy’s cdxStatus function does (case cdx.IASFalsePositive, cdx.IASNotAffected: return types.FindingStatusNotAffected). Keep the word false_positive in the impact statement so a reviewer can see it.
• resolved_with_pedigree: remediated “and evidence of the changes are provided in the affected components pedigree”. It becomes fixed, and the pointer to pedigree evidence is lost unless you keep it as text.

Justifications: two of nine line up

OpenVEX’s five justification labels come from CISA’s June 2022 status-justification document, and the CSAF 2.0 schema’s flags[].label uses the same five strings. CycloneDX defines a different set of nine. Here is each one with its CycloneDX definition and our reading of the closest OpenVEX/CSAF label.

Why so strict? The OpenVEX spec defines inline_mitigations_already_exist as built-in protections that “cannot be subverted by the attacker and cannot be configured or disabled by the user.” A CycloneDX protected_at_runtime or protected_by_compiler claim does not tell you that. protected_at_perimeter and protected_by_mitigating_control describe the deployment, not the product, and a mitigating control that “reduce[s] the likelihood and/or impact” is weaker than “not affected” in the CISA sense.

This mapping is our editorial reading of the published definitions. We did not find a mapping table published by the CycloneDX project or CISA.

OpenVEX gives you a way out: for not_affected, “a VEX statement MUST include either a status justification or an impact_statement.” So you can emit a not_affected statement with no label and an impact statement that preserves the original CycloneDX reason. CSAF’s VEX profile has the same escape hatch: each known_not_affected product needs either a machine-readable flag or a human-readable justification in threats with category impact.

Responses and action statements

For affected products, both targets require an action:

• OpenVEX: for affected, “a VEX statement MUST include a statement that SHOULD describe actions to remediate or mitigate the vulnerability” (action_statement).
• CSAF VEX profile: for known_affected, “additional product specific information SHALL be provided in /vulnerabilities[]/remediations as an action statement.”

CycloneDX’s response values give you a starting point. update and rollback fit CSAF’s vendor_fix remediation category, workaround_available fits workaround, and will_not_fix / can_not_fix fit no_fix_planned (or none_available), which the CSAF profile explicitly permits for an action statement. OpenVEX takes a free-text action_statement, so join the responses with analysis.detail. If an exploitable statement has neither a response nor detail, the converted statement will be valid but useless; send it back to the supplier.

BOM-Link: the part that silently drops statements

A CycloneDX VEX BOM that references components by BOM-Link is bound to one SBOM version. Trivy’s docs (v0.67) say the tool “only supports the Independent BOM and VEX BOM format, so you need to provide a separate VEX file alongside the SBOM,” that “BOM-Links must be placed in affects.ref,” and that the input SBOM must be CycloneDX. The usage example is trivy sbom trivy.sbom.cdx --vex trivy.vex.cdx. The feature is marked experimental.

Trivy’s code adds a detail the docs do not spell out: if the BOM-Link’s serial number or version does not equal the scanned SBOM’s, it logs URN doesn't match with SBOM and skips the statement. Regenerate the SBOM (new serial number or version) without regenerating the VEX, and every suppression stops applying. That fails safe, since findings come back rather than disappear, but it surprises teams.

OpenVEX has no BOM-Link. Products are identified by an @id such as a Package URL, so a converter has to resolve each BOM-Link to the referenced component’s purl in the SBOM. That is why the converter below takes both files.

A tested converter: CycloneDX VEX to OpenVEX

This Python 3 script reads a CycloneDX SBOM and a separate CycloneDX VEX BOM and writes an OpenVEX 0.2.0 document. It maps states as in the first table, maps only the two clean justifications, and keeps everything else as text. It is illustrative, not production-ready: it does not handle version ranges in affects[].versions, services, or nested BOMs beyond components.

#!/usr/bin/env python3
"""Convert a CycloneDX VEX BOM (independent VEX, BOM-Link refs) to OpenVEX v0.2.0.
Usage: python3 cdx2openvex.py sbom.cdx.json vex.cdx.json author > out.openvex.json"""
import json, sys, hashlib
from datetime import datetime, timezone

STATUS = {  # CycloneDX analysis.state -> OpenVEX status
    "not_affected": "not_affected", "false_positive": "not_affected",
    "exploitable": "affected", "in_triage": "under_investigation",
    "resolved": "fixed", "resolved_with_pedigree": "fixed",
}
# Only the pairs whose definitions line up; everything else is carried as text.
JUSTIFICATION = {
    "code_not_present": "vulnerable_code_not_present",
    "code_not_reachable": "vulnerable_code_not_in_execute_path",
}

def purls_by_ref(sbom):
    serial, version = sbom["serialNumber"], sbom.get("version", 1)
    out, stack = {}, list(sbom.get("components", []))
    while stack:
        c = stack.pop()
        if "bom-ref" in c and "purl" in c:
            out[f"urn:cdx:{serial.removeprefix('urn:uuid:')}/{version}#{c['bom-ref']}"] = c["purl"]
        stack.extend(c.get("components", []))
    return out

def convert(sbom, vex, author):
    refs, statements, problems = purls_by_ref(sbom), [], []
    for v in vex.get("vulnerabilities", []):
        a = v.get("analysis", {})
        state = a.get("state")
        if state not in STATUS:
            problems.append(f"{v['id']}: no analysis.state, skipped"); continue
        products = []
        for af in v.get("affects", []):
            purl = refs.get(af["ref"])
            if purl: products.append({"@id": purl})
            else: problems.append(f"{v['id']}: {af['ref']} not found in SBOM")
        if not products: continue
        s = {"vulnerability": {"name": v["id"]}, "products": products, "status": STATUS[state]}
        detail = a.get("detail", "").strip()
        if s["status"] == "not_affected":
            j = JUSTIFICATION.get(a.get("justification"))
            if j: s["justification"] = j
            note = f"CycloneDX state={state}, justification={a.get('justification', 'none')}"
            s["impact_statement"] = f"{note}. {detail}".strip()
        elif s["status"] == "affected":
            resp = ", ".join(a.get("response", [])) or "none given"
            s["action_statement"] = f"CycloneDX response: {resp}. {detail}".strip()
        statements.append(s)
    body = json.dumps(statements, sort_keys=True).encode()
    doc = {"@context": "https://openvex.dev/ns/v0.2.0",
           "@id": "https://example.com/vex/" + hashlib.sha256(body).hexdigest()[:16],
           "author": author,
           "timestamp": datetime.now(timezone.utc).isoformat(timespec="seconds"),
           "version": 1, "statements": statements}
    return doc, problems

if __name__ == "__main__":
    sbom, vex = (json.load(open(p)) for p in sys.argv[1:3])
    doc, problems = convert(sbom, vex, sys.argv[3])
    json.dump(doc, sys.stdout, indent=2)
    for p in problems: print("WARN", p, file=sys.stderr)

Test run

We fed it a three-component CycloneDX 1.6 SBOM (log4j-core 2.14.1, jackson-databind 2.13.0, snakeyaml 1.30) and a VEX BOM with four statements. The assessments in the VEX are invented test data, not real vendor findings:

1. CVE-2021-44228 on log4j-core: not_affected, code_not_reachable.
2. CVE-2022-42003 on jackson-databind: not_affected, requires_configuration.
3. CVE-2022-1471 on snakeyaml: exploitable, response update.
4. CVE-2021-44228 again, but with a BOM-Link naming SBOM version 2 instead of 1.

Both input files passed check-jsonschema against the CycloneDX 1.6 schema. The run printed one warning to stderr and three statements; the output validated against openvex_json_schema.json (v0.2.0) with the Python jsonschema package:

WARN CVE-2021-44228: urn:cdx:3e671687-395b-41f5-a30f-a58921a69b79/2#pkg-log4j not found in SBOM

The statements array of the output:

[
{
  "vulnerability": { "name": "CVE-2021-44228" },
  "products": [ { "@id": "pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1" } ],
  "status": "not_affected",
  "justification": "vulnerable_code_not_in_execute_path",
  "impact_statement": "CycloneDX state=not_affected, justification=code_not_reachable. JNDI lookups are never invoked; the app logs through SLF4J with Logback."
},
{
  "vulnerability": { "name": "CVE-2022-42003" },
  "products": [ { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.13.0" } ],
  "status": "not_affected",
  "impact_statement": "CycloneDX state=not_affected, justification=requires_configuration. The deserialization feature this issue depends on is disabled in our ObjectMapper configuration."
},
{
  "vulnerability": { "name": "CVE-2022-1471" },
  "products": [ { "@id": "pkg:maven/org.yaml/snakeyaml@1.30" } ],
  "status": "affected",
  "action_statement": "CycloneDX response: update. Dependency upgrade ships in release 4.2."
}
]

The second statement is the important one: it stays not_affected with no invented label, and the reason survives as text. The fourth input statement was dropped with a warning instead of being applied to the wrong SBOM.

Common mistakes

• Mapping every protected_* justification to inline_mitigations_already_exist. That label claims the protection cannot be disabled. A WAF rule or a compiler flag can.
• Dropping false_positive statements because the target format has no matching status. Map them to not_affected and say why.
• Dropping the detail text. It is often the only evidence a reviewer has, and both OpenVEX and CSAF have a place for it.
• Reusing a VEX BOM after regenerating the SBOM. BOM-Links name an exact serial number and version.
• Treating converted VEX as first-party. Keep the original author. OpenVEX author should be the organization that made the assessment, not the converter.

Where this fits

VEX is the “is my product actually affected” step in our vulnerability prioritization workflow, after the CVE record and before KEV, SSVC and EPSS. The SBOM that the VEX points at is covered in our guide to SBOM minimum elements in 2026. If you want a signal for which exploitable statements to fix first, our CVSS vs EPSS vs KEV comparison covers the trade-offs.

Limits of this article

The justification mapping is our reading of the published definitions; no standards body has published it. We read CSAF 2.0 from the OASIS TC’s GitHub repository (schema and editor’s draft prose) rather than the OASIS-hosted standard. We read Trivy’s main branch, not a tagged release, and its docs for v0.67; behaviour may differ in the version you run. We did not run Trivy itself or test the reverse conversion (OpenVEX or CSAF to CycloneDX), which is harder because CycloneDX affects needs a component reference the OpenVEX product may not resolve to.

Sources and verification

Scope. This is a workflow guide built on public specifications and feeds, plus one script we ran. On November 2, 2026 we read the CVE JSON schema (5.2.0), CISA’s Vulnrichment README, CERT/CC’s SSVC deployer documentation and decision table, the OpenVEX specification and the EPSS repository README, and ran the script below against the KEV catalog (version 2026.10.30), the EPSS file scored 2026-11-01 and CVE records from cvelistV5. The assets, exposure ratings and the VEX document in the test are invented for the demonstration. The policy choices in the script are ours, not a standard.

The workflow in one table

Our comparison of CVSS, EPSS and KEV explains what each signal measures. This guide is the plumbing: the order in which a finding from a scanner or SBOM passes through the data, and what lands in the ticket.

Steps 1 to 3 remove work. Steps 4 to 6 order what remains.

Step 1: check the record state

A CVE record is either PUBLISHED or REJECTED (the schema’s two states), and published records can carry tags such as disputed. A rejected ID has no affected products to evaluate. In our test run, CVE-2026-23915 is a Fortinet-assigned ID that was rejected on January 20, 2026 with the reason “Not used”, so the finding closes. Our guide to CVE record states covers the tags and edge cases.

Step 2: confirm you are affected

The CNA’s affected block is an algorithm, not a list: walk versions, take the first match, otherwise use defaultStatus, and if that is missing the schema says the status is unknown. Scanner results that only match a product name skip this. Our explainer on CVE affected versions shows how lessThan, defaultStatus and versionType combine, with a tested evaluator. Keep three outcomes apart in the ticket: affected, unaffected, and unknown or undetermined. The last needs a person or the vendor advisory.

Step 3: apply supplier VEX

If the vulnerable component ships inside someone else’s product, the supplier may publish a VEX (Vulnerability Exploitability eXchange) statement. OpenVEX defines four statuses: not_affected (“No remediation is required regarding this vulnerability”), affected, fixed and under_investigation. A not_affected statement must carry a justification or an impact statement.

Two cautions. A VEX statement is about a specific product and version, so match on the product identifier, not on the CVE alone; a not_affected statement from an appliance vendor says nothing about your own services that use the same library. And read the justification before closing. Our guide to reading a VEX not-affected statement covers the five justifications and what to question.

Step 4: read the exploitation evidence

Two public sources answer “is this being exploited?”:

• KEV. The CISA KEV JSON feed lists CVEs with evidence of exploitation, with dateAdded, dueDate, knownRansomwareCampaignUse and, on newer entries, forensicTriage. The catalog we used (version 2026.10.30, released October 30, 2026) had 1,766 entries.
• CISA’s SSVC values in the CVE record. CISA’s Vulnrichment project writes three SSVC decision points (Exploitation, Automatable, Technical Impact) into a CISA-ADP container. Its README says CISA is “assessing new and recent CVEs”, and that it will not overwrite the CNA’s data. Each value set carries a timestamp. Our Vulnrichment guide shows where they sit and how to pull them with jq.

The SSVC documentation describes Exploitation as “the present state of exploitation”, not a prediction. A none from months ago can be stale, so a KEV listing should outrank an older ADP value. That is the rule our script applies.

Step 5: add EPSS for likelihood

For findings with no exploitation evidence, EPSS estimates “the probability [0-1] of exploitation in the wild in the next 30 days”, and percentile gives the share of scored CVEs with the same or a lower score. The file we used (model v2026.06.15, scored 2026-11-01) held 398,784 CVEs. EPSS is a ranking aid within the non-exploited queue. It does not replace step 4: in our run the KEV-listed FortiMail flaw scored 0.04573. See the EPSS data feed guide for the columns, model-version breaks and a scanner join.

Step 6: let exposure and impact decide

CERT/CC’s SSVC deployer model maps four inputs to a patch priority:

The decision table (deployer_patch_application_priority_1_0_0.csv, 72 rows) returns one of four outcomes, which the deployer documentation defines as: Defer (“Do not act at present”), Scheduled (“Act during regularly scheduled maintenance time”), Out-of-cycle (“Act more quickly than usual… during the next available opportunity”) and Immediate (“Act immediately; focus all resources on applying the fix”). In the table, Immediate appears in 3 rows, all with active exploitation and open exposure. Our SSVC deployer explainer walks through the inputs, including where Human Impact is easy to get wrong.

One mapping detail: CISA’s ADP data writes poc, while the deployer table uses public poc. They are not identical definitions. CISA’s tree uses the older PoC value, which also covers privately attested exploitation and widespread hearsay; the newer Public PoC value covers only public exploit code or a well-known method. Our script maps one to the other, which can understate cases CISA marked poc on private evidence.

A tested script that writes the ticket fields

The script reads a findings CSV, the KEV JSON, the EPSS daily file, the SSVC deployer CSV, a folder of CVE records and an optional OpenVEX file, and prints one ticket row per finding. Python 3.10 or later, standard library only.

#!/usr/bin/env python3
"""Turn scanner findings into patch-decision ticket rows.

Inputs : findings.csv (asset,product,cve,exposure,human_impact)
         KEV JSON, EPSS daily CSV (.csv.gz), SSVC deployer table CSV,
         a directory of cvelistV5 records, optional OpenVEX file.
Output : tickets.csv on stdout. Python 3.10+, standard library only.
"""
import csv, gzip, json, sys, argparse, pathlib

def load_kev(path):
    data = json.load(open(path))
    return {v["cveID"].strip().upper(): v for v in data["vulnerabilities"]}

def load_epss(path):
    scores = {}
    with gzip.open(path, "rt") as fh:
        rows = (line for line in fh if not line.startswith("#"))
        for r in csv.DictReader(rows):
            scores[r["cve"]] = (float(r["epss"]), float(r["percentile"]))
    return scores

def load_deployer(path):
    rows = list(csv.reader(open(path)))
    return {tuple(r[1:5]): r[5] for r in rows[1:]}

def load_vex(path):
    out = {}
    if path:
        for s in json.load(open(path)).get("statements", []):
            for p in s.get("products", []):
                out[(s["vulnerability"]["name"].upper(), p["@id"])] = s
    return out

def cisa_ssvc(record):
    """Return CISA ADP SSVC values (Exploitation, Automatable, Technical Impact, timestamp)."""
    for adp in record["containers"].get("adp", []):
        for m in adp.get("metrics", []):
            other = m.get("other", {})
            if other.get("type") == "ssvc":
                c = other["content"]
                opts = {k: v for o in c["options"] for k, v in o.items()}
                return (opts.get("Exploitation"), opts.get("Automatable"),
                        opts.get("Technical Impact"), c.get("timestamp"))
    return (None, None, None, None)

def main():
    ap = argparse.ArgumentParser()
    for a in ("findings", "kev", "epss", "deployer", "records"):
        ap.add_argument(a)
    ap.add_argument("--vex")
    args = ap.parse_args()
    kev, epss = load_kev(args.kev), load_epss(args.epss)
    table, vex = load_deployer(args.deployer), load_vex(args.vex)
    out = csv.writer(sys.stdout)
    out.writerow(["asset", "cve", "record_state", "vex_status", "kev_dateAdded",
                  "kev_dueDate", "kev_ransomware", "cisa_exploitation", "cisa_automatable",
                  "cisa_technical_impact", "cisa_ssvc_timestamp", "epss", "epss_percentile",
                  "deployer_exploitation", "deployer_priority", "next_step"])
    for f in csv.DictReader(open(args.findings)):
        cve = f["cve"].strip().upper()
        rec_path = pathlib.Path(args.records) / f"{cve}.json"
        if not rec_path.exists():
            out.writerow([f["asset"], cve, "NO RECORD"] + [""] * 12 + ["check the ID"])
            continue
        rec = json.load(open(rec_path))
        state = rec["cveMetadata"]["state"]
        if state == "REJECTED":
            out.writerow([f["asset"], cve, state] + [""] * 12 + ["close: CVE ID rejected"])
            continue
        v = vex.get((cve, f.get("product", "")), {})  # VEX applies to one product, not every asset
        k = kev.get(cve, {})
        exp, auto, ti, ts = cisa_ssvc(rec)
        e, pct = epss.get(cve, ("", ""))
        # Our policy choice: a KEV listing counts as active exploitation, whatever
        # the (possibly older) CISA ADP snapshot says. CISA writes "poc"; the
        # deployer table writes "public poc".
        dexp = "active" if k else {"poc": "public poc"}.get(exp, exp)
        prio = ""
        if dexp and auto:
            prio = table.get((dexp, f["exposure"], auto, f["human_impact"]), "")
        if v.get("status") == "not_affected":
            step = "close: supplier VEX not_affected (" + v.get("justification", "no justification") + ")"
        elif not prio:
            step = "manual triage: no CISA SSVC data"
        else:
            step = prio
        out.writerow([f["asset"], cve, state, v.get("status", ""), k.get("dateAdded", ""),
                      k.get("dueDate", ""), k.get("knownRansomwareCampaignUse", ""),
                      exp or "", auto or "", ti or "", ts or "", e, pct, dexp or "", prio, step])

if __name__ == "__main__":
    main()

The test input (findings.csv) used invented assets with real CVE IDs:

asset,product,cve,exposure,human_impact
edge-mail-01,fortimail,CVE-2026-104286,open,high
k8s-node-17,linux-kernel,CVE-2026-46300,controlled,medium
build-runner-03,pkg:cargo/gix-fs@0.22.1,CVE-2026-100419,small,medium
billing-api,pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1,CVE-2021-44228,open,very high
vendor-appliance-2,pkg:generic/example-appliance@4.2,CVE-2021-44228,open,very high
legacy-scan,unknown,CVE-2026-23915,open,low

The VEX file is an invented OpenVEX document from an “Example Appliance Vendor” stating not_affected with justification vulnerable_code_not_present for CVE-2021-44228 in pkg:generic/example-appliance@4.2. We ran:

python3 patch_decision.py findings.csv known_exploited_vulnerabilities.json \
  epss_scores-2026-11-01.csv.gz deployer_patch_application_priority_1_0_0.csv \
  records/ --vex vendor.openvex.json > tickets.csv

The data came from raw.githubusercontent.com/cisagov/kev-data, the empiricalsec/epss_scores repository (2026/epss_scores-2026-11-01.csv.gz), CERTCC/SSVC (data/csv/ssvc/) and CVEProject/cvelistV5 at commit 451e97a. Output, with some columns dropped for width:

Three things in that output are worth noticing:

• The same CVE got two different answers (Log4Shell rows) because the VEX statement applies to one product only.
• A KEV-listed kernel flaw came out Scheduled. CVE-2026-46300 is in KEV with forensicTriage: Yes and a three-day federal due date, but with controlled exposure, no automatability and medium Human Impact the deployer table says Scheduled. If you follow CISA’s directives, the due date wins. If you do not, the table is telling you the exposure is what drives urgency. Either way, keep both fields in the ticket, and consider a compromise check when forensicTriage is Yes; our BOD 26-04 explainer covers what that flag asks agencies to do.
• EPSS and KEV disagreed on FortiMail, as expected: one estimates future observed activity, the other records evidence already seen.

What the ticket should hold

Store the inputs, not just the priority, so a reviewer can see why. A suggested field list (ours, not a standard):

Keeping it current

The feeds move at different speeds: CISA updates KEV on weekdays, EPSS publishes daily, and CVE records and VEX documents change when their authors revise them. Re-run the flow on a schedule and on any change to a ticket’s inputs, and alert when a finding’s priority rises. Set your service-level targets per priority (for example, how many days “Out-of-cycle” means for you) in policy, not in the script; the deployer model does not define days.

Limits of this article

The script is a working example, not a product. It reads CVE records from a local folder (it does not fetch them), does not evaluate affected versions itself (pair it with a version check such as the evaluator in our affected-versions guide), handles OpenVEX JSON only, and uses one policy choice (KEV overrides an older CISA Exploitation value) that you may want to change. The four-value deployer inputs simplify real decisions: SSVC expects organizations to adapt trees to their context. We did not test it against commercial scanner exports.

Sources and verification