CVE Prioritization 2026

Not all CVEs are equal. The prioritization.

CVSS

The Common Vulnerability Scoring System (CVSS) is the standard way to rate vulnerability severity. CVSS scores range from 0 to 10, with 7.0 to 8.9 marked High and 9.0 to 10.0 marked Critical. The score is a useful starting point for prioritization but it is not the prioritization itself. A team that patches in CVSS-score order alone is doing it wrong.

What CVSS provides and what it leaves out:

• CVSS score is a starting point.: The base score captures inherent severity: how easy is exploitation, how much damage can the attacker cause, what authentication is required. The score is calculated by the assigning organization (NVD, vendor, or researcher). It is consistent enough to be a useful first filter.
• Adjust by exploitability.: A 9.8 CVSS that requires authenticated network access is less urgent than a 9.0 CVSS that is exploited in the wild without authentication. The team adjusts using exploitability data: KEV catalog, EPSS scores, threat intel feeds. The adjustment changes priority.
• Adjust by asset criticality.: A 9.0 on a development sandbox matters less than a 7.0 on a production payment processor. The asset's role in the business affects priority. The team's CMDB or asset inventory provides the criticality data.
• Don't just take the score.: Patching in raw CVSS order produces wasted effort on low-impact patches and ignores high-impact ones. The team uses CVSS as input, not output. The output is a prioritized list that reflects exploitability, asset criticality, and business context.
• Temporal score helps.: CVSS includes temporal metrics (exploit code maturity, remediation level) that update as situational awareness changes. Use the temporal score when available; it captures the current state better than the base score alone.

CVSS is a good starting point and a poor ending point. The next step is context.

Context

The CVSS score does not know whether your specific deployment exposes the vulnerability. The context layer answers that question: is the affected component installed, is it reachable, what data does it touch, what compensating controls exist?

• Internet-facing changes priority.: A vulnerability on an internet-facing system is fundamentally different from the same vulnerability on an internal system. Internet-facing vulnerabilities can be exploited by anyone; internal vulnerabilities require an attacker who is already inside. The priority adjustment is significant.
• Critical asset changes priority.: The asset's role determines the impact of compromise. A vulnerability on the customer database is higher priority than the same vulnerability on a non-production system. The team's asset inventory drives the adjustment.
• Compensating controls reduce priority.: A vulnerability mitigated by a WAF rule, a network segmentation control, or an authentication wall is lower priority than the same vulnerability without mitigation. The compensating control reduces real risk; the priority reflects the residual risk.
• Per-deployment context matters.: Two organizations with the same vulnerability often have very different priority. The deployment context (network exposure, asset criticality, compensating controls, data sensitivity) is unique to each organization. The prioritization is local; the CVSS score is universal.
• Threat intelligence enriches.: Active exploitation in the wild raises priority. Threat intel feeds (CISA KEV, vendor advisories, OSINT) provide the signal. Vulnerabilities being actively exploited get fast-tracked regardless of CVSS score.

Context is the difference between a generic vulnerability list and a usable patch queue. The same vulnerability is different priorities to different organizations.

Respond

The response SLA is the contract between the security team and the business: this is how fast we promise to fix vulnerabilities at each severity tier. The SLA is bounded so the security team can plan capacity; it is defensible so audit and compliance discussions are short.

• Critical: 7-day SLA.: Critical vulnerabilities are fixed within 7 days from the time they are confirmed in the environment. The window covers analysis, patch, test, deploy. The 7-day target is aggressive but achievable for genuine criticals.
• High: 30-day SLA.: High-severity vulnerabilities are fixed within 30 days. The window covers more deliberate testing and rollout. The 30-day target is the industry-standard PCI/HIPAA expectation.
• Medium: best-effort.: Medium-severity vulnerabilities are addressed in the regular patching cadence. There is no hard SLA; they get attention as part of normal cycles. The team commits to addressing them; not to a specific timeline.
• Bounded.: Each tier has a clear boundary. The team knows what is in each tier and the expected timeline. The bounded scope prevents the medium tier from absorbing everything.
• Defensible.: The SLA is documented and shared with auditors, customers, and the board. When an audit asks "what is your vulnerability response SLA?" the team has a clear answer. The SLA is reviewed and tightened over time as capability improves.

CVE prioritization done well looks invisible: the right vulnerabilities are fixed at the right pace, the team is not buried in noise, and the audit conversations are short. Nova AI Ops integrates with vulnerability scanners, applies the prioritization layer, and produces the queue that the engineering team actually works from.