Why Developers Ignore Security Alerts (And How to Fix It)

Developers ignore security alerts because most alerts ask them to finish work the security team started. For security leaders trying to win back engineering attention, the fix is to make every request cheaper to say yes to.

Whenever I speak with security teams, one of the questions I hear most often is some version of this: how do we get developers to actually act on what we send them?

After more than three years of building security agents at Nullify, we think the usual diagnosis, a culture problem, is wrong.

Developers are not ignoring security alerts. They are pricing them, and most alerts are priced to be ignored.

You cannot mandate attention. You can change the price.

The short answer: developers ignore security alerts because each one hands them unfinished work. They must confirm it is real, reachable and relevant, then design, test and own the fix. When most alerts turn out to be noise, tuning them out is rational. The fix is to lower that price.

Every security alert is a bill with the work left blank

Routing scanner findings to the people who wrote the code was a very rational design for a small security team. The problem is what the handoff contains.

A developer who receives a finding is not being asked one question. They are being asked five:

• Is this real?
• Is it reachable in the way our code actually runs?
• Does it matter for this particular service?
• What is the correct fix, and will it break anything?
• Is this mine to fix?

A scanner answers none of these. The developer has to, between feature work, with less security context than the team that sent the alert.

The odds are stacked against the alert

So developers estimate the cost, estimate the odds it is worth it, and decide. Our own production data shows why that usually goes against security. Across five production tenants, we looked at 14,847 SAST findings triaged over 90 days, and 57% were ultimately classified as false positives.

The point is not that scanners are bad. The point is that a developer who dutifully investigates every alert spends more than half of that effort proving that noise is noise.

And the odds compound. That is what security alert fatigue actually is. The first false positive costs an afternoon. The tenth costs the security team its credibility. Eventually the rational amount to spend on any alert is zero, including the one that was real.

Six ways to stop developers ignoring security alerts

1. Treat developer attention as a budget

Decide how much engineering capacity security gets this quarter, in the unit engineering already plans in: story points, hours or a share of each sprint. Security then prioritises before sending, and becomes a planned line item rather than an interruption.

2. Only send what you would defend in a code review

If a developer pushed back on the finding in a pull request, could you defend it? If the honest answer is "probably not, but the scanner flagged it", it is not ready to send.

This is where exploit validation and business context earn their keep. The same vulnerability might sit in a low-risk internal service or a customer-facing authentication flow. The developer should see the second one, with the evidence attached.

3. Send the change, not the question

An alert asks the developer to do the work. A pull request asks them to review work that has already been done. Developers review changes many times a day, with CI telling them whether anything broke. Writing a fix from scratch competes with the feature they were hired to ship.

4. Fix classes, not instances

Twelve findings with the same root cause should not arrive as twelve tickets. Fix the class once and send one change.

5. Route to an owner who has room

A correct fix still stalls if it goes to the wrong person, or to the right person in a release week. Commit history, CODEOWNERS and team structure often disagree, so check all three, then check capacity.

6. Measure what developers did, not what security sent

Findings sent measure security activity. Track the merge-ready rate instead: the share of fix pull requests a team merges with no further edits and no back-and-forth.

If that rate is low, the price is still too high.

Nullify takes the cost out of every request

All of this can be done by hand, but few security teams have the headcount to do it for every finding.

Nullify's agents triage every finding for exploitability, reachability and data flow before it reaches a developer. Where a fix is warranted, Nullify writes it and opens a pull request in GitHub, GitLab or Buildkite. It stays in draft until your CI passes and goes to the code owners. Nothing merges without human approval.

Campaigns handle the budget directly: tell Nullify which part of the backlog to remediate, by when, and how many developer story points to spend reviewing fixes. We also cap it at three open fix pull requests per repository and five new ones per run, because flooding a team with good fixes is still flooding them.

The alert becomes a change. The question becomes an answer.

The wrong takeaway is that developers should never have to think

The wrong takeaway would be that developers should never see a finding they have to think hard about. Architectural changes and fixes that alter behaviour customers depend on genuinely need a developer's judgement.

And developers do care about security. They have simply learned, one wasted afternoon at a time, that the alerts in front of them are rarely the best use of that care.

The better question is how to make yes the easy answer

The question is not "how do we get developers to pay attention to our alerts?"

It is how do we make every security request cheap enough that saying yes is the obvious choice?

Developers will keep pricing your alerts.

Make them cheap to say yes to.