Vulnerability response deadlines and VEX
This page is the canonical reference for response deadlines by CVSS severity. When the process and vulnerability chapters cover response deadlines, they use this table and link here.
CVSS (Common Vulnerability Scoring System) expresses the severity of a vulnerability as a number between 0 and 10. Response deadlines are tiered by this score so that limited resources are used efficiently.
Response deadlines by CVSS severity
The following is the OpenChain KWG guide baseline.
| Severity | CVSS score | Response deadline (KWG baseline) | Action |
|---|---|---|---|
| Critical | 9.0~10.0 | Within 1 week | Patch immediately or deprecate |
| High | 7.0~8.9 | Within 4 weeks | Establish a priority patch plan |
| Medium | 4.0~6.9 | Within 1 month | Include in the next release |
| Low | 0.1~3.9 | Next release | Register in the backlog |
The deadlines above are the KWG baseline. Organizations with a higher risk profile (finance, infrastructure, external delivery, etc.) can apply a stricter internal SLA.
Example: Critical within 24 hours / High within 1 week — patch immediately or review service suspension. If you set an internal SLA, document it in output/process/vulnerability-response.md and apply that deadline first.
VEX — filtering out CVEs that don't affect you
Even when a component in an SBOM has a known CVE, the product is often not affected in practice (the vulnerable function is never called, the affected feature is unused, etc.). Treating every CVE the same way creates response noise.
VEX (Vulnerability Exploitability eXchange) is a standard artifact that states, for each CVE, "is this product actually affected?" Declaring "not affected" with a rationale lets you focus only on vulnerabilities that need action.
Key status values:
| Status | Meaning |
|---|---|
not_affected | Not affected (rationale required) — no action needed |
affected | Affected — act within the response deadline |
fixed | Already using a fixed version |
under_investigation | Investigating whether affected |
VEX is expressed in CycloneDX (the vulnerabilities field), OpenVEX, or CSAF, and is delivered alongside the SBOM down the supply chain.
This criterion is foundational knowledge for ISO/IEC 18974 §4.3.2 (vulnerability identification, assessment, and response).
Related documents
- Vulnerability analysis and response chapter guide — scan CVEs with grype and OSV and respond by these deadlines
- Open source process chapter guide — document response deadlines as an in-house process
- Vulnerability output best practices — completed CVE report and remediation plan examples