Prove which vulnerabilities are real

A vulnerability scanner tells you a CVE might apply to a version string it saw. That is a hypothesis, and someone on your team has to spend an afternoon turning it into a yes or a no.

Eight words that are not synonyms

Most of the argument between a security team and an engineering team is really a disagreement about which of these a ticket has reached. They are usually all called "a vulnerability".

A CVSS score describes stage 3. EPSS estimates the chance that somebody, somewhere exploits that CVE. CISA KEV records that it has been exploited in the wild. All three are useful, and none of them answers the only question that decides whether you work tonight: is it exploitable on my system? That question has one honest answer, and it is a request and a response.

What we drop, and why that is the point

Umbra's AI agents generate candidate findings; a separate validator then tries to disprove each one against the live target before it can ship. Across production scans to date:

41% of our own AI's candidate findings do not survive validation. That is a small sample — 85 findings — and we will publish a larger figure when we have one rather than round this into a marketing number. But the shape of it is the product: the value is not the AI that finds things, it is the thing that refuses to let unproven findings reach you.

How the validator decides

These are the actual rules it operates under, not a description of them.

The burden of proof sits on the finding. Anything without a live HTTP differential is dropped. "Plausible" is not a verdict.

Re-firing a request and getting the same response proves the behaviour happens. It does not prove anyone gained anything. Before confirming, the validator has to state what an unauthorised party actually obtained — data they should not read, an action they should not perform, a boundary that genuinely enforces something. If the response is what anyone in that position always gets, there is no finding, however confidently it was written up.

Findings assert things like "X is a security control and I bypassed it". Defeating a control that was never enforcing anything is not a finding. The control has to be shown to enforce something first.

Proving the things that produce no response

Blind SSRF, blind XXE, JNDI injection and out-of-band command execution share a problem: a successful exploit looks identical to a failed one from the client side. Umbra runs its own out-of-band collector, mints a unique hostname per attempt, and confirms the vulnerability when the target's infrastructure calls back. The callback is the evidence, and it goes in the report.

Where it runs

Validation is not a separate product. It runs across every surface Umbra monitors:

Commercially it is one unit: a Check is one verification, whatever it took. Re-testing a finding we already reported is free and never counted, because charging you to confirm your own fix would be a strange way to encourage fixing.

Try it on something you own

The free tier monitors 25 assets with discovery and CVE matching. Paid plans add the validation described on this page. No card.

Part of{" "} continuous security validation {" "} — discover, prove, fix, re-test.