Notifications
Clear all
Topic starter
18/08/2026 2:18 pm
TL;DR: Developer frustration with security tools usually comes from late-stage enforcement, slow feedback loops, and interfaces that do not match how software teams work, according to Pynt. The real issue is not developer resistance alone, but an operating model that treats security as a checkpoint instead of a shared delivery control.
NHIMG editorial — based on content published by Pynt: Why developers seem to have such a hard time with security tools
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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.
👉 Read Pynt's analysis of why developers struggle with security tools →
Developer-security friction in CI/CD: what teams need to fix?
Explore further
18/08/2026 3:10 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Why developer-security friction still slows secure software delivery
