Vulnerability Prioritization: Beyond CVSS Scores

CVSS scores alone do not indicate actual risk to your organization. After eighteen years of penetration testing I can tell you that blindly following CVSS has led many organizations to fix the wrong things first. I have seen companies spend weeks patching a CVSS 9.8 vulnerability on an isolated internal test server while ignoring a CVSS 6.5 issue on their internet-facing payment gateway. The test server posed essentially zero real-world risk; the payment gateway vulnerability was actively being exploited in the wild.

Factors Beyond CVSS

CVSS measures the technical characteristics of a vulnerability in isolation. Real risk depends on context that only you and your penetration tester can provide.

• Asset criticality - A vulnerability on your core banking platform is fundamentally different from the same vulnerability on an internal wiki. I always ask clients to provide an asset inventory with business criticality ratings before the engagement begins.
• Exposure - Is it internet-facing or internal? Behind a VPN? The attack surface dramatically affects exploitation likelihood. A critical vulnerability behind three layers of network segmentation is less urgent than a medium vulnerability directly accessible from the internet.
• Exploit availability - Is there a public Metasploit module or proof-of-concept? Vulnerabilities with readily available exploit code move to the top of the priority list because the barrier to exploitation is essentially zero.
• Data sensitivity - Access to public marketing content is a very different concern than access to customer financial data or health records. The type and volume of data at risk should heavily influence prioritization.

Prioritization Matrix

I use a contextual prioritization matrix that combines technical severity, asset criticality, exposure, and exploit availability.

• Critical - Fix within 24-48 hours. Internet-exposed vulnerabilities on critical assets with available exploits. I typically identify one to three of these per engagement, and I communicate them immediately upon discovery.
• High - Fix within 1-2 weeks. Serious vulnerabilities on important systems that require prompt attention but allow for change management processes.
• Medium - Fix within 30 days. Real vulnerabilities with mitigating factors such as limited exposure or lower asset criticality.
• Low - Fix when convenient. Informational findings, best-practice deviations, and defense-in-depth improvements.

Attack Chain Consideration

Sometimes a medium vulnerability enables a critical attack path. Individual findings do not exist in isolation. A medium-severity information disclosure might reveal internal network architecture that makes exploiting a different vulnerability trivial. A low-severity default credential on an internal service might provide the foothold needed to pivot to a critical database server. I always map out attack chains in my reports. I have had engagements where five individually medium-rated findings combined into a chain that gave me domain administrator access from the internet. No single finding would have triggered urgent remediation, but the chain represented a critical risk.

Practical Approach

Here is the framework I use to translate findings into an actionable remediation plan.

1. Identify crown jewels - work with stakeholders to define the three to five most critical assets whose compromise would cause the most significant business impact
2. Map attack paths to them - trace every finding back to potential paths leading to critical assets
3. Prioritize path interruption - fix the vulnerability that breaks the most attack paths, sometimes a single fix on a critical chokepoint eliminates multiple paths
4. Balance quick wins with strategic fixes - start with configuration changes to reduce immediate risk while planning larger architectural improvements

Communicating Prioritization Decisions

When I present prioritized findings, I include a visual attack path diagram showing how individual vulnerabilities connect to form exploit chains leading to critical assets. Teams are much more motivated to address vulnerabilities when they can see exactly how an attacker would use them, rather than simply being told a severity number.

Accepting Risk Deliberately

Not every vulnerability needs to be fixed. Some findings may be accepted as residual risk because the cost of remediation exceeds the potential impact, or because compensating controls sufficiently reduce the risk. The key is making this decision deliberately and documenting it. I help clients create formal risk acceptance records, ensuring the decision is made by someone with appropriate authority and reviewed periodically.