Notifications
Clear all
Topic starter
02/08/2026 11:45 am
TL;DR: Security friction, noisy alerts, and late findings push developers toward workarounds and bypasses, while AI-assisted scanning helps only when it is integrated into existing workflows and paired with clear remediation guidance, according to Semgrep. The central issue is not tooling volume but whether security appears early enough, with enough context, to change developer behaviour before insecure code ships.
NHIMG editorial — based on content published by Semgrep: Security Resistance and Friction Free
Questions worth separating out
Q: How should security teams reduce access friction for software engineers?
A: Start by removing avoidable approval steps from routine development access, then centralise authentication and entitlement visibility so engineers are not forced to manage multiple credentials across databases, clusters, and internal tools.
Q: Why do noisy security alerts weaken code security?
A: Noisy alerts train developers to distrust the tool, which leads to ignored findings and manual workarounds.
Q: What do teams get wrong about AI-generated documentation and code review?
A: They often assume documentation or review output is proof of oversight.
Practitioner guidance
- Move scanning into the developer workflow Run static analysis on pull requests, merge requests, and in-IDE events so developers see findings while the code context is still fresh.
- Tune findings for actionability, not volume Suppress trivial and duplicate alerts, then review rule precision regularly so the tool does not train developers to ignore it.
- Pair detection with remediation guidance Require alerts to explain why the issue matters, show the likely attack scenario, and point developers to the fix path in plain language.
What's in the full article
Semgrep's full article covers the workflow and tooling detail this post intentionally leaves for the source:
- How to place static analysis into pull request and IDE workflows without slowing delivery.
- Examples of reducing false positives so developers trust findings instead of ignoring them.
- Guidance on using AI to triage issues and explain remediation in human-readable terms.
- Culture and incentive patterns that increase fix rates rather than defect counting.
👉 Read Semgrep's analysis of developer security friction and secure coding adoption →
Developer security friction: is your workflow helping or blocking?
Explore further
02/08/2026 12:56 pm
Security friction is a governance failure, not just a usability issue. When developers bypass controls because the workflow is painful, the organisation is signalling that enforcement has outrun adoption. That creates blind spots in code security, secrets handling, and pipeline identity controls. The practical conclusion is that security must be engineered for use, not merely for policy compliance.
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: Developer security friction is the real barrier to secure code
