← all writing

Nine Out of Ten Alerts Are Wrong, and Everyone Knows It

The security industry's own 2026 numbers say most SAST output trains developers to ignore the tool. We published our own noise rate instead of hiding behind the word 'AI-powered.'

There's a number that keeps showing up across 2026 application security research, and it should worry anyone buying a code-scanning tool right now: traditional SAST tools produce false-positive rates between 40 and 91%, depending on the study and how "untuned" the deployment is. OX Security's 2026 benchmark, drawn from 216 million findings across 250 organizations, found that after applying exploitability analysis, only 0.092% of raw findings turned out to be critical. Nine out of ten alerts, on average, are wrong.

The industry has a name for what happens next: alert fatigue. Once developers learn that most security alerts are noise, they don't get more careful about which ones they check, they get less careful about all of them, including the real ones. Security researchers call it "poisoned well syndrome." It's not a training problem or a discipline problem. It's rational behavior in response to a tool that's wrong most of the time.

Wrong-match rate: industry range vs. TrueMend, disclosed
Industry SAST (untuned) 40-91%
TrueMend, Java (hardest) 18.6%
TrueMend, Python (easiest) 4.5%
Industry false-positive range from 2026 SAST research (Endor Labs, OX Security, Pixee) next to TrueMend's own disclosed wrong-match rates across its easiest and hardest languages.

Here's what we think the actual fix looks like, and it's less flattering than "our AI is smarter." It's disclosure. Every vendor in this space claims high accuracy. Almost none of them publish the number in a form you could independently check. We run blind two-axis adjudication on our own detectors, findings pooled with a named competitor's, shuffled, and judged on two separate questions: is the issue real, and is it actually worth fixing. The target bar is under 10% wrong-match. We hit that on Python, Rust, TypeScript and PowerShell. We don't hit it yet on Java, Bash, or Go, and we say so, with the actual number, not a rounded-up "high accuracy" claim.

Whether the false positive rate in your environment is 60% or 91%, the structural problem is the same: SAST flags patterns, not exploits. "Could" and "is" are separated by an ocean of context that static analysis can't see on its own.

That gap, between what a pattern matcher can see and what's actually exploitable, is exactly where most of the industry's noise comes from. Here's a real example from our own benchmark work, a detector that used to fire on the literal word "password" instead of an actual hardcoded secret:

// what the detector used to flag as a critical hardcoded credential
self.password = password;         // a variable assignment, not a secret
function login({ password }) {}   // a destructured kwarg, not a secret

// the fix: require an actual quoted literal, not just the word
const HARDCODED_SECRET = /["']([a-zA-Z0-9+/=]{16,})["']/;

That's one of fifteen detector defects our own benchmark surfaced and fixed before we published a number, across two languages, all with regression tests and commit references. The point isn't that the bug existed, every scanner has false positives. The point is whether you fix it and show the receipt, or round the number up and hope nobody checks.

Why the number matters more than the pattern count

A tool with 5,000 patterns and a 90% false-positive rate finds you roughly 500 real things and 4,500 reasons to stop trusting it. A tool with fewer patterns and a 5% false-positive rate finds you fewer things, but every one of them is worth your time, which is the only unit that actually matters once a team is already drowning in review load. Pattern count is a vanity metric. Wrong-match rate, measured against a real corpus and published even when it's embarrassing, is the number that decides whether your team still reads the alerts in six months.


Where TrueMend fits

Detection quality that isn't published in a checkable form isn't detection quality, it's a claim. TrueMend's wrong-match rate is measured by blind adjudication against real repositories and a named competitor, republished every time the methodology changes, wins and losses both.

  • For security teams evaluating a new scanner: ask for the wrong-match rate, the corpus it was measured on, and whether the vendor's own losses are in the document. If the answer is a rounded-up "high precision," that's the tell.
  • For teams already fighting alert fatigue: the fix isn't a bigger pattern library, it's a lower noise floor. Ours is published per language, not averaged into one flattering headline number.
← all writingnext: how the engine works →