How to prioritise security findings when you have hundreds

Why CVSS fails at volume

The Common Vulnerability Scoring System was designed for cross-vendor comparability, not for remediation decisions in a specific environment. A score of 9.8 (Critical) on a component running on an air-gapped server in a locked data centre with no internet access represents less risk than a score of 6.5 (Medium) on a publicly exposed payment API. In practice this leads teams to chase theoretical critical flaws while ignoring the ones attackers actually exploit. CIAD audits show that without asset and threat context, a CVSS-only focus wastes security team capacity.

Three dimensions to add to prioritisation

To reach an actionable queue, enrich every finding with three dimensions. First, exploitability and active exploitation: use the Exploit Prediction Scoring System (EPSS) or the CISA Known Exploited Vulnerabilities (KEV) catalogue. If a flaw appears in KEV it automatically jumps to the top regardless of CVSS. Second, asset exposure: determine whether the system is directly reachable from the internet, from a partner VPN, or only from an internal segmented network. An internet-facing asset raises priority by one tier. Third, business impact: assign the asset a criticality class based on the data it processes (payment cards, health records, public web) and its recovery time objective (RTO).

Four-step practical process

Step one, data enrichment: connect scanner output (Nessus, OpenVAS, Qualys) with the CMDB and threat intelligence feeds (EPSS, KEV). Automate the addition of tags such as internet-facing, pci-dss, kev-listed. Step two, risk score calculation: apply a simple formula: Priority = (CVSS_Base * Weight_CVSS) + (EPSS * Weight_EPSS) + Exposure_Bonus + Impact_Bonus. Set weights according to organisational policy, for example exposure at twice the weight of CVSS. Step three, bucketisation: split findings into three buckets: Immediate (kev-listed plus internet-facing), Week (high EPSS plus critical asset), Sprint or Backlog (the rest). Step four, review and communication: walk through the Immediate bucket weekly with application owners. Document the rationale for any deferral, for instance a compensating control such as a WAF rule or network segmentation.

Worked example: e-shop with 200 findings

The scanner reported 15 findings with CVSS 9.0 or above. After enrichment, three were in KEV but only one sat on an internet-facing web server (the others on internal databases). Two findings had CVSS 6.5 but EPSS 0.95 and resided on the payment gateway. Result: the Immediate bucket received three findings (one critical internet-facing plus two payment-related). The team fixed three instead of 15 and covered 80 percent of real risk in the first week.

What this means for decision-making

Prioritisation is not about fixing everything. It is about quickly identifying what an attacker will actually exploit. The combination of CVSS, exploitation evidence, exposure and impact gives you a decision framework you can defend to management and auditors alike.