Vulnerable vs. Exploitable: Why We Verify Findings Instead of Just Flagging Them
Most application security tooling has the same problem: it's very good at telling you something might be wrong, and much worse at telling you whether it actually is. A SAST scan flags a thousand lines that match a dangerous pattern. A dependency scanner flags every package with a known CVE, whether or not your code ever calls the vulnerable function. The result is a list, not an answer — and someone still has to work out which of those thousand things is real.
We think that's the wrong place to stop, so we don't stop there.
What "verified" actually means
Alongside the usual static analysis — SAST across your source code, SCA across your dependencies, posture scanning across your AWS account — anything that looks exploitable goes through a verification pass before it's ever written up as a finding. Not a second opinion from another scanner. A safe, controlled attempt against a target you've authorised, to confirm the issue is real rather than theoretical.
A finding that survives that pass isn't a maybe. It's a proven way in, with the evidence to show for it — and everything that doesn't survive it never makes it into your report as noise.
Why a human still reviews it
Verification is what narrows a long list of maybes down to a short list of provens — but that short list still gets reviewed by a certified pentester before it reaches you. Automation is what makes that review possible at any reasonable speed; it isn't a replacement for someone who understands your specific environment deciding what actually matters.
That combination — automated scanning, real verification, and a human who signs off before you see it — is now part of our Enterprise tier. If you're evaluating tools that promise an "AI pentest" with nobody checking the output, it's worth asking what happens between the scan finishing and the report landing in your inbox. For us, that's where the actual security work happens.