You ran a vulnerability scan last Tuesday. It came back with 10,247 findings. Of those, 1,843 are rated “Critical.” Your patch window is next Sunday. Your team has three people. Quick math says you’re not patching 1,843 things by Sunday. So you do what every team does — you sort by CVSS score, start at the top, and hope you’re fixing the right ones. You’re probably not. That CVSS 10.0 vulnerability on the air-gapped test server nobody touches? It scored higher than the CVSS 7.8 on your internet-facing payment gateway that has a working exploit in Metasploit. CVSS doesn’t know the difference. You should.

The TLDR

Vulnerability management is the continuous cycle of finding, prioritizing, remediating, and verifying security weaknesses in your systems. The scanning part is easy — any tool can find thousands of vulnerabilities. The hard part is deciding which ones actually matter to your environment, right now. CVSS scores were never designed to be your sole prioritization mechanism, but the industry treats them that way. Risk-based vulnerability management considers exploit availability, asset criticality, network exposure, and threat intelligence to cut through the noise and focus on what an attacker would actually use against you.

The Reality

The vulnerability landscape is staggering. NIST’s National Vulnerability Database (NVD) cataloged over 28,000 new CVEs in 2023 alone, and the number keeps climbing. That’s 77 new vulnerabilities per day, every day, forever. No organization on earth can patch everything immediately. You must prioritize. The question is whether you prioritize intelligently or just chase numbers.

Here’s the uncomfortable truth about CVSS — the Common Vulnerability Scoring System maintained by FIRST. It’s a technical severity score. It tells you how bad a vulnerability could be in a theoretical worst case. It does not tell you whether anyone is actually exploiting it. It does not know that the affected system sits behind three layers of network segmentation and requires physical console access. It does not care that the vulnerability requires conditions so specific that exploiting it in the wild is essentially impossible.

The Exploit Prediction Scoring System (EPSS), maintained by FIRST and Carnegie Mellon, estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. Research from Cyentia Institute and Kenna Security showed that only about 2-5% of published CVEs are ever exploited in the wild. Two to five percent. That means 95%+ of the vulnerabilities you’re scrambling to patch will never be used against anyone, anywhere. But the ones that are exploited? Those are the ones that make the news. And CVSS alone can’t reliably tell you which group a vulnerability falls into.

How It Works

The Vulnerability Management Lifecycle

This isn’t “run a scan and file a ticket.” It’s a continuous operational cycle with five phases, and skipping any of them means the whole program drifts into theater.

Asset Discovery. You can’t secure what you don’t know about. Before you scan for vulnerabilities, you need an accurate, current inventory of every system, application, and service in your environment. Shadow IT — the servers, cloud instances, and SaaS apps nobody told security about — is where the worst vulnerabilities hide. CISA’s Binding Operational Directive 23-01 made asset discovery a federal mandate for exactly this reason.

Vulnerability Scanning. Automated tools probe your systems for known weaknesses. Two flavors: authenticated (the scanner logs in and inspects from inside, seeing everything) and unauthenticated (scanning from outside, seeing what an attacker would see). You need both. Unauthenticated scans miss a lot — they can’t see missing patches on a system they can’t log into. Authenticated scans see more but require credential management that introduces its own risks.

Prioritization. This is where programs succeed or fail. Raw scan output is a firehose. You need a framework to decide what gets fixed first.

Remediation. Patching, configuration changes, compensating controls, or acceptance of residual risk. Not every vulnerability gets a patch. Sometimes the vendor hasn’t released one. Sometimes patching would break a critical business application. Compensating controls — network segmentation, WAF rules, enhanced monitoring — buy time while you figure out a permanent fix.

Verification. Rescan to confirm the fix actually worked. You’d be amazed how often a “patched” system still shows the same vulnerability because the patch failed to install, required a reboot nobody performed, or was rolled back by an automated configuration management tool.

Scanning Tools and Approaches

Network vulnerability scanners like Nessus, Qualys, and Rapid7 are the workhorses. They maintain databases of known vulnerabilities and check your systems against them. They’re good at what they do, but they have blind spots.

Web application scanners — DAST tools like OWASP ZAP and Burp Suite — focus on application-layer vulnerabilities: SQL injection, XSS, authentication flaws. Network scanners don’t find these. If you have web applications (and you do), you need both.

Software Composition Analysis (SCA) scans your codebase for vulnerable third-party libraries and dependencies. That Log4j vulnerability (CVE-2021-44228) lived in a logging library buried three layers deep in the dependency tree. SCA tools find those.

Container and IaC scanning checks container images and infrastructure-as-code templates for vulnerabilities and misconfigurations before deployment. Shift left — find it before it’s running in production.

The CVSS Problem (and What to Use Instead)

CVSS v3.1 scores vulnerabilities on a 0.0 to 10.0 scale across three metric groups: Base (the intrinsic technical characteristics), Temporal (how the threat evolves over time), and Environmental (your specific context). In practice, almost nobody uses the Temporal or Environmental scores. Everyone sorts by Base score and calls it prioritization. That’s the lie.

A CVSS Base score of 9.8 means the vulnerability is technically severe — remote code execution, no authentication required, full compromise. What it doesn’t tell you:

EPSS fills part of this gap. It uses machine learning trained on real-world exploitation data to predict the likelihood of exploitation. A vulnerability with a CVSS 9.8 but an EPSS score of 0.01 is technically severe but unlikely to be exploited. A vulnerability with CVSS 7.5 and EPSS 0.95 should be on fire in your ticketing system right now.

CISA’s Known Exploited Vulnerabilities (KEV) Catalog (https://www.cisa.gov/known-exploited-vulnerabilities-catalog) is the authoritative list of vulnerabilities that are confirmed to be exploited in the wild. If a CVE is on the KEV list, it’s not theoretical — someone is actively using it. For federal agencies, KEV entries come with binding remediation deadlines. For everyone else, they should still be top priority.

Risk-based prioritization combines CVSS (technical severity) + EPSS (exploitation likelihood) + KEV status (confirmed exploitation) + asset criticality (business impact) + network exposure (reachability) into a composite risk score. That’s the number you should sort by.

Vulnerability Disclosure and Coordination

When security researchers find vulnerabilities, there’s a whole ecosystem for responsible disclosure. NIST’s NVD is the central repository. MITRE’s CVE program assigns the identifiers. Vendors publish advisories (Microsoft’s Patch Tuesday, Adobe’s security bulletins, etc.). Coordinated disclosure gives vendors time to develop patches before the vulnerability is made public.

But zero-days exist — vulnerabilities disclosed or exploited before a patch is available. When that happens, compensating controls are your only option. CISA’s alerts often include mitigation guidance for zero-days before vendor patches land.

How It Gets Exploited

Attackers don’t sort by CVSS score. They sort by exploitability.

Weaponized exploits hit fast. When a critical vulnerability gets a public proof-of-concept exploit, exploitation in the wild typically begins within days — sometimes hours. The ProxyLogon and Log4Shell incidents showed that mass exploitation can begin before most organizations have even finished assessing the vulnerability, let alone patching it.

Patch gaps are the target. Attackers reverse-engineer patches to understand the vulnerability they fix, then build exploits targeting unpatched systems. The window between patch release and your patch deployment is the danger zone. For internet-facing systems, that window needs to be measured in hours, not weeks.

Scanner blind spots are real. Misconfigurations, logic flaws, and business logic vulnerabilities don’t have CVE numbers. Your scanner won’t find them. The OWASP Top 10 is full of vulnerability classes that automated scanning handles poorly — broken access control, insecure design, security misconfiguration. These require manual assessment.

Vulnerability chaining. Individual vulnerabilities that score medium severity can combine into a critical attack path. A medium-severity information disclosure that reveals internal network topology, combined with a medium-severity SSRF, combined with a medium-severity privilege escalation, equals total compromise. CVSS scores each one in isolation. Attackers don’t think in isolation.

What You Can Do

Sources & Further Reading