Why CVSS is not enough to prioritize patches by risk
CVSS has long been the only language of vulnerability management with business and IT. Vulnerability with CVSS 9.8 - critical, patch immediately. CVSS 4.0 - can wait. In practice, this logic is falling apart.
CVSS evaluates the technical severity at the time of disclosure and is almost never recalculated. It does not take into account the probability of real exploitation: CVE with a rating of 9.8 may not have a public exploit at all, and CVE with a rating of 6.5, under which the working PoC is written, is in operation for the third month. CVSS doesn’t know your infrastructure – a critical vulnerability in Apache Struts is pointless if Struts don’t turn on any asset. But the scanner will show it in the report if he finds it in dependencies.
The scale is growing. The NVD enriches tens of thousands of CVE per year – and that’s not enough to cover the incoming stream. NIST has announced a transition to selective enrichment: CVE from the KEV CISA, federal software and software, which falls under the definition of “critical” from Executive Order 14028, are given priority. The remaining CVE can remain without enrichment indefinitely. Essentially, the NVD ceases to be a “universal layer of broadcasting” between vulnerability disclosure and surgery.
The conclusion for the team: it is no longer possible to wait for the final score from the NVD before making decisions. You need your own conveyor, which works faster than NVD and takes into account the context of the environment.
Comparison of Vable Prioritization Methods
CISA KEV directory of vulnerabilities: conveyor reference point
KEV (Known Exploited Vulnerabilities) is a CISA catalog with vulnerabilities confirmed by exploited in real attacks. Unlike NVD, KEV is not the base of all known CVE, but a list of those that have already been used by attackers for Exploit Public-Facing Application (T1190, Initial Access) and similar vectors. Each entry contains: CVE identifier, vendor, product, description, date of addition and date of mandatory elimination (dueDate) for federal agencies.
For Blue Team KEV, it works as a binary signal: CVE is in the catalog - it is operated right now, and it hits the top of the backlog without respect for CVSS. The catalog is available through a public API without registration and keys - a clean for information security.
BOD 22-01: Mandatory elimination of vulnerabilities from KEV
In November 2021, CISA published Binding Operational Directive 22-01Obliging federal agencies to address vulnerabilities from the KEV catalog within the terms set by CISA for each record (podDate field). The directive formalized the risk-oriented approach: prioritization is based not on CVSS, but on the fact of confirmed operation in-the-wild.
A key shift: the criterion for immediate response is the presence of a CVE in KEV, not a numerical CVSS-score. Public availability of the asset, the ability to automate the operation and the criticality of the system for the mission are additional factors that CISA recommends in mind when determining priorities. We put this logic in the assembly line.
Open CVE Monitoring Sources for Blue Team Threatening Intelligence
Before assembleing a conveyor - a map of available sources. Everyone's free.
Vendoritions and CNA sources - direct from vendors and CNA become primary operating sources. CVE.org, GitHub Security Advisories, Red Hat Security Advisories
MITRE ATT&CK - Mapping vulnerabilities on attacking tactics. CVE, which is happened on Exploit Public-Facting Application (T1190, Initial Access), is a priority for the vulnerability requiring local access and privileges (Exploitization for Privilege Escalation, T1068).
Risk-oriented patching: asset binding and SSVC
Conveyor without binding to assets - academic exercise. Need inventory: what products and versions are deployed. In terms of NIST CSF v2.0 ID.AM-01 - inventory of hardware and software assets. Sources of inventory: CMDB (ServiceNow, GLPI, NetBox) through APIs, scans (Nessus, OpenVAS), Software Discovery data (T1518, Discovery). Comparison - by CPE from NVD or by pair of vendor+product from KEV.
For final priority, SSVC is used - the model recommended by CISA. The decision is made on wood:
1. Exploitation - is there active operation? KEV = yes; EPSS > 0.5 = probable
2. Automatch - an attacker can automate operation? Public PoC, weaponsized exploit
3. Technical Impact - full control (RCE) or partial (information disclosure)?
4. Mission Prevalence - how much negative is the affected asset for business processes?
The result is one of three actions:
• Act - immediate elimination (within the terms of BOD 22-01). Example: CVE in KEV, EPSS > 0.7, on a publicly accessible web server with business data
• Attend - elimination in the near cycle (14 days). Example: CVE with high EPSS, but on the internal server for VPN
• Track - monitoring, elimination by schedule (60 days). Example: the same CVE on an isolated test bench
The Black Kite approach from the Chain Vulnerability Report shows the scale of the filtration: of the 780 high-priority CVE, only 295 were-detectable (the attacker can find a vulnerable system via Shodan / Censys), and after the application of EPSS and KEV filters, the number has been reduced to a controlled ten. The four-entry model - detection, EPSS/KEV, the effect on supply chain, combined evaluation - is applicable to internal infrastructure.
Automation and integration of the pump management assembly line
A script that runs manually once a month is not a conveyor. Conveyor - process with schedule, notifications and feedback.
Schedule. cron on Linux or Task Scheduler on Windows. KEV is updated several times a week, EPSS - daily. Reasonable frequency - once a day, in the morning before the start of the working day. I usually bet on 06:00 - to the arrival of the team digest is already in the channel.
Storage. The results of each run are preserved. Minimum - JSON files with time stamps. For more teams - Elasticsearch or PostgreSQL. This allows you to track the dynamics: new CVE in KEV, changing EPSS-score, overdue SLA.
Notifications. When CVE appears with the decision of Act - an immediate alter to Telegram, Slack or MS Teams. For Attend - daily digest. For Track, it's a weekly report. Integration through the webhook takes an hour.
Ticket system. Each CVE with the Act or Attend solution automatically creates a ticket in Jira, YouTrack or GLPI: CVE-ID affected by the asset, EPSS-score, SLA of KEV dueDate. The responsible person is appointed by the owner of the CMDB asset.
Restrictions on the approach. The free API conveyor does not replace commercial management (Tenable, Qualys, Rapid7). It closes the blind spot: the speed of reaction to the new CVE in KEV, the priority of EPS instead of CVSS, transparency of solutions. For infrastructure with 10 000+ CVE in the scanning results will require local cesting NVD and EPSS data - the daily full dump EPSS weighs several tens of MB (relevant size - on api.first.org).
Checklist Vulnerability Monitor Conveyer
A ready-made list of actions - you can transfer to a colleague or included in the report.
1. Configure the daily CISA KEV API survey, save the delta (new entries) to local storage
2. Connect the EPSS API (FIRST.org), enrich every CVE from KEV and scan results
3. Get free NVD API key to increase the query limit to 50/30 sec
4. Export inventory of assets from CMDB or scanner, link to CPE vendor or +product
5. Implement a matching: for each asset to determine the applicable CVE from KEV and top EPSS
6. Apply SSVC-tree: for each CVE determine the solution - Act, Attend, Track
7. Customize alertes: Act - immediate notification, Attend - daily digest
8. Integrate with the ticket system: Act/Attend - automatic ticket with SLA
9. Add OSV API to cover open-source dependencies (if applicable)
10. Configure the weekly report: open CVE by category, weekly dynamics, expired SLA
Three months of operation of the conveyor will show the pattern: which owners of the systems do not fit into the SLA, what classes of vulnerabilities repeat, where the inventory is incomplete. This data for conversation with management is not an abstract “level of security”, but specific metrics.
Teams that try to close every CVE with CVSS >= 7 burn out in two quarters. The backlog grows faster than people work, motivation falls, the process turns into a formality - a tick for audit. Those who build a priority on evidence (KEV, EPSS, the context of the asset) close less than CVE but necessary. The difference is visible in the number of incidents, and not among the closed tickets.
BOD 22-01 captures the correct vector: from “patchs everything on CVSS” to “patches that are exploited, on what is sticking out.” Tools for this are free - KEV, EPSS, NVD API, OSV. Deficit is not in data, but in the discipline: daily run, correlation with assets, honest accounting of overdue SLAs.
CVSS has long been the only language of vulnerability management with business and IT. Vulnerability with CVSS 9.8 - critical, patch immediately. CVSS 4.0 - can wait. In practice, this logic is falling apart.
CVSS evaluates the technical severity at the time of disclosure and is almost never recalculated. It does not take into account the probability of real exploitation: CVE with a rating of 9.8 may not have a public exploit at all, and CVE with a rating of 6.5, under which the working PoC is written, is in operation for the third month. CVSS doesn’t know your infrastructure – a critical vulnerability in Apache Struts is pointless if Struts don’t turn on any asset. But the scanner will show it in the report if he finds it in dependencies.
The scale is growing. The NVD enriches tens of thousands of CVE per year – and that’s not enough to cover the incoming stream. NIST has announced a transition to selective enrichment: CVE from the KEV CISA, federal software and software, which falls under the definition of “critical” from Executive Order 14028, are given priority. The remaining CVE can remain without enrichment indefinitely. Essentially, the NVD ceases to be a “universal layer of broadcasting” between vulnerability disclosure and surgery.
The conclusion for the team: it is no longer possible to wait for the final score from the NVD before making decisions. You need your own conveyor, which works faster than NVD and takes into account the context of the environment.
Comparison of Vable Prioritization Methods
CISA KEV directory of vulnerabilities: conveyor reference point
KEV (Known Exploited Vulnerabilities) is a CISA catalog with vulnerabilities confirmed by exploited in real attacks. Unlike NVD, KEV is not the base of all known CVE, but a list of those that have already been used by attackers for Exploit Public-Facing Application (T1190, Initial Access) and similar vectors. Each entry contains: CVE identifier, vendor, product, description, date of addition and date of mandatory elimination (dueDate) for federal agencies.
For Blue Team KEV, it works as a binary signal: CVE is in the catalog - it is operated right now, and it hits the top of the backlog without respect for CVSS. The catalog is available through a public API without registration and keys - a clean for information security.
BOD 22-01: Mandatory elimination of vulnerabilities from KEV
In November 2021, CISA published Binding Operational Directive 22-01Obliging federal agencies to address vulnerabilities from the KEV catalog within the terms set by CISA for each record (podDate field). The directive formalized the risk-oriented approach: prioritization is based not on CVSS, but on the fact of confirmed operation in-the-wild.
A key shift: the criterion for immediate response is the presence of a CVE in KEV, not a numerical CVSS-score. Public availability of the asset, the ability to automate the operation and the criticality of the system for the mission are additional factors that CISA recommends in mind when determining priorities. We put this logic in the assembly line.
Open CVE Monitoring Sources for Blue Team Threatening Intelligence
Before assembleing a conveyor - a map of available sources. Everyone's free.
Vendoritions and CNA sources - direct from vendors and CNA become primary operating sources. CVE.org, GitHub Security Advisories, Red Hat Security Advisories
MITRE ATT&CK - Mapping vulnerabilities on attacking tactics. CVE, which is happened on Exploit Public-Facting Application (T1190, Initial Access), is a priority for the vulnerability requiring local access and privileges (Exploitization for Privilege Escalation, T1068).
Risk-oriented patching: asset binding and SSVC
Conveyor without binding to assets - academic exercise. Need inventory: what products and versions are deployed. In terms of NIST CSF v2.0 ID.AM-01 - inventory of hardware and software assets. Sources of inventory: CMDB (ServiceNow, GLPI, NetBox) through APIs, scans (Nessus, OpenVAS), Software Discovery data (T1518, Discovery). Comparison - by CPE from NVD or by pair of vendor+product from KEV.
For final priority, SSVC is used - the model recommended by CISA. The decision is made on wood:
1. Exploitation - is there active operation? KEV = yes; EPSS > 0.5 = probable
2. Automatch - an attacker can automate operation? Public PoC, weaponsized exploit
3. Technical Impact - full control (RCE) or partial (information disclosure)?
4. Mission Prevalence - how much negative is the affected asset for business processes?
The result is one of three actions:
• Act - immediate elimination (within the terms of BOD 22-01). Example: CVE in KEV, EPSS > 0.7, on a publicly accessible web server with business data
• Attend - elimination in the near cycle (14 days). Example: CVE with high EPSS, but on the internal server for VPN
• Track - monitoring, elimination by schedule (60 days). Example: the same CVE on an isolated test bench
The Black Kite approach from the Chain Vulnerability Report shows the scale of the filtration: of the 780 high-priority CVE, only 295 were-detectable (the attacker can find a vulnerable system via Shodan / Censys), and after the application of EPSS and KEV filters, the number has been reduced to a controlled ten. The four-entry model - detection, EPSS/KEV, the effect on supply chain, combined evaluation - is applicable to internal infrastructure.
Automation and integration of the pump management assembly line
A script that runs manually once a month is not a conveyor. Conveyor - process with schedule, notifications and feedback.
Schedule. cron on Linux or Task Scheduler on Windows. KEV is updated several times a week, EPSS - daily. Reasonable frequency - once a day, in the morning before the start of the working day. I usually bet on 06:00 - to the arrival of the team digest is already in the channel.
Storage. The results of each run are preserved. Minimum - JSON files with time stamps. For more teams - Elasticsearch or PostgreSQL. This allows you to track the dynamics: new CVE in KEV, changing EPSS-score, overdue SLA.
Notifications. When CVE appears with the decision of Act - an immediate alter to Telegram, Slack or MS Teams. For Attend - daily digest. For Track, it's a weekly report. Integration through the webhook takes an hour.
Ticket system. Each CVE with the Act or Attend solution automatically creates a ticket in Jira, YouTrack or GLPI: CVE-ID affected by the asset, EPSS-score, SLA of KEV dueDate. The responsible person is appointed by the owner of the CMDB asset.
Restrictions on the approach. The free API conveyor does not replace commercial management (Tenable, Qualys, Rapid7). It closes the blind spot: the speed of reaction to the new CVE in KEV, the priority of EPS instead of CVSS, transparency of solutions. For infrastructure with 10 000+ CVE in the scanning results will require local cesting NVD and EPSS data - the daily full dump EPSS weighs several tens of MB (relevant size - on api.first.org).
Checklist Vulnerability Monitor Conveyer
A ready-made list of actions - you can transfer to a colleague or included in the report.
1. Configure the daily CISA KEV API survey, save the delta (new entries) to local storage
2. Connect the EPSS API (FIRST.org), enrich every CVE from KEV and scan results
3. Get free NVD API key to increase the query limit to 50/30 sec
4. Export inventory of assets from CMDB or scanner, link to CPE vendor or +product
5. Implement a matching: for each asset to determine the applicable CVE from KEV and top EPSS
6. Apply SSVC-tree: for each CVE determine the solution - Act, Attend, Track
7. Customize alertes: Act - immediate notification, Attend - daily digest
8. Integrate with the ticket system: Act/Attend - automatic ticket with SLA
9. Add OSV API to cover open-source dependencies (if applicable)
10. Configure the weekly report: open CVE by category, weekly dynamics, expired SLA
Three months of operation of the conveyor will show the pattern: which owners of the systems do not fit into the SLA, what classes of vulnerabilities repeat, where the inventory is incomplete. This data for conversation with management is not an abstract “level of security”, but specific metrics.
Teams that try to close every CVE with CVSS >= 7 burn out in two quarters. The backlog grows faster than people work, motivation falls, the process turns into a formality - a tick for audit. Those who build a priority on evidence (KEV, EPSS, the context of the asset) close less than CVE but necessary. The difference is visible in the number of incidents, and not among the closed tickets.
BOD 22-01 captures the correct vector: from “patchs everything on CVSS” to “patches that are exploited, on what is sticking out.” Tools for this are free - KEV, EPSS, NVD API, OSV. Deficit is not in data, but in the discipline: daily run, correlation with assets, honest accounting of overdue SLAs.
