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.
Editorial analysis by NHI Mgmt Group, 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 classified as false positives.
Key questions
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 noisy security findings quickly lose developer credibility?
A: Repeated false positives teach engineers that the channel is expensive and unreliable.
Q: How do security teams know if alert fatigue is improving?
A: They should look for shorter queues only if investigation quality stays high.
Practitioner guidance
- Define a developer security intake standard Require exploitability, reachability, service context, and remediation scope before a finding is sent to engineering.
- Convert alerts into merge-ready fixes Where possible, open a tested pull request instead of a ticket, so developers review a change rather than recreate the fix from scratch.
- Prioritise findings by engineering capacity Allocate a fixed share of sprint capacity or story points to security work, then match routing and backlog placement to available owner bandwidth.
Bottom line: Developer alert fatigue is a governance failure because security requests are often delivered as unfinished work that engineers must validate before they can fix it.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
30/09/2026 5:00 pm
Developer alert fatigue is a workflow-governance failure, not a motivation failure. The article is right to reject the culture diagnosis because the underlying issue is that security requests are delivered as ambiguous work items. When an alert forces engineers to act as both validator and remediator, the process is structurally expensive and predictably deprioritised. The practitioner conclusion is that engineering attention must be budgeted and scoped before alerts are sent.
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: Should teams send raw findings or prebuilt fixes to engineering?
A: Prebuilt fixes are usually better when the issue is straightforward, because they preserve developer time and convert a question into a review. Raw findings still make sense for architectural decisions or fixes that need deep design judgement, but they should be the exception.
👉 Read our full editorial: Developer security alert fatigue is a governance problem, not a culture one