managing-vulnerabilities

Managing Vulnerabilities

A scanner returns ten thousand findings, most rated High or Critical, and the team can patch a few hundred a month. Vulnerability management is the function that decides which few hundred — and the default of "sort by CVSS descending" is close to the worst possible order, because CVSS measures theoretical severity, not the probability that this vulnerability, on this asset, gets exploited.

The whole discipline is turning an undifferentiated backlog into a defensible order of operations that a limited team can actually execute.

When to Use

• Triaging vulnerability scanner output into a remediation order
• Deciding what to patch first under a fixed remediation budget
• Building or reviewing a risk-based vulnerability management process
• Explaining why a CVSS 9.8 is not this week's top priority
• Deciding whether a finding warrants an exception rather than a fix

When NOT to Use

• Working a security alert queue (EDR/SIEM detections) — use triaging-security-alerts; that is detected activity, this is latent weakness
• Auditing source for new vulnerabilities — use auditing-code-for-vulnerabilities
• Cloud misconfiguration rather than software CVEs — use hardening-cloud-posture
• Exploiting a vulnerability to prove it — use the relevant offensive skill

CVSS Is Severity, Not Priority

CVSS base score answers "how bad is this if exploited, in the abstract?" It does not answer "will it be exploited here?" — which is the question remediation order actually turns on. The evidence is stark: the large majority of CVEs are never exploited in the wild, yet most are scored High or Critical. Sorting by CVSS spends the team's finite capacity on vulnerabilities that will never be attacked while genuinely exploited ones wait behind them.

Use CVSS 4.0 as one input — the severity term — and combine it with signals that speak to probability and impact-here.

The Three Signals to Combine

1. Is it being exploited? — EPSS and KEV