Topic starter
30/09/2026 4:59 pm
TL;DR: Developers ignore security alerts because many findings arrive as unfinished work, and Nullify says 57% of 14,847 SAST findings triaged across five production tenants were false positives, making triage effort rationally expensive. The real control problem is not attention, but how security requests are priced, routed, and converted into merge-ready work.
NHIMG editorial: based on content published by Nullify: Why Developers Ignore Security Alerts (And How to Fix It)
By the numbers:
- Across five production tenants, 57% of 14,847 SAST findings triaged over 90 days were ultimately classified as false positives.
Questions worth separating out
Q: What breaks when security alerts are not validated before developers see them?
A: Developers lose time proving the alert is real, reachable, and worth fixing, which makes every new finding more expensive to trust.
Q: Why do unfiltered security findings create more risk instead of less?
A: Because they shift the analytical burden onto the people least able to absorb it.
Q: How can security teams tell whether developer alerting is actually working?
A: Look at whether findings become accepted fixes with minimal rework.
Practitioner guidance
- Validate findings before routing them Filter alerts for exploitability, reachability, and business context before they reach engineering queues.
- Treat developer attention as a finite budget Plan security remediation in the same units engineering already uses, such as sprint capacity, story points, or hours.
- Send fixable changes instead of open questions Where possible, convert a finding into a reviewed pull request with tests, code-owner review, and a clear merge decision.
What's in the full article
Nullify's full article covers the operational detail this post intentionally leaves for the source:
- How its agents triage findings for exploitability, reachability, and data flow before they reach developers
- How campaign controls cap the number of open fix pull requests and the number of new ones per run
- How the draft pull request workflow works across GitHub, GitLab, and Buildkite
- How story point budgeting is used to allocate remediation effort across a backlog
👉 Read Nullify's analysis of why developers ignore security alerts and what to change →
Security alerts for developers: why the governance model is failing?
Explore further
30/09/2026 5:00 pm
Developer alert fatigue is a governance failure, not a motivation failure. The article correctly rejects the lazy explanation that engineers simply do not care about security. What fails is the control design: findings are handed off before they are validated, prioritised, or made easy to review. In identity and access programmes, the same pattern appears when ownership is assumed instead of operationalised. The practitioner conclusion is to govern the handoff, not the people.
A few things that frame the scale:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
A question worth separating out:
Q: What should teams do when a security finding is important but disruptive?
A: Convert it into the smallest reviewable change that preserves engineering context and delivery flow. That usually means evidence, a proposed fix, tests, and code-owner review instead of a ticket that asks a developer to start from scratch. If the fix cannot be reviewed cleanly, the remediation path still needs work.
👉 Read our full editorial: Developer security alert fatigue is a governance problem, not a culture one
