sekura

Most High Severity Findings Are Never Exploitable

Severity-based scanners score vulnerabilities in isolation and miss reachability entirely. Most high-severity alerts point to code paths attackers cannot actually reach. Here is the data and what changes when you scan for proof instead.

Most vulnerability scanners are not wrong. They are just answering a different question than the one you need answered.

A scanner's job, as traditionally defined, is to flag every location in your codebase where a known-vulnerable pattern or dependency exists. That task is tractable. Determining whether that pattern is actually reachable, callable, and exploitable in your specific running application is much harder. Most scanners do not attempt it.

Why Your Alert Queue Fills With Noise

The typical production codebase generates between 300 and 1,000 CVSS "high" or "critical" findings per release cycle. Research by Kula et al. showed that over 80% of vulnerable library functions in real Java projects are never called by the application that depends on them. Veracode's State of Software Security data shows median time-to-remediation for critical findings is measured in months, because teams cannot separate real issues from theoretical ones.

This is not laziness. It is a structural problem. Your scanner cannot tell you whether the vulnerable deserialize() method in commons-text-1.9.0 is reachable through any call chain in your application. It tells you the library is present and the version is flagged.

CVSS does not resolve this. CVSS scores severity of the vulnerability in isolation from your code. A CVSS 9.8 in a dependency you never invoke is, practically speaking, not a vulnerability in your application.

The False Positive Rate You Are Paying For

False positive rate, in this context, is the fraction of scanner alerts that represent findings a real attacker could not exploit in your deployed application. This number is not published by most scanner vendors.

Internal measurements on production codebases put it between 60% and 85%. Other published research lands in the same range. That means for every 10 "critical" alerts, six to eight go nowhere.

The triage cost is real. A security engineer spending 30 minutes per finding, processing 500 findings per month, spends 250 hours. At a fully loaded cost of $150 per hour, that is $37,500 per month spent on labor that reduces no actual risk.

I think that is the real price of severity-based scanning. Not the license fee. The engineering time.

How Reachability Analysis Changes the Problem

Reachability analysis starts with a different question: can an attacker reach this code path through any input surface in the deployed application?

Answering it requires more than pattern matching. The steps are:

  1. Build the actual call graph of the application, not just the dependency tree.
  2. Identify which function entry points are reachable from external input surfaces: HTTP handlers, message queues, file parsers, RPC endpoints.
  3. Trace whether the vulnerable code path can be triggered by attacker-controlled input given actual data flow.
  4. Attempt to synthesize a working exploit, not a theoretical payload schema.
  5. Report only findings where that synthesis succeeds.

The difference between "this function exists in a library you use" and "we constructed an HTTP request that reaches this function and triggers the vulnerability" is the difference between probability and proof.

flowchart TD A[Dependency CVE found by SAST] --> B{Vulnerable function imported?} B -- No --> C[Discard: not reachable] B -- Yes --> D{Called from external entry point?} D -- No --> C D -- Yes --> E{Attacker input can reach call?} E -- No --> C E -- Yes --> F[Exploit synthesis phase] F -- Synthesis fails --> G[Discard: hypothesis only] F -- Synthesis succeeds --> H[Report with working proof-of-exploit]

Most findings exit through node C. That is by design, not by oversight.

What a Collapsed Triage Queue Looks Like

Proof-first scanning changes the output, not just the volume. Instead of 500 findings with mixed CVSS scores, you receive a small set of confirmed findings, each with an attached working exploit payload.

I believe that changes how teams operate at a fundamental level. You stop triaging and start fixing things that are definitively broken.

Sekura runs seven phases: white-box SAST, recon, dynamic probing, exploit synthesis, exploit-chain analysis, post-quantum cryptography review, and reporting. A finding reaches the report only if the exploit synthesis phase produces a working proof. If synthesis fails, the hypothesis is discarded.

Your engineers receive a PR comment with a concrete payload, not a ticket with a score. They patch, push, and the scan reruns. The feedback loop is tight.

Scanning has existed for 25 years. The field has spent most of that time optimizing for recall: surface everything that might be a problem. The next phase is about precision: report only what is actually a problem. The scanner that sends you 500 tickets is not more thorough than one that sends you 12. It is less honest about what it actually knows.

If you want to run a proof-first scan against your own codebase, start at /poc/.