Why do developers push back on security and what helps?

Developers push back on security mainly when it slows delivery, floods them with findings that are not real, or arrives after the work is done. The attitude is usually a rational response to friction and incentives. Remove the friction, show fixable findings early and give teams ownership, and cooperation improves.

Is it really an attitude problem?

Calling it attitude hides the cause. Developers are measured on shipping features and keeping services up. A control that adds waiting time, produces false alarms or blocks a release for a reason nobody can explain looks like an obstacle to those goals. People adapt: they skip the step, mark the finding as accepted, or learn which tool to ignore.

No survey is needed to see the pattern, because it appears in any team with a noisy scanner. The signal drops, trust drops, and real findings get lost with the rest.

What are the common sources of friction?

Late feedback. A flaw found after release costs a context switch and a hotfix. Found in the pull request, it costs a few minutes.

False positives. A tool that reports a vulnerable library even when the vulnerable code is never called teaches people to dismiss it.

Vague findings. "Insecure deserialization, high" with no file, line or fix gives the reader homework.

Tool sprawl. Five dashboards with different severity scales mean nobody knows what to do first.

Blame. If reporting a mistake leads to punishment, mistakes get hidden.

No time. Security work added without removing other work comes out of evenings or does not happen.

Constructed example: the ignored dashboard

A team receives 600 open findings from a dependency scanner. Most are in libraries used only in test code or in functions the service never calls. The team lead asks the security group which ten matter. Nobody can say. The backlog sits, and a genuinely exploitable flaw is lost among the rest for three months.

When the team gets findings filtered by reachability and sorted by whether the flaw is known to be exploited, the list shrinks to eleven. Developers fix nine in a week. The change was not persuasion. It was relevance.

What actually helps?

Fix the defaults first, because they cost developers nothing to adopt. NIST's Secure Software Development Framework describes practices such as using well secured components, automating checks and sharing the responsibility across roles. CISA's Secure by Design guidance argues that secure behavior should be the default product behavior, which applies to internal platforms too.

Then work on communication. Explain why a rule exists with a concrete example, offer a fix with the finding, and let teams set the pace of cleanup within agreed limits. OWASP's security culture material emphasizes trust, shared responsibility and practical help from security staff.

Tools can lower the cost of compliance. Safeguard's reachability analysis cuts findings to the ones that matter, and its IDE extensions bring checks to the editor so feedback arrives while the code is still open. Automated remediation through fix pull requests is off by default, so a team decides when to turn it on.

How to check or apply this

1. Ask developers what slows them down most in the security process, and fix the top answer first.
2. Measure false positive rate and fix or retire noisy checks.
3. Move checks left: editor, commit and pull request, not post release.
4. Attach a fix, a file and a line to every finding, not just a rule name.
5. Give each team ownership of its findings and a realistic time budget for fixing them.
6. Run blameless reviews and thank people who report their own mistakes.
7. Revisit the process each quarter with developers in the room.

Quick check

Sources

• OWASP Security Culture project
• NIST SP 800-218, Secure Software Development Framework
• CISA, Secure by Design

Last reviewed: 18 October 2026.