CVSS alone will not tell you what to patch first. A base score of 9.8 on an internal developer tool nobody can reach from the internet is not a fire. A base score of 7.5 on a Citrix appliance with active exploitation is your weekend. Prioritization is four factors, not one. Here is the model I use.

The four factors

  • Exploitation status. Is it on the CISA KEV list? Is there a public PoC? A working weaponized exploit? Active mass exploitation? This is the single strongest signal and it gets the most weight.
  • Exposure. Where does the affected asset live? Internet-facing, DMZ, internal flat network, segmented, air-gapped? An unpatched SSH server behind two firewalls and a bastion is a different problem than the same CVE on an edge load balancer.
  • Impact. What would compromise of this asset cost you? Crown-jewel data, production downtime, lateral movement into the domain, regulatory exposure. This is business-contextual and requires talking to people outside security.
  • Reversibility. How hard is remediation? A routine Windows patch is cheap. A firmware update on an OT device, a kernel upgrade on a legacy app server, or a schema change on a database cluster is not. Reversibility also captures rollback risk.

Score each factor 1–5, multiply exploitation and exposure (the "will they reach it" signal) and then weight by impact. Reversibility goes into the scheduling decision, not the priority decision.

Integrate with the CMDB or it does not work

Factor two and three live in your configuration management database. If the CMDB does not know an asset is internet-facing, or does not know it processes cardholder data, your score is garbage. Before you automate the scoring, spend a quarter making two CMDB fields reliable: network_exposure and business_criticality. Everything downstream depends on those.

Automation takes the vulnerability feed (Tenable, Qualys, your cloud provider's native scanner), joins to the CMDB, pulls KEV and EPSS, and produces a ranked queue. The queue is the ticket source of truth. Individual analysts do not re-prioritize; they challenge the score when they see context the data missed, and that challenge updates the rule.

Three examples

  • MOVEit Transfer (CVE-2023-34362). KEV within days, internet-facing by design, mass exploited, crown-jewel data in the typical deployment. Score: maximum. Response: emergency patch, then assume compromise and hunt.
  • Log4Shell (CVE-2021-44228). KEV, ubiquitous, weaponized within 24 hours. The hard part was not priority — priority was obvious. The hard part was exposure analysis, because the CMDB had no idea where Log4j was. Lesson: software bill of materials matters here, not just asset inventory.
  • SonicWall / Fortinet appliance CVEs. Recurring pattern — edge VPN or firewall, authenticated or unauthenticated RCE, immediate KEV listing, ransomware affiliates moving within days. These score maximum every time and deserve a pre-approved emergency change process.

Dealing with inherited technical debt

Every org has the legacy app that cannot be patched, the unsupported OS in a manufacturing line, the ancient database that runs payroll. The framework handles these by making them explicit:

  • Score them normally. Do not pretend the vulnerability is not there.
  • Document the compensating control: network isolation, allowlisted traffic, enhanced logging, compensating detection.
  • Set an expiration on the risk acceptance, with a named owner for the roadmap to replacement.
If your patching priorities do not change when CISA adds a CVE to KEV before lunch, your framework is decorative.

The takeaway

Take your top 100 open vulnerabilities. Score them against the four factors using data you actually have. You will find two things: a handful of items that are higher priority than your current system says, and a larger pile that is lower priority than your current system says. Rebalance the work. Defenders do not win by patching more; they win by patching what matters, before the adversary's tooling catches up.