The decision pipeline
Start with the release inventory and identify components precisely. Correlate them with vulnerability sources. Investigate whether a candidate finding applies to that product configuration. Then connect an affected release to deployments and an owner who can remediate or document a risk decision.
A CVE identifier describes a vulnerability record. It does not itself prove that every similarly named package, or every product containing that package, is affected. Keep candidate matches separate from confirmed applicability.
Investigate matching uncertainty
| Matching issue | What to investigate |
|---|---|
| Name collision | Ecosystem, producer and namespace. |
| Version ambiguity | Resolved version, downstream patch or distribution backport. |
| Fork or repackaging | Supplier patch history and exact artifact evidence. |
| Range interpretation | Ecosystem-specific ordering and advisory affected ranges. |
| Bundled library | Whether vulnerable code is included in delivered bytes. |
| Environment conditions | Configuration, architecture and exposure prerequisites. |
Retain the matching rule and advisory revision so a later correction can explain why a finding changed. Review unresolved identities rather than counting them as clean components.
Use multiple kinds of intelligence
Package ecosystem advisories, supplier security notices, CVE-related intelligence and exploitation information can answer different questions. Record coverage by ecosystem, ingestion frequency, source timestamps, and handling of withdrawn or corrected records. A platform that advertises a feed may update only selected datasets.
Supplier advisories and VEX can communicate product-specific applicability. Evaluate their author, scope, product identifier, revision, justification and supporting evidence. Accepting a statement should be a recorded trust decision with a reevaluation trigger.
Source: CycloneDX · VEX capability.
Source: OpenVEX · Specification.
Prioritize the product risk
Consider actual exposure, exploitation evidence, affected functionality, compensating controls and the importance of the deployed product. A severity score is one input. The same component finding may need different responses in an isolated test tool and an externally reachable production service.
An inventory cannot reliably answer whether vulnerable code is reachable. Additional configuration evidence, analysis and testing may be necessary. Absence from an incomplete inventory cannot support a confident “not affected” conclusion.
Keep remediation and risk acceptance distinct
- Assign the finding to a product owner and verify the affected release.
- Determine update, replacement, configuration or compensating-control options.
- Record the applicability evidence and response decision.
- Implement and test the selected action.
- Generate or request the updated inventory when software changes.
- Verify deployment, then close the affected instances.
- Reopen when new evidence changes the decision.
Risk acceptance records who approved the remaining risk, why, for how long and under what conditions. It should not rewrite a vulnerability as absent or remove the component from the SBOM.
Run an incident drill before relying on the system
Select a known component in a retained release. Introduce a controlled advisory fixture and ask for the affected products, versions, deployed environments and owners. Then add a supplier applicability statement for one product version and verify that other versions remain in scope.
Measure elapsed time to a verified exposure list and account for unresolved assets. Test notification failure, feed interruption and a corrected advisory. A successful drill demonstrates a workflow; a chart of CVE counts demonstrates only aggregation.
Primary sources
- CycloneDX · VEX capabilitySpecification project documentation
- OpenVEX · SpecificationProject specification
- CISA and partners · 2026 Minimum Elements (ACSC publication)Published government guidance