# Vulnerability Management (/docs/operational-model/use-cases/vulnerability-management) ## SBOMs in vulnerability management [#sboms-in-vulnerability-management] When a CVE is published, the first question is whether the organization is 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 directly. 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 [#the-vulnerability-ecosystem] ### Advisory sources [#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 [#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](/docs/content-requirements/vulnerabilities#vulnerability-identifiers) for content requirements. ### Prioritization frameworks [#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 | Requires organizational input (mission impact, exposure context) | Organizations with defined risk appetite who need repeatable triage decisions. | | **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 [#overview-vulnerability-response-flow] ## Producer workflow [#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 [#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-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 [#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 [#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](/docs/operational-model/use-cases/regulatory-compliance) for the full regulatory context. ### Communicate [#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](/docs/operational-model/workflows/vulnerability-disclosure). ### Verify and record [#verify-and-record] 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 [#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-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](/docs/operational-model/use-cases/supplier-transparency) for how to assess and improve supplier data coverage. ### Correlate against advisories [#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 [#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 [#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](/docs/operational-model/use-cases/supplier-transparency)). ### Act and update risk register [#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 [#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](/docs/operational-model/use-cases/regulatory-compliance). ## Common pitfalls [#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_affected` VEX 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.