Notifications
Clear all
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.
NHIMG editorial — based on content published by Veracode: Beyond “Fast”: Why Deep, Continuous Risk Analysis is the Only Way Forward
By the numbers:
- False positives from security scanners cost one enterprise over 200 developer hours in a single quarter.
- At a loaded cost of $150/hour, that’s $30,000 in wasted productivity.
- Veracode understands the actual control flow of 170+ frameworks across 11 languages.
Questions worth separating out
Q: How should security teams reduce false positives in AI vulnerability scanning?
A: Require scanners to prove reachability, exposure, and privilege context before findings are allowed to block delivery.
Q: Why do noisy security scanners create programme risk instead of just inconvenience?
A: Because every irrelevant alert consumes attention, delays delivery, and erodes trust in the control.
Q: What do teams get wrong about shifting security left?
A: They often treat shift-left as a detection exercise instead of a governance change.
Practitioner guidance
- Measure scanner precision before expanding coverage Track false positive rate, false negative rate, and time wasted on triage per repository.
- Adopt reachability-aware analysis for release-critical code Prioritise tools that can prove whether a vulnerable path is reachable and attacker-invokable, especially in large monolithic services and framework-heavy applications.
- Move blocking decisions to high-confidence findings only Use continuous background scanning for most findings and reserve merge gates for issues with strong exploitability signals, so pipeline controls do not become a universal bottleneck.
What's in the full article
Veracode's full post covers the operational detail this analysis intentionally leaves for the source:
- Its detailed explanation of reachability and taint tracing in SAST workflows, which is where implementation teams need to validate fit.
- Its examples of framework-aware detection across modern application stacks, useful if you need to benchmark your own tools.
- Its scan-time and productivity claims for continuous background analysis, which matter when you are making budget or process decisions.
- Its discussion of how the same approach extends into SCA, container security, and infrastructure as code.
👉 Read Veracode's analysis of deep continuous risk analysis in AppSec →
Fast scanning versus deep analysis: what changes for AppSec teams?
Explore further
02/08/2026 1:21 pm
Noise is a governance failure, not just a tuning problem. When scanners generate hundreds of irrelevant findings, they stop behaving like security controls and start behaving like productivity debt. That matters because developers eventually work around the control, which leaves real vulnerabilities unreviewed. For AppSec teams, the operational question is not whether scanning exists, but whether findings are accurate enough to preserve trust and coverage.
A question worth separating out:
Q: How do teams decide when to block a pipeline versus continue in fail-forward mode?
A: Block only when the finding has high confidence, clear exploitability, and meaningful business impact. Use background scanning for lower-confidence issues and treat the pipeline as a delivery system, not the only enforcement point. That balance preserves speed while still preventing dangerous code from moving unchecked.
👉 Read our full editorial: Deep continuous risk analysis is replacing fast but noisy scanning
