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.
What developer-security friction means in practice
Developer-security friction is not just “security slows things down.” It is the gap between how developers actually build, test, and ship software and how a control expects them to interact with security, especially when the handoff is late or unclear.
That friction usually appears when security feedback arrives after code is already integrated, when remediation guidance is vague, or when the safest path requires a separate workflow that developers are unlikely to follow consistently. In that state, controls can become bypassed, deferred, or treated as blockers instead of guardrails.
Where friction comes from
The most common source is process mismatch. A security requirement may be sound in principle, but if it sits outside the delivery path, developers experience it as extra work rather than part of the build system. That is especially true when findings are handed off without enough context to fix them quickly.
Tooling can also create friction when it duplicates signals, produces too many low-confidence findings, or uses language that does not map to the way engineers think about code ownership. In that case, the issue is not only volume, but translation: a control that is technically correct may still be operationally awkward.
Friction also rises when security and engineering use different release cadences, different issue trackers, or different definitions of “done.” The result is a control path that competes with delivery rather than fitting into it.
Why this matters for security outcomes
When friction is high, teams tend to optimize for throughput and work around the control. That can mean ignored alerts, delayed fixes, weaker review quality, or security exceptions that accumulate faster than they are revisited.
The practical security issue is not merely inconvenience. A control that cannot be used reliably is often less effective than a simpler control that developers can apply early and repeatably. OWASP Cheat Sheet Series is useful here because it reflects implementation guidance that is meant to be applied during development, not after release.
Friction can also hide risk. If developers start avoiding scanners, postponing fixes, or treating reviews as a separate security-only phase, the organization may gain process completion on paper while losing real control coverage in practice.
How to think about reducing it
Developer-security friction is usually reduced by moving from gated security to embedded security. That means giving feedback earlier, making remediation more specific, and aligning security checks with the natural flow of coding, testing, and deployment.
Security teams also need to distinguish between a control that is strict for a reason and a control that is merely inconvenient. A requirement that blocks delivery without improving assurance is a candidate for redesign, not just enforcement.
Good friction reduction preserves intent while improving usability. The goal is not to dilute security, but to make the secure path the easiest credible path for developers to take.
Risk and Threat Considerations
High friction creates a predictable control failure mode: people route around what slows them down. In software delivery, that can lead to shadow workflows, delayed remediation, or repeated exception handling that weakens the control over time.
Failure mechanism: Security feedback arrives too late, is too generic, or requires too much context switching, so developers delay fixes or bypass the control altogether.
Impact: Vulnerabilities persist longer, exception handling becomes normalised, and the organization loses both security assurance and visibility into real exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, OWASP SAMM and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V15 — Secure Coding and Architecture | Developer-security friction often arises when controls do not fit software design and delivery. |
| Recommendation — Embed security requirements into the development workflow so engineers can act on findings without leaving the build context. | ||
| OWASP SAMM | Software Assurance Maturity Model | SAMM addresses how security becomes a repeatable part of software delivery maturity. |
| Recommendation — Use SAMM to align security practices with delivery stages and reduce handoff-driven friction. | ||
| NIST SP 800-53 Rev 5 | SA-11 — Developer Testing and Evaluation | Developer-security friction is reduced when security feedback is integrated into development and test activities. |
| RA-5 — Vulnerability Monitoring and Scanning | Late or noisy findings are a core source of friction, making scanning quality and timing material. | |
| Recommendation — Build security checks into development and testing so issues surface early and are easier to remediate. Tune scanning so results are timely, actionable, and routed to the team that can fix them. | ||
| ISO/IEC 27001:2022 | A.8.29 — Security testing in development and acceptance | The term centers on fitting security testing into the software delivery process without unnecessary disruption. |
| Recommendation — Place security testing where developers can consume the results before release decisions are made. | ||
Practitioner Guidance
Why practitioners should care: This term is mainly about whether a control can be adopted at scale. If developers cannot act on a finding quickly and clearly, the control may be technically valid but operationally weak.
Common misunderstanding: Teams often assume more security checks automatically means better security. In practice, poorly timed or poorly explained controls can reduce adoption and create a false sense of coverage.
Practitioner takeaway: Treat friction as a design signal. If a security step repeatedly interrupts delivery, revisit when it runs, what it returns, and how directly it helps the person expected to fix the issue.
Related resources from NHI Mgmt Group
- Should organisations treat developer friction as a security risk signal?
- How should security teams choose a SAST tool without creating developer friction?
- Why do application security tools often create more friction than risk reduction in developer workflows?
- Why do traditional CI/CD security scanners often increase developer friction instead of reducing risk?