CVSS scores severity. EPSS predicts exploitation. Neither proves reachability.

The Common Vulnerability Scoring System (CVSS) is maintained by FIRST and produces a 0–10 score describing how severe a vulnerability would be if an attacker exploited it. The base score is built from intrinsic characteristics — attack vector, complexity, privileges required, user interaction and the impact on confidentiality, integrity and availability. Scores are banded as low, medium, high and critical, and most tools surface the critical and high bands by default.

Two properties of the CVSS base score are routinely forgotten. It is a measure of severity, not of likelihood: a 9.8 describes the damage available to an attacker who succeeds, not the chance that anyone will try. It is also deliberately environment-agnostic, because the score is published once for every organisation that will ever consume it. FIRST is explicit that the base score alone is not a prioritisation mechanism.

The practical consequence is a queue sorted by a number that does not know your estate. A critical CVSS score on an internal service behind mutual TLS with no route from the internet outranks a medium score on an unauthenticated public endpoint, even though the second is the one an attacker will reach first.

The Exploit Prediction Scoring System (EPSS), also a FIRST project, exists to answer the question CVSS does not: how likely is exploitation. EPSS outputs a probability between 0 and 1 that a given CVE will be exploited in the wild within the next 30 days, trained on observed exploitation telemetry rather than on the characteristics of the flaw. Each CVE also carries a percentile, which is how it ranks against every other scored CVE.

EPSS is a strong corrective to severity-only triage, because only a small fraction of published CVEs are ever exploited in the wild. Sorting by EPSS concentrates effort on the vulnerabilities attackers actually use, and teams commonly draw a working threshold around 10% and treat anything above it as urgent.

What EPSS cannot do is localise. It is a population-level forecast about a CVE, identical for every organisation that looks it up on a given day. It does not know your network topology, your compensating controls, whether the affected package is loaded on a reachable code path, or whether the host is exposed at all. A 90% EPSS score on a component that no route reaches is still not your most urgent fix.

The CISA Known Exploited Vulnerabilities (KEV) catalogue is the highest-confidence public signal of the three. A CVE is added only when there is reliable evidence of active exploitation, which converts EPSS's probability into an observed fact. US federal civilian agencies are bound by CISA directive to remediate KEV entries within published deadlines, and many private organisations have adopted the catalogue as a hard service-level target.

KEV's strength is also its boundary. It confirms that a vulnerability is being exploited somewhere in the world, against someone. It says nothing about whether the affected component exists in your estate, whether an attacker can reach it, or which of your systems would fall if they did. KEV tells you a weapon is in circulation, not whether your door is unlocked.

CVSS, EPSS and KEV are all lookups. They are properties of a CVE, resolved from a public dataset, and they are the same for you and for your competitor. Reachability is the opposite kind of signal: it is a property of your environment, and the only way to establish it is to test.

Panop's agents discover the estate, fingerprint what is actually running, then execute real attacker techniques safely against live infrastructure to confirm which exposures can be reached and exploited. A finding that survives that process carries the reproduction path as evidence. Panop then weights confirmed findings against operational context — asset criticality, data sensitivity, availability constraints and ownership — so the queue reflects both what is reachable and what it would cost.

Public scores remain useful inside this model. CVSS, EPSS and KEV help decide what deserves testing attention first and how to weight a confirmed finding. They are inputs to the decision, not the decision itself. The output is a ranked remediation queue with owners attached, and every fix is re-tested to confirm the path closed. See risk prioritisation for how that queue is produced, and autonomous penetration testing for how the validation runs.

Not every exposure has a CVE. A large share of genuinely exploitable findings are implementation flaws in your own applications and infrastructure, which no public scoring system covers because no advisory was ever published for them. Panop fingerprints each detected service and runs targeted tests for the classes that apply to it, rather than exhaustive generic scans.

• SQL injection (SQLi) — unsanitised input reaching a database query, validated by confirming that the injected condition changes the response rather than by pattern-matching the parameter.
• Cross-site scripting (XSS) — reflected, stored and DOM-based variants, confirmed by establishing that the payload executes in the rendered document.
• Remote code execution (RCE) — command injection, unsafe deserialisation and vulnerable-component paths that let an attacker run code on the host.
• Authentication and access control flaws — broken authorisation, exposed administrative interfaces and credentials that still work.
• Cloud and edge misconfiguration — permissive storage, over-broad identity policies, and CDN or WAF settings that can be bypassed.

These classes map onto the OWASP Top 10 categories that most compliance programmes reference. Because each confirmed finding is reproduced rather than inferred, an SQL injection or RCE that Panop reports has been demonstrated, not scored as probable.

PCI DSS 4.0 is the clearest example of a standard that asks for evidence rather than scores. Requirement 11.4 calls for internal and external penetration testing performed at least every twelve months and after any significant infrastructure or application change, using a defined methodology, with exploitable vulnerabilities corrected and the testing repeated to verify the correction. Requirement 11.3 separately covers vulnerability scanning, and requirement 6.2.4 addresses common software attacks including injection and scripting flaws.

The "after any significant change" clause is what an annual engagement cannot satisfy in a cloud estate, where containers, serverless functions and APIs change weekly. Continuous validation closes that gap: because testing re-runs when infrastructure changes, the evidence of the post-change test exists without commissioning another engagement. The same validation records support ISO/IEC 27001, NIS2 and DORA reporting, which is covered on the Security & Compliance page.