Topic starter
02/08/2026 12:20 pm
TL;DR: One enterprise spent more than 200 developer hours in a quarter on false positives, according to Veracode research, while academic research shows two-thirds of SAST papers cite high false-positive rates as a major barrier to use. The practical shift is toward continuous, context-aware analysis that preserves developer trust instead of trading speed for blind spots.
Editorial analysis by NHI Mgmt Group, based on content published by Veracode: “Beyond “Fast”: Why Deep, Continuous Risk Analysis is the Only Way Forward”.
By the numbers:
- One enterprise lost more than 200 developer hours in a single quarter to false positives.
- Veracode says its false positive rate averages less than 1% compared with an industry norm of 5-30%.
Key questions
Q: How should AppSec teams reduce false positives without losing vulnerability coverage?
A: Use contextual analysis that weighs reachability, data flow, and compensating controls before escalating findings.
Q: When do noisy application security findings become a governance risk?
A: They become a governance risk when developers stop trusting the scanner and begin disabling it, suppressing alerts, or bypassing pipeline controls.
Q: What do security teams get wrong about scanning code faster?
A: They often assume more scanning will close the gap created by faster development.
Practitioner guidance
- Audit false-positive burden by application and pipeline stage Measure how many findings are dismissed, reclassified, or ignored in each repository and identify where scanner noise is causing developer work to stall or controls to be bypassed.
- Prioritise reachability and taint-aware analysis Require analysis that proves whether untrusted data can actually influence sensitive operations, especially in large frameworks and monolithic codebases.
- Move from hard gates to fail-forward policies Keep continuous scanning active on every change, but reserve pipeline failure for the most severe findings so security visibility does not depend on blocking delivery.
Bottom line: Fast application security scanning creates governance risk when false positives drive developers to ignore or disable controls.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:21 pm
False-positive governance is now an AppSec control problem, not just a tooling problem. When developers lose trust in scanner output, they do not simply complain about noise, they work around the control. That turns scanning from a security safeguard into a productivity tax, and eventually into an ignored signal. For AppSec programmes, the real governance question is whether findings are actionable enough to influence behaviour.
A question worth separating out:
Q: What is the difference between shift left and fail forward in AppSec?
A: Shift left means moving testing earlier in the delivery cycle. Fail forward keeps continuous security feedback flowing without blocking most deployments, then reserves hard failure for the highest-risk cases. That distinction matters because early but noisy controls still waste developer time if they cannot produce reliable findings.
👉 Read our full editorial: Deep continuous risk analysis is replacing fast but noisy scanning