Why CVSS Alone Is Failing Your Security Team

Every security team has lived this: a scanner returns 4,000 findings, hundreds of them "Critical," and the team is expected to work the list top-down by CVSS score. Three weeks later they're still in the 9.8s, and the thing that actually got exploited was a 7.5 nobody had reached yet.

CVSS measures severity, not risk

CVSS is a measure of intrinsic severity — how bad a vulnerability would be if exploited, under worst-case assumptions. It is deliberately context-free. It does not know whether the affected software is internet-facing, whether a working exploit exists, whether the version you run is even in the vulnerable range, or whether attackers are using it today. Those are exactly the things that decide what you should fix first.

Severity tells you how bad it could be. Risk tells you how likely it is to happen to you. You schedule work against risk, not severity.

The signals that actually predict exploitation

Real-world prioritisation comes from layering exploitation evidence on top of severity:

• CISA KEV — is the vulnerability confirmed exploited in the wild? If so, it jumps the queue regardless of CVSS.
• EPSS — the statistical probability a CVE will be exploited in the next 30 days.
• Public exploit availability (ExploitDB) — working exploit code is far more dangerous than a theoretical one.
• Exposure — is the affected service internet-facing, or buried behind three layers of network controls?
• Version applicability — does the CVE actually apply to the version you run, or just the product family?

How Argus reframes the list

Argus keeps CVSS as one input but weighs real-world exploitation on top. A high that's being actively exploited outranks a critical that isn't. The result isn't a longer list — it's a shorter, defensible one, where the top item is genuinely the next thing an attacker would use against you.

That's the difference between a scanner that sorts by severity and an intelligence platform that prioritises by risk.