Why developer-security friction still slows secure software delivery

At a glance

What this is: This is an analysis of why developers struggle with security tools, with the key finding that friction comes from timing, usability, and workflow mismatch rather than security intent.

Why it matters: It matters to IAM practitioners because the same workflow failures that create developer resistance also undermine identity, access, and secrets controls when they are bolted onto delivery pipelines too late.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Pynt's analysis of why developers struggle with security tools

Context

Developer security friction is a governance problem as much as a tooling problem. When security controls arrive after code is written, teams experience them as disruption instead of protection, and that dynamic weakens adoption of access, secrets, and policy controls across delivery pipelines. For identity programmes, the same pattern shows up whenever governance is detached from build and runtime workflows.

Security tools also fail when they are built for inspection rather than execution. Developers need fast feedback, clear remediation paths, and controls that fit CI/CD behaviour, while security teams need consistency and accountability. That tension is typical in modern software organisations, not an edge case, and it becomes more visible as secrets, service accounts, and cloud permissions are managed at speed.

The operational lesson is straightforward: if identity and security controls do not fit the developer workflow, they will be bypassed, delayed, or ignored. That is why governance around secrets, OAuth connections, and privileged access must be designed as part of the delivery system rather than layered on top of it.

Key questions

Q: How should teams reduce local development friction without weakening security controls?

A: Use a preconfigured local baseline that includes secure defaults, repeatable tooling, and minimal manual setup. The point is to remove unnecessary environment assembly while keeping browser trust, database access, and credential handling inside an approved workflow. Convenience is not the objective on its own. Consistency is what improves both delivery speed and security oversight.

Q: Why do security tools fail to change developer behaviour?

A: They often fail when they interrupt work late, produce unclear findings, or demand too many manual steps. Developers respond to speed, clarity, and ownership. If a tool does not explain what is wrong and how to fix it quickly, the finding becomes background noise rather than a governance control.

Q: What breaks when secrets are stored in code and CI/CD tools?

A: Access becomes invisible, reusable, and hard to revoke, which means the organisation loses control of where authentication material exists. Once secrets are embedded in code or pipeline tools, discovery gets harder, offboarding slows down, and the same credential can survive multiple deployment cycles.

Q: How can organisations tell whether developer-friendly security is working?

A: Developer-friendly security is working when findings move into the tools engineers already use and are resolved faster without losing policy fidelity. Look for fewer handoffs, shorter remediation cycles, and better context at the point of fix. If alerts still sit outside the development flow, friction remains too high.

Technical breakdown

Why late-stage security gates create developer resistance

Late-stage security gates create friction because they interrupt a workflow that developers have already mentally finished. If scanning, policy checks, or approval steps appear only after code is ready, the control feels like a blocker rather than a design constraint. In practice, teams then optimise for speed around the tool instead of compliance with it. This is especially harmful where identity controls are involved, because secrets, tokens, and access paths are often embedded earlier than the security team sees them.

Practical implication: move controls left into the build path so identity and security checks happen before deployment pressure builds.

How clunky tooling weakens security outcomes

Clunky tooling fails when it cannot translate security findings into developer action. Vague errors, slow scans, and overloaded interfaces increase the chance that users will dismiss alerts, work around them, or defer fixes. The technical issue is not just usability, but control efficacy. If a tool cannot produce fast, understandable guidance, it cannot reliably change behaviour. For NHI and secrets management, that means vulnerable credentials and overbroad access can persist because the remediation path is too hard to use.

Practical implication: prioritise tools that produce clear, actionable findings with minimal workflow disruption.

Why automation matters for secrets and identity governance

Automation reduces friction by moving repetitive checks out of the developer decision loop. In CI/CD, automated policy enforcement can inspect secrets, permissions, and configuration drift continuously without requiring manual intervention for every change. That matters because identity controls fail when they depend on human memory or repeated review at high frequency. Automated checks are not a replacement for governance, but they are the only scalable way to keep pace with rapid release cycles and identity sprawl.

Practical implication: embed automated secrets and access checks into pipelines so governance scales with delivery volume.

NHI Mgmt Group analysis

Workflow friction is a control failure, not a culture problem. When security arrives after development decisions are already made, developers naturally treat it as overhead. That is the real governance failure: controls that are technically sound but operationally mis-timed do not shape behaviour. For identity and NHI programmes, this is where secrets leakage, shadow access, and policy bypass start to look normal. The practitioner conclusion is to align control timing with the delivery lifecycle, not with the incident response cycle.

Developer-friendly security is now an adoption requirement. Security teams cannot assume good controls will be used if they are hard to understand or slow to respond. In application security, the best control is often the one developers can execute without leaving their workflow. That applies directly to secrets handling, service account governance, and access policy enforcement. The practitioner conclusion is that usability is a governance attribute, not a cosmetic feature.

Identity control planes must extend into delivery systems. The strongest bridge between appsec and IAM is to treat secrets, tokens, and OAuth connections as governed identities with lifecycle rules. That means the security model cannot stop at authentication, because the main risk sits in provisioning, reuse, and offboarding of non-human access. The practitioner conclusion is to connect IAM, PAM, and pipeline controls into one operating model.

Tool sprawl weakens accountability unless ownership is explicit. Multiple disconnected scanners and reviewers create ambiguity about who acts, when they act, and what evidence proves remediation. That problem compounds when the same pipeline contains code, secrets, and runtime permissions. The practitioner conclusion is to define ownership and evidence requirements across security tooling, not inside each tool alone.

Developer experience is becoming part of security architecture. Security controls that reduce context switching and shorten remediation loops create better compliance than controls that are simply stricter. This does not mean lowering standards. It means designing for execution, so that identity and secrets governance can be enforced at the pace of software delivery. The practitioner conclusion is to measure control adoption, not just control existence.

What this signals

Developer experience is now an identity control issue. When security tooling creates friction, teams work around it, which is exactly how secrets, service accounts, and OAuth grants escape governance. For identity programmes, the signal is clear: controls must be measurable by adoption, not only by coverage. The strongest operating model is one where developer workflows and access governance are designed together, with policy checks embedded before runtime.

A useful concept here is workflow-integrated identity governance, which means treating pipeline checks, secret handling, and access policy as one system rather than separate disciplines. That approach matters because delayed review cannot keep pace with release velocity. Teams that want to reduce exposure need to connect delivery telemetry with identity telemetry and make remediation the path of least resistance.

The broader market direction is toward governance that can keep up with software throughput. In practice, that means tighter links between secrets management, CI/CD, and identity lifecycle controls, supported by standards such as the NIST Cybersecurity Framework 2.0. The next maturity step is not more tooling, but better-fit controls that developers actually use.

For practitioners

• Build security checks into pull requests and pipelines Place secrets scanning, policy evaluation, and access checks before merge or deploy so developers see issues while the change is still easy to fix.
• Translate findings into developer-ready fixes Replace vague scan output with remediation guidance that names the affected secret, token, permission, or configuration path and shows the exact corrective action.
• Reduce the number of security touchpoints Consolidate overlapping tools and approval paths where possible so teams do not need to interpret multiple alerts for the same code change or identity event.
• Treat secrets as governed identities Apply lifecycle controls to service accounts, API keys, and tokens so ownership, rotation, and revocation are visible in the same process used for human access.

Key takeaways

• Developer frustration with security tools usually reflects workflow misalignment, not resistance to security itself.
• Secrets and identity controls lose effectiveness when they are added after code decisions are already made.
• The practical fix is to move security into the developer workflow, shorten feedback loops, and make remediation clear.

Key terms

• Workflow-integrated identity governance: A governance model that places identity, access, and secrets controls inside the delivery workflow rather than after it. It reduces friction by making policy checks, remediation, and evidence collection part of the normal engineering process, which improves adoption and lowers the chance of workarounds.
• Developer Experience Security: Developer experience security is the idea that security controls must be usable if they are to be followed consistently. When setup is slow or brittle, people invent workarounds that weaken governance. Good security design therefore includes the friction of the approved workflow, not only the strength of the underlying control.
• Secrets Lifecycle: Secrets lifecycle is the management of credentials from issuance through rotation, revocation, and offboarding. It matters because a secret that is technically valid can still be operationally unsafe if its owner, purpose, or downstream access paths are no longer current.
• Workflow friction: Workflow friction is the operational resistance created when security controls interrupt normal work. In identity programmes, it often appears as repeated prompts, logout failures, password resets, or exception requests, and it can drive users toward insecure shortcuts if the design is not practical.

What's in the full article

Pynt's full analysis covers the operational detail this post intentionally leaves for the source:

• Developer workflow examples that show where security checks most often create friction in CI/CD.
• Guidance on making alerts more actionable so developers can fix issues without security team mediation.
• Practical ideas for automating checks that reduce manual review without weakening governance.
• Examples of tool and process changes that help security and engineering teams share ownership of fixes.

👉 Pynt's full post expands on workflow friction, tool usability, and collaboration patterns that shape security adoption.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity in a practitioner-focused format. It is designed for teams that need identity controls to work at the pace of modern delivery.