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 as the baseline 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 Critical and High deadlines are the OpenChain KWG guide baseline. Because the KWG guide does not define deadlines for Medium and Low, those are trustedoss recommendations.
| Severity | CVSS score | Response deadline | Source | Action |
|---|---|---|---|---|
| Critical | 9.0~10.0 | Within 1 week | KWG baseline | Patch immediately or stop using |
| High | 7.0~8.9 | Within 4 weeks | KWG baseline | Establish a priority patch plan |
| Medium | 4.0~6.9 | Within 1 month | trustedoss recommendation | Include in the next release |
| Low | 0.1~3.9 | Next release | trustedoss recommendation | Register in the backlog |
Of the deadlines above, Critical and High 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 consider suspending the service. If you set an internal SLA, document it in output/process/vulnerability-response.md and apply that deadline first.
What to Do With a CVE That Has No CVSS Score
Starting 2026-04-15, NIST shifted NVD (National Vulnerability Database) enrichment to a risk-based approach. It prioritizes CVEs in the CISA KEV (Known Exploited Vulnerabilities) catalog, software used by the federal government, and software defined as critical under EO 14028, filing everything else as "Not Scheduled." The table above assumes a CVSS score exists; as unscored CVEs keep piling up, supplement it with the two signals below.
| Signal | Meaning | How to use it for priority |
|---|---|---|
| KEV | CISA's catalog of vulnerabilities confirmed to be actively exploited | If listed, treat it as Critical/High regardless of CVSS score |
| EPSS | A predictive model scoring the probability of exploitation within 30 days | A high score (e.g. 0.1+) bumps response priority up one tier |
Even a CVE with no CVSS score deserves a Critical/High-equivalent response if it is listed in KEV or scores high on EPSS. To supplement NVD, you can also query ENISA's EUVD (European Union Vulnerability Database) and GCVE (Global CVE, db.gcve.eu), run by a federation of GCVE Numbering Authorities. Both cross-reference CVE identifiers, so adding them does not require a major change to your existing workflow.
VEX — Filtering Out CVEs That Do Not Affect You
Even when a component in an SBOM has a known CVE, the actual product is often not affected by that vulnerability (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, whether this product is 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, CSAF, or SPDX 3.0
(relationship-based expression), and is delivered along with the SBOM through the supply
chain.
All four formats above are actually in use, and none has become the single standard. If a
customer specifies a format, follow it; otherwise, since you are likely already producing a
CycloneDX SBOM, starting with the same CycloneDX vulnerabilities field is the easiest to
wire into your existing tooling.
These criteria are foundational knowledge for the ISO/IEC 18974 §4.3.2 (vulnerability identification, assessment, and response) requirement.
EU CRA Reporting Obligation: A Separate Regulatory Deadline From the SLA Above
The CVSS-based deadlines above are an internal SLA for when you finish patching. The EU Cyber Resilience Act (CRA, Regulation (EU) 2024/2847) sets a separate regulatory obligation for when you must report a confirmed fact to authorities. Do not conflate the two. For example, even if your internal patch SLA for a Critical vulnerability is one week, if it is actively exploited, the report must go out within 24 hours.
This obligation applies only to manufacturers placing products with digital elements on the EU market. If you only build software for domestic use, it does not apply. Confirm with legal counsel whether your organization is in scope for the CRA.
| Stage | Deadline | Recipient |
|---|---|---|
| Early warning | Within 24 hours of becoming aware | Competent CSIRT + ENISA |
| Notification | Within 72 hours of becoming aware | Competent CSIRT + ENISA |
| Final report | Within 14 days after a corrective/mitigating measure is available (exploited vulnerability) or within 1 month of the notification (severe incident) | Competent CSIRT + ENISA |
Reports go to the CSIRT designated by the member state (per NIS2 Article 12) and to ENISA, in practice through the single reporting platform ENISA operates. This obligation applies from 2026-09-11; the CRA's other obligations (product requirements, etc.) apply in full from 2027-12-11.
For the primary source, see Article 14 of the CRA text (EUR-Lex, Regulation (EU) 2024/2847). These deadlines reflect the regulation as of this writing; implementing guidance is still being issued, so confirm the latest official guidance before filing an actual report.
Related Documents
- Vulnerability Analysis and Response chapter guide — scan CVEs with grype and OSV and respond within these deadlines
- Open Source Process chapter guide — document response deadlines as an in-house process
- Vulnerability Deliverable Best Practices — completed CVE report and remediation plan examples