The Vexta Confidence Score: A Vulnerability Prioritization Score That Uses Six Signals

What is a vulnerability prioritization score, and why do severity ratings alone fall short of one? A vulnerability prioritization score takes more than a raw severity label into account, folding in how confident the detector is, whether the bug has been proven exploitable, whether it is even reachable, and how likely it is to be attacked in the wild, then compresses all of that into one ranked number. Vexta, VITI Security's agentless, AI-augmented vulnerability scanner and pentest platform, calls its version the Vexta Confidence Score: a 0-100 number per finding built from six separate signals, so the findings list sorts itself by what should actually wake someone up rather than by severity label alone.

What six signals feed the score?

The score multiplies six weighted factors together. Severity sets the base: critical, high, medium, low, and info each carry a fixed weight, with critical weighted heaviest. Detector confidence applies its own multiplier, since a high-confidence detector match and a low-confidence heuristic match should not count the same even at identical severity. Proof status is the Proof-of-Exploitation verdict: a proven finding gets a strong upward multiplier, an unproven finding stays neutral, and a refuted finding gets pushed down hard, close to zero weight. A reachability factor, drawn from Vexta's attack-path and ASPM reasoning, boosts findings on a path an attacker could realistically walk and discounts ones that sit in dead code or unreachable configuration.

The last two factors pull from outside the scan itself. EPSS, the Exploit Prediction Scoring System (a probability, published by FIRST.org, that a given vulnerability will be exploited in the next 30 days), adds weight in proportion to that probability. CISA KEV, the Known Exploited Vulnerabilities catalog that the US Cybersecurity and Infrastructure Security Agency maintains, applies an extra multiplier when the CVE behind a finding is already confirmed as actively exploited. All six factors multiply together and the result is clamped to a 0-100 range, so severity alone can never dominate the outcome the way it would in a simple high/medium/low sort.

How does the score turn into a priority band?

The findings list sorts by this score in descending order by default, and each score lands in one of four bands shown with a color: 80 and above is Act Now in red, 60 to 79 is Sprint in orange, 40 to 59 is Backlog in yellow, and under 40 is Noise in grey. The intent behind the bands is blunt: on most scopes, only a small slice of findings genuinely deserves same-week attention, and the score is built to surface exactly that slice at the top of the list instead of making a hunter scroll past a hundred medium-severity, low-confidence, unreachable findings to find the three that matter.

Because proof status is one of the multipliers, a critical-severity finding that Proof-of-Exploitation refutes will not sit at the top of the list just because of its severity label. And because reachability and EPSS both factor in, a merely medium-severity bug on a path an attacker can actually reach, with a CVE that CISA has already listed as exploited in the wild, can outrank a higher-severity finding that is unreachable and has no exploitation history behind it.

Why weight proof status this heavily?

A finding that Proof-of-Exploitation has proven gets a substantial upward multiplier, because a hunter has already been handed working evidence, not a hypothesis. A refuted finding gets slashed to a fraction of its base weight, since a safe proof-of-concept already ran cleanly and found nothing there, and letting it sit high in the list would waste a triager's time. An unproven finding stays at a neutral multiplier, neither boosted nor buried, which matters just as much: unproven is not the same as safe, and the score is deliberately built so that an unverified critical finding does not quietly vanish down the list the way a refuted one is meant to.

What does this look like on two real findings?

Take two findings from the same scan. The first is a critical-severity SQL injection that Proof-of-Exploitation refuted after a clean safe proof-of-concept found nothing there, sitting on a path the ASPM reachability check marks as backlog-only exposure. The second is a medium-severity server-side request forgery that Proof-of-Exploitation proved, sits on a path reachable from an unauthenticated entry point, and matches a CVE already listed in the CISA KEV catalog with a high EPSS probability attached. On a severity-only sort, the first finding would sit above the second. Under the Vexta Confidence Score, the refuted multiplier drags the first finding down near the Noise band while the proven, reachable, actively-exploited second finding lands in Act Now, which is the ordering that actually matches which one deserves attention this week.

That example is the whole argument for combining six signals instead of reading severity alone: severity describes how bad a bug would be in the worst case, and the other five factors describe how likely that worst case actually is on this target, right now.

Why bring EPSS and CISA KEV into a scanner's own score?

Severity and detector confidence describe the bug itself, but they say nothing about whether anyone is actually exploiting that bug class right now. EPSS answers the first version of that question with a probability estimate refreshed regularly by FIRST.org, and CISA KEV answers a harder version of it directly: this specific CVE is confirmed, not modeled, as actively exploited. Folding both into the same score means a finding tied to a CVE already on the KEV list gets pulled toward the top of a hunter's queue even if its raw severity or detector confidence alone would not have put it there, because active exploitation in the wild is exactly the kind of signal that should override a purely local assessment of how bad a bug looks on paper.

Key takeaways