False positives in AppSec: what teams need to fix first

TL;DR: AppSec programmes have trained developers to distrust findings, according to Nullify, citing a client review where more than 2,000 alerts had less than 10% triaged and only ~15% of highs and criticals opened, a pattern echoed by older and newer survey data. The result is not just noise but a governance failure: once findings are assumed unreliable, security debt accumulates faster than teams can justify fixing it.

Editorial analysis by NHI Mgmt Group, based on content published by Nullify: “Death by False Positives: How AppSec & ProdSec Lost The Developers”.

By the numbers:

• Over 2,000 open alerts were reviewed at one financial-services client, but less than 10% had been triaged.
• The same client had only ~15% of its highs and criticals opened by a human.
• Nullify says one limited deployment to ten repositories found 547 false positives against 105 true positives.

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: What happens when developers stop trusting AppSec findings?

A: They begin to triage by habit instead of by severity, which means real vulnerabilities can sit unreviewed while noise keeps arriving.

Q: What are the signs that a vulnerability program is creating too much noise to be effective?

A: A vulnerability program is probably generating too much noise when teams are flooded with red findings, developers ignore tickets, and important issues keep getting buried in the backlog.

Practitioner guidance

• Tighten triage precision before expanding scanner coverage Measure false-positive rates by tool, rule set, and repository so you can remove the worst sources of noise before asking engineers to absorb more findings.
• Track developer trust as an operational security metric Use triage acceptance, reopen rates, and ignored-high-severity counts to show whether findings are still being treated as credible inputs to remediation.
• Route only validated findings into engineering backlogs Separate validation from assignment so developers receive issues that have already been confirmed as real and paired with enough context to fix quickly.

Bottom line: Excessive false positives are not just a tooling nuisance, they weaken the credibility of the entire AppSec workflow.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →