To use a VEX statement, you must be able to say that its product identifier refers to something in your SBOM. Package URLs, hashes and CPE strings are the usual bridges. Match on the most specific identifier available, and treat anything ambiguous as unmatched until the supplier clarifies.
Why matching is the hard part
CISA says product and subcomponent identifiers should use existing well-known identifiers and should reference existing SBOM identifiers. It also allows them to be URIs, hashes, commit IDs, version ranges or even arbitrary values created by the author. That flexibility means two files can describe the same software in unlike ways.
What OpenVEX supports
OpenVEX gives a product an identifier plus an identifiers map. The recognised types are purl, which the spec recommends, cpe22 and cpe23. It also supports hashes keyed by algorithm, such as sha-256. No single mechanism is mandatory, but a valid statement must identify a product somehow.
Product versus subcomponent
CISA describes a common pattern: the vulnerable subcomponent is affected, while the product that contains it is not. In that case the statement names the product, and lists the subcomponent. In OpenVEX, subcomponents use the same identifier fields as products, should carry software identifiers, and should be listed in the product's SBOM.
For you as a consumer, that means two joins:
- Match the statement's product to the product you deploy.
- Match its subcomponent to a component in that product's SBOM.
If either fails, the statement does not apply cleanly.
A matching routine
- Normalise your SBOM identifiers to package URLs where possible.
- Try an exact match on hash. A hash identifies a specific artifact.
- Try an exact match on package URL including version.
- Fall back to a CPE match, and flag it as lower confidence.
- If the statement uses a version range, evaluate your version against it explicitly.
- Anything left is unmatched. Do not apply it.
Typical mismatches
- The supplier lists a product family, you run one version.
- The SBOM lists a component under a different ecosystem name than the VEX file.
- The VEX file refers to a build identifier that your SBOM does not record.
For each, send the supplier a short question rather than guessing.
Keep the link in your records
When you close a finding on the strength of a VEX statement, record the document identifier, its version and the matched identifier. If the match was weak, say so.
Quick check
Is a package URL enough to match?
Usually, if it includes the version and ecosystem. A hash is stronger because it pins a specific artifact.
What if there is no SBOM to match against?
Matching becomes manual. Generating an SBOM for what you deploy is the first step.
Safeguard can generate and scan SBOMs and dependency trees, and the free scan at https://gold.safeguard.sh/scan is a quick way to see your component identifiers.
Sources
Last reviewed: 19 October 2026.
