Prioritising Vulnerabilities Using CVSS and Exploit Intelligence

Why a severity number is only the beginning of a defensible remediation queue.

These are notes from problems I have actually wrestled with in vulnerability operations, not a claim that every feature is solved or that every customer has the same environment. I built VulnOps because the everyday work between finding a vulnerability and closing it deserved better tools.

A number is not a remediation plan

I have seen plenty of occasions where high or medium severity findings needed immediate attention while a critical-severity finding was less pressing in our specific environment. Browsers such as Chrome and Edge, Zoom and end-of-support .NET components can become urgent because of exploitation intelligence, how they are used and the available mitigation. A severity label is useful, but it is not a substitute for asking where the affected system sits, who can reach it and whether an attacker can realistically exploit the weakness. I was tired of pretending a single column in a CSV could answer all that.

The three-tab problem

Before I developed this workflow, prioritisation often involved navigating a Tenable SLA matrix and repeatedly moving between screens to find the affected vulnerability, its context and its owner. The user experience made work feel harder than the technical problem required. I wanted engineers to open one finding and understand the SLA, relevant exploit information, remediation pattern and operational status. For MSPs and MSSPs, the client agreement is not optional background information. The client SLA often determines escalation and deadlines even when another scoring system would rank the same finding differently.

Why the environment changes the answer

Our environment included network controls, Zscaler, firewalls and endpoint defence from CrowdStrike. Servers were not simply sitting on public IP addresses waiting for someone to scan them. That reduces some exposure paths, but it does not mean we are safe from every attacker. Some vulnerabilities matter most after an initial foothold, through lateral movement or privilege escalation. I prefer to document those assumptions rather than claim that a perimeter product makes an internal weakness irrelevant. When I see a low-reachability issue, I want the analysis to explain why it is lower priority and what would change that judgement.

Attack chains tell a more useful story

A CISO or CTO does not necessarily want to inspect fifty disconnected plugin IDs. They want to understand a credible path to an outcome: initial access, escalation, persistence and business impact. Mapping vulnerabilities to MITRE ATT&CK helps create that conversation. It is still a model, not evidence that an attacker has used that exact chain. The rapid availability of AI-assisted offensive and defensive tooling makes clear explanations even more important; simplistic statements that every path is easy to exploit are just as misleading as pretending the paths do not exist. My goal is to show plausible combinations and the assumptions underneath them.

Severity is a starting point, not a queue

A CVSS score expresses technical severity under defined assumptions, but it does not by itself tell an engineer which vulnerability to fix first on a particular Tuesday. A high-scoring issue in an isolated, unused component may be less urgent than a moderately scored flaw on an externally reachable management service. Vulnerability programmes need a repeatable method that balances severity, threat intelligence and business exposure. In VulnOps, ingesting findings is only the first phase. Classification and prioritisation need to account for whether the finding is relevant, whether exploitation has been observed and what operational consequences a fix might cause. The point is not to invent a magical score that replaces professional judgement. It is to make the decision explainable and update it when facts change.

Understand CVSS in context

CVSS is useful for comparing the technical characteristics of vulnerabilities, including exploitation prerequisites and potential impact. CVSS versions differ, so avoid comparing scores without recording the version and source. A base score does not know which service you expose to the internet, whether the application is essential to payroll or whether you have compensating controls in place. Use CVSS as a standardised severity input and then add contextual evidence about exposure, asset criticality and implementation. A vendor advisory may provide an important configuration nuance not visible in a generic scanner plugin. Treat missing scores as missing information, not automatically low risk. This matters because some newly published CVEs appear in vulnerability feeds before NVD enrichment or complete vendor metadata is available.

Add EPSS as a probability signal

FIRST's Exploit Prediction Scoring System estimates the probability of exploitation activity for a published CVE in the next 30 days. EPSS is not a severity metric and it cannot prove that your organisation is being attacked. Its percentile is a relative ranking, not the same as the probability itself. An EPSS value of 0.20 means an estimated 20 percent chance of observed exploitation activity somewhere in the ecosystem during that window, not a 20 percent chance that your specific server will be compromised. Record the observation date because EPSS is refreshed as threat data evolves. A low EPSS score must not override hard evidence of active exploitation or a high-consequence local exposure. It is best used to reduce guesswork among otherwise comparable findings.

Treat CISA KEV as known exploitation evidence

The CISA Known Exploited Vulnerabilities catalog identifies vulnerabilities with evidence of exploitation in the wild. A KEV entry is not merely a prediction that somebody might build an exploit someday. For affected technology, that is a strong escalation signal. Confirm applicability rather than mechanically prioritising every CVE in the catalog against an environment that does not run the affected component. Public proof-of-concept code, weaponised exploit availability and reports from your own monitoring may provide additional signals, but they have different evidentiary strength. Do not conflate proof of concept with widespread exploitation. A useful triage explanation says which signal raised the priority and when that signal was checked. Keeping the sources distinct makes the process auditable.

Bring in reachability and business impact

An internet-exposed VPN appliance, a management server reachable from a privileged network and a workstation application behind strong controls are not equivalent contexts. Examine the actual attack surface, authentication requirements, lateral-movement possibilities, service dependencies and potential impact of loss. Where asset-level details remain inside Tenable or other scanners under a data-minimisation model, the prioritisation workflow can reference the verified context without replicating a full network map. VulnOps also uses MITRE ATT&CK mappings and attack-chain concepts to connect weaknesses into plausible paths. Those paths are investigative hypotheses: an ATT&CK mapping alone does not demonstrate an exploitable chain or actual reachability. Security teams should validate the prerequisites before treating a visualised chain as an immediate breach route.

A practical triage decision

Consider two hypothetical findings. The first is an elevated CVSS issue on a non-exposed application that is not currently loaded, with no observed exploitation. The second has a lower base score but appears in KEV and affects an internet-facing service actively used by customers. The second likely deserves attention first, subject to the actual applicability and operational context. Document that rationale in a risk register with an owner, due date and an approved fallback when patching is unsafe. Reassess when a vendor publishes new mitigation guidance, a threat signal changes or an asset is moved to a different exposure zone. The best prioritisation system is not the one with the most decimal places. It is the one that consistently identifies urgent work and lets engineers explain why it moved to the front of the queue.

Engineering review checklist

Before using this approach in production, document the affected versions, prerequisite access, approval owner, intended change, test evidence, rollback limitations and independent validation criteria. Revisit the outcome after the next scan cycle. These checks help distinguish a successful script execution from a defensible security decision and prevent an incomplete change from being reported as closed.