Topic starter
18/08/2026 2:18 pm
TL;DR: Developer-security friction usually comes from late enforcement and poor workflow fit, according to Pynt. CI/CD controls lose value when they are slow, unclear, or detached from the delivery path developers use.
Editorial analysis by NHI Mgmt Group, based on content published by Pynt: “Why Developers and Security Tools Just Don't Click”.
Key questions
Q: Why do slow security tools increase delivery risk instead of reducing it?
A: Because delay changes behaviour.
Q: Why does adding security late in the SDLC increase risk for software teams?
A: Adding security late increases risk because design flaws, insecure dependencies, and secrets exposure are already embedded by the time testing begins.
Q: How should security teams reduce developer friction in CI/CD pipelines?
A: Start by placing security checks where developers already work, such as commit, merge, and build stages, and make findings short, specific, and fix-oriented.
Practitioner guidance
- Embed security checks earlier in the delivery pipeline Run policy and vulnerability checks at commit or merge time so developers get actionable feedback before the change moves deeper into the build process.
- Reduce alert ambiguity for developers Rewrite findings into short, fix-oriented messages that name the issue, the affected component, and the next step without requiring security expertise.
- Align secrets governance with CI/CD workflows Treat service credentials, tokens, and pipeline secrets as part of the build process, with ownership and review built into the same workflow.
Bottom line: Developer-security friction is usually created by late enforcement and poor workflow fit, not by developer resistance alone.
Glossary terms: Developer-security friction, Continuous Integration And Continuous Delivery, Secrets Management, Secure development life cycle
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 3 days ago by NHI Mgmt Group
18/08/2026 3:10 pm
Developer-security friction is a control design failure, not a developer attitude problem. The article points to late enforcement, slow tools, and poor usability as the real sources of resistance. That means organisations should stop treating adoption as a training issue alone and examine whether controls are aligned with delivery reality. In practice, security that cannot fit the software workflow will be bypassed, delayed, or delegated away.
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: When should organisations rework their developer-security operating model?
A: When controls repeatedly cause bypasses, delays, or unresolved findings, the problem is no longer just tooling. That is the point to rework ownership, feedback timing, and the handoff between development and security so the control model matches how software is actually shipped.
👉 Read our full editorial: Why developer-security friction still slows secure software delivery
This post was modified 3 days ago by NHI Mgmt Group