Developer security friction is the real barrier to secure code

At a glance

What this is: Semgrep says developer security friction, not lack of tools, is what most often blocks secure code, because noisy findings and late checks encourage workarounds.

Why it matters: IAM, NHI, and application security teams need controls that surface issues early and in context, or developers will route around them and weaken governance.

Context

Security friction is the point at which a control becomes so disruptive that users start working around it. In software development, that usually means noisy alerts, late scanning, or tools that interrupt the workflow after context has already been lost. The result is not just annoyance, but weaker security decisions at the point where code is created.

This matters to application security and identity governance because developers increasingly handle secrets, tokens, and access paths as part of everyday delivery. When security is bolted on after the fact, the control model loses influence over how credentials are created, handled, and remediated. That is a familiar governance failure pattern, even when the subject is code rather than identity operations.

Key questions

Q: How should security teams reduce developer resistance to secure coding checks without slowing delivery?

A: The best approach is to make security checks fast, early, and actionable. Run scanning in parallel so it finishes before the slowest test, surface issues in the editor rather than waiting for commit or CI, and provide autofix where possible. That combination reduces workflow friction and gives developers something they can use immediately instead of another blocking warning.

Q: Why do noisy security alerts cause teams to ignore static analysis findings?

A: Because repeated false positives turn the tool into background noise. Once developers learn that most alerts do not matter, they stop trusting the system and start filtering its output informally. That reduces the chance that real findings will be acted on quickly, even when the underlying control is technically present.

Q: What breaks when application security testing is moved too late in the delivery cycle?

A: Late testing turns vulnerabilities into backlog, which increases alert fatigue and encourages teams to work around controls. Developers lose context, fixes take longer, and security becomes a blocking event rather than a design input. In practice, delayed feedback raises the chance that issues survive into production unchanged.

Q: Should organisations automate fixes for AI-generated vulnerabilities?

A: Yes, for repeatable flaw classes where the fix is well understood and the risk of delay is high. Automated remediation should handle predictable issues such as input validation, secret handling, and object reference mistakes, while humans focus on architectural decisions and exceptions. That division is the only scalable way to keep pace with AI-assisted delivery.

Technical breakdown

Why late security feedback fails in developer workflows

Static analysis and similar controls work best when they surface issues at the moment a developer creates them. If the feedback arrives in a separate system, after the pull request has moved on, or long after the relevant code path was written, developers lose the context needed to fix the issue quickly. That turns security into a delayed gate instead of a design input. In practice, the further a finding sits from the IDE or code review, the more likely it is to be ignored, deprioritised, or worked around.

Practical implication: Run security checks where the code is being written and reviewed, not in a separate downstream queue.

How alert noise erodes trust in security tooling

False positives and redundant findings create a trust problem, not just a usability problem. Once developers learn that a tool produces too many low-value alerts, they stop treating its output as authoritative and begin filtering it mentally or procedurally. That is especially damaging when the same tool is expected to help prioritise real issues. Effective controls therefore need triage logic, suppression of trivial findings, and concise explanations that help the reader understand why the alert matters.

Practical implication: Tune detections aggressively so that developers see fewer, higher-confidence findings with clear remediation context.

Where AI helps and where it does not

AI can assist with triage, summarisation, and remediation guidance, but it does not remove the need for secure coding judgment. Used well, it can reduce review friction by grouping similar findings and explaining likely fixes. Used as the primary security verdict, it creates dependence on patterns that may be hard to reproduce, hard to trace, or wrong in subtle ways. The article’s point is not that AI is useless, but that it becomes counterproductive when it replaces structured security thinking instead of supporting it.

Practical implication: Use AI to reduce review burden and improve guidance, but keep human validation in the loop for security decisions.

NHI Mgmt Group analysis

Security friction is a governance failure, not just a UX problem. When controls are so disruptive that developers work around them, the organisation has already lost the ability to shape secure behaviour at the point of code creation. That failure is especially visible when security is treated as a post-build checkpoint instead of a delivery constraint. The practitioner conclusion is simple: if a control cannot survive daily workflow pressure, it will not govern risk for long.

Developer trust in security tooling is earned through signal quality. A tool that floods teams with false positives stops being a control and becomes background noise. That matters because security teams often measure output volume instead of decision quality, which encourages more alerts rather than better ones. The better model is precise feedback, clear remediation, and consistent suppression of low-value findings so developers can act quickly and reliably.

Developer friction debt: this is the cumulative security loss created when teams repeatedly delay, simplify, or bypass controls to keep delivery moving. The debt shows up in insecure code, weak review habits, and a culture where security is seen as someone else’s job. Once that pattern is established, adding more tooling rarely helps. The practitioner lesson is to reduce the cost of doing the right thing before the culture hardens around workarounds.

Security and development have to operate as one workflow. The article is right to stress immediate feedback, in-context guidance, and shared responsibility. That combination is also relevant to identity-adjacent security, especially where developers handle secrets, service credentials, and access paths as part of deployment. The conclusion for IAM and AppSec leads is to treat developer experience as part of control effectiveness, not a separate concern.

AI should improve prioritisation, not become the security source of truth. The strongest use case is filtering, explanation, and educational support inside the workflow. The failure mode is over-reliance, where teams assume AI will find and fix issues without reinforcing secure design habits. That shifts the organisation from proactive control to reactive scanning, which weakens both engineering discipline and security assurance.

From our research library:

• 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.
• Read next: Password Security and Password Manager Guide

What this signals

Developer friction debt: repeated workflow interruption creates a hidden governance debt that shows up later as ignored alerts, delayed fixes, and insecure defaults. Security teams should measure whether controls are changing developer behaviour, not just generating more findings.

The same pattern appears anywhere security is bolted onto a fast-moving workflow. When the control path is slower than the delivery path, people route around the control, so the programme must optimise for context, timing, and explainability rather than volume.

Security leaders should treat developer experience as a control variable. If a finding cannot be understood and fixed in the normal flow of work, it is unlikely to change the security outcome in a meaningful way.

For practitioners

• Embed scanning in developer workflows Run static analysis in pull requests, merge requests, and the IDE so findings appear while the developer still has full code context.
• Reduce alert noise before rollout Tune rules to suppress trivial or redundant findings and review false-positive patterns so the tool earns trust instead of eroding it.
• Pair findings with immediate remediation guidance Require concise explanations, likely attack scenarios, and fix instructions for each alert so developers can resolve issues without leaving the workflow.
• Train developers on secure coding basics Provide practical secure coding instruction early, then reinforce it with examples tied to the languages and frameworks the team actually uses.
• Reward issue closure, not just defect discovery Measure how quickly teams fix findings and whether security feedback improves code quality, rather than only counting the number of issues raised.

Key takeaways

• Security friction turns protective controls into bypass incentives when developers cannot resolve findings quickly in their normal workflow.
• The article points to a behavioural gap in secrets management, with only 44% of developers reported to follow best practices.
• The strongest control response is earlier, lower-noise, more actionable feedback that makes secure coding the easiest path.

Key terms

• Developer-security friction: The operational mismatch that occurs when security controls interrupt, confuse, or slow development work instead of fitting into it. It usually shows up when feedback is late, remediation is unclear, or the control path is separate from how code is built and shipped.
• Alert Fatigue: Alert fatigue is the condition where a security team receives so many low-value alerts that important events become harder to notice. In monitoring programs, it usually signals poor rule tuning, weak prioritisation, or a mismatch between detection logic and operational reality.
• Shift-left security: Shift-left security means moving security checks and remediation earlier in the software delivery lifecycle, especially into development and pull request workflows. The goal is to surface issues when they are cheapest to fix and closest to the code change that introduced them.
• Code Review: Code review is the human inspection of a proposed change before it is merged. Reviewers assess correctness, maintainability, and risk, including whether the fix makes sense in context. It is a control for judgment and quality, but it does not by itself prove remediation.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, secrets management, and the lifecycle controls that matter when developers handle credentials. It helps security, IAM, and engineering teams align delivery speed with identity discipline.