Vulnerability Management
Using SBOMs and VEX to detect, assess, and act on vulnerabilities across producer and consumer workflows
Why Vulnerability Management Needs SBOMs
When a CVE drops, the first question is "are we affected?" Without a component inventory, answering that question means manual dependency audits and guesswork across teams. An organization with SBOMs can query its component inventory and have an answer in minutes. Without them, the same question takes days.
SBOMs make vulnerability management a structured process. Producers query their own SBOMs to identify affected products and versions. Consumers do the same against supplier SBOMs to determine portfolio-wide exposure. VEX documents add exploitability context, letting consumers distinguish real exposure from false positives.
The Vulnerability Ecosystem
Advisory Sources
Vulnerability information comes from multiple, partially overlapping sources:
- NVD (National Vulnerability Database) provides enriched CVE records with CVSS scoring for the US market. Operated by NIST.
- EUVD (European Vulnerability Database) serves as the EU's authoritative source, established under NIS2 (Article 12(2) of Directive (EU) 2022/2555). Relevant for organizations operating under CRA obligations.
- GitHub Security Advisories (GHSA) covers vulnerabilities in open source packages hosted on GitHub. Advisories are curated and linked to affected package versions.
- Supplier notifications arrive as CSAF advisories, VEX documents, or security bulletins from commercial vendors. Timeliness varies by supplier maturity.
- Internal findings from dependency scanners, SAST/DAST tools, penetration tests, and customer reports.
No single source is comprehensive. Mature security teams correlate findings across multiple feeds.
Vulnerability Identifiers
Two identifier schemes dominate:
- CVE (Common Vulnerabilities and Exposures) is the primary public identifier, assigned by CVE Numbering Authorities (CNAs). Most advisory sources reference CVEs.
- GHSA (GitHub Security Advisory) identifiers are GitHub-specific but map to CVEs when available.
For internally discovered vulnerabilities not yet assigned a CVE, use a consistent internal identifier scheme. See Vulnerability Identifiers for content requirements.
Prioritization Frameworks
Four frameworks address different aspects of vulnerability priority:
| Framework | What it measures | Strengths | Limitations | When to use |
|---|---|---|---|---|
| CVSS | Technical severity of the vulnerability itself | Widely adopted, standardized scoring | Does not account for exploit availability or environmental context | Baseline severity classification. Most advisories include a CVSS score. |
| EPSS | Probability of exploitation in the wild within 30 days | Data-driven, updated daily, addresses "will this actually be exploited?" | Probabilistic; less useful for targeted or novel attacks | Prioritizing across large vulnerability backlogs. Complements CVSS by adding likelihood. |
| SSVC | Decision outcome (track, track*, attend, act) based on exploitation status, exposure, and impact | Decision-tree approach maps directly to actions, not just numbers | Requires organizational input (mission impact, exposure context) | Organizations with defined risk appetite who need actionable decisions, not scores. |
| CISA KEV | Whether a vulnerability is known to be actively exploited | Binary signal with high confidence; backed by US government intelligence | US-centric, limited to confirmed exploitation | Immediate filter: anything on the KEV catalog warrants urgent attention regardless of CVSS score. |
A common approach: filter by CISA KEV first (known exploited = act immediately), then rank the remainder by EPSS exploitation likelihood. CVSS provides the baseline severity reference. SSVC adds repeatable triage decisions for organizations with defined risk appetite.
Overview: Vulnerability Response Flow
Producer Workflow
Producers detect, triage, patch, and communicate vulnerabilities affecting their own products. The SBOM serves as the authoritative component inventory at each step.
Detect
Vulnerability detection draws from dependency scanning in CI/CD pipelines, supplier advisories, public advisory databases, and internal tool results (SAST, DAST, penetration testing). Customer reports are an additional intake channel. Assign a single owner for each finding at intake. Unowned findings accumulate without resolution.
SBOM-aware scanning tools correlate findings directly against the component inventory. A dependency scanner that knows which version of a library shipped in which product version can report exact exposure rather than a generic "this library has a CVE."
Triage and Prioritise
Triage determines the response: fix, mitigate, accept, or defer. Each decision produces a different downstream action and a different VEX state.
Triage criteria combine framework scores with operational context:
- Severity (CVSS score and qualitative rating)
- Exploitation likelihood (EPSS score, CISA KEV status)
- Exposure context: is the affected component internet-facing? Reachable in the deployed configuration?
- Known exploitation: is this vulnerability being actively exploited in the wild?
Decision outcomes:
| Decision | When | VEX state | Required documentation |
|---|---|---|---|
| Fix | Exploitable, reachable, severity warrants code change | affected → fixed (after release) | Fix timeline, target release |
| Mitigate | Exploitable but fix is impractical short-term; workaround available | affected | Mitigation description, review date |
| Accept | Low severity or low exposure; risk within tolerance | not_affected (with justification) or affected (with rationale) | Time-bound acceptance with owner, expiry date, rationale |
| Defer | Insufficient information to decide | under_investigation | Investigation timeline, owner |
Set triage SLAs proportional to severity. Critical vulnerabilities triaged within 48 hours is a common target. Set remediation targets proportional to severity and exposure. Make them explicit and time-bound.
Patch and Update Dependencies
Fixing a vulnerability means either changing application code or updating an affected dependency.
For dependency updates, maintain a regular update cadence (weekly or monthly) independent of vulnerability response. Pin dependency versions to ensure reproducible builds and remove unused dependencies to reduce attack surface. Track transitive dependencies, not only direct ones; a vulnerability three levels deep in the dependency tree still ships in the product.
When updating a third-party component to address a vulnerability, verify that the update does not introduce regressions in authentication, input validation, or other security-critical paths.
Validate and Release
Before release, the CI/CD pipeline validates that vulnerability management obligations are met:
- Dependency scanning and SAST executed for this release
- All Critical and High findings addressed, or documented as exceptions with owner and expiry date
- SBOM generated or updated and stored for the release
- Known vulnerabilities triaged with severity, owner, and target date recorded
- Patch fixes reviewed, tests passed, release notes updated
Under the EU Cyber Resilience Act, security updates that fix vulnerabilities without changing the product's intended purpose are not considered substantial modifications. See Regulatory Compliance for the full regulatory context.
Communicate
After releasing a fix, update VEX and VDR documents to reflect the new status. Notify affected customers with: affected versions, severity, fixed version, and remediation guidance.
The full disclosure workflow, including VEX lifecycle state transitions, coordinated disclosure, upstream reporting, and authority notification, is covered in Vulnerability Disclosure.
Close the Loop
After communicating and releasing the fix:
- Verify that the update has been deployed or made available to affected customers
- Update the risk register with the final disposition
- Log any accepted risks with an owner and expiry date. Accepted risks without review dates become permanent.
Consumer Workflow
Consumers operate software they did not build. Their vulnerability management depends on supplier transparency: SBOMs for component visibility and VEX for exploitability context. Advisories provide notification when new issues arise.
Ingest Supplier SBOMs
Ingest updated SBOMs from suppliers on each software release. Store them in a system that supports querying across products, vendors, and component versions. Automated ingestion enables continuous correlation rather than point-in-time audits.
Suppliers who do not provide SBOMs leave a gap. Track which suppliers provide SBOMs and which do not. See Supplier Transparency for how to assess and improve supplier data coverage.
Correlate Against Advisories
When a vulnerability advisory arrives (CVE publication, CSAF document, VEX update from a supplier), query the ingested SBOM inventory for affected components. The query returns:
- Which products contain the affected component
- Which specific versions are deployed
- Where those products are deployed (if deployment metadata is tracked)
Correlate against multiple advisory sources. A CVE published in NVD and a supplier VEX statement may reference the same vulnerability with different timing and detail.
Assess Impact
Correlation identifies exposure. Impact assessment determines priority. Consider:
- System criticality: Is the affected product internet-facing, processing sensitive data, or supporting critical business functions?
- Exploitability in context: Does the supplier's VEX indicate the vulnerability is reachable in the product's configuration? Is it listed on the CISA KEV catalog?
- Dependency depth: Is the affected component a direct dependency or a transitive one buried in the tree?
- Remediation availability: Has the supplier released a patch, published a workaround, or acknowledged the issue?
Prioritize remediation based on the combination of these factors.
Track Supplier Responsiveness
Supplier maturity varies. Track how quickly and completely suppliers respond to vulnerabilities:
- Time-to-VEX: How long after a public CVE does the supplier issue a VEX statement indicating whether their product is affected?
- Time-to-patch: How long after acknowledging a vulnerability does the supplier release a fix?
- Time-to-advisory: How long after a fix is available does the supplier publish a security advisory?
These metrics surface suppliers who consistently lag in vulnerability response. Slow response from a supplier of a critical component is a supply chain risk. Options include escalation, contractual review, or alternative sourcing. Supplier responsiveness metrics feed into ongoing risk assessments (see Supplier Transparency).
Act and Update Risk Register
Based on the impact assessment:
- Apply the supplier's patch through normal update channels
- Implement a workaround if a patch is not yet available, and track the open item until it is
- Escalate to the supplier if no VEX, patch, or advisory has been provided within expected timelines
- Accept the risk with documented rationale, owner, and review date if the exposure is within tolerance
Update the internal risk register with the disposition. Link the entry to the specific advisory, affected products, and remediation action taken.
Regulatory Context
The EU Cyber Resilience Act imposes specific vulnerability management obligations on manufacturers of products with digital elements:
- No known exploitable vulnerabilities at release. Products must not be placed on the EU market with known exploitable vulnerabilities. "Exploitable" means an adversary can use the vulnerability under practical operational conditions.
- Vulnerability handling throughout the support period. Manufacturers must handle vulnerabilities effectively for the entire support period (minimum five years unless the product's expected use time is shorter).
- Reporting actively exploited vulnerabilities. Manufacturers must notify their national CSIRT coordinator and ENISA simultaneously: early warning within 24 hours, detailed notification within 72 hours, and a final report within 14 days of a corrective measure being available.
- Upstream reporting. Manufacturers who discover vulnerabilities in integrated third-party components must report the vulnerability to the component maintainer and share security fixes in a machine-readable format.
For the full regulatory context, including support period rules, the definition of "known exploitable vulnerability," and the distinction between security updates and substantial modifications, see Regulatory Compliance.
Common Pitfalls
- Treating CVSS as the sole prioritization input. A CVSS 9.8 that requires local access and is not exploited in the wild may be lower priority than a CVSS 7.5 on the CISA KEV catalog. Combine severity with exploitability and exposure context.
- Triaging without an SBOM. Without a component inventory, triage depends on manual investigation. Teams spend time determining whether a component is present rather than assessing whether the vulnerability is exploitable.
- Accepting risk without an expiry date. Accepted vulnerabilities without a review date become permanent fixtures. Set an owner and a review date for every accepted risk.
- Ignoring transitive dependencies. A vulnerability in a transitive dependency ships in the product just as a direct dependency does. Dependency trees, not just top-level manifests, determine exposure.
- No VEX for "not affected" findings. When a producer determines a CVE does not affect their product, that finding has value. Publishing a
not_affectedVEX statement saves downstream consumers from repeating the same analysis. - Monitoring one advisory source. NVD, EUVD, GitHub Advisories, and supplier feeds publish at different times with different coverage. Relying on a single source delays detection.