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.
Editorial analysis by NHI Mgmt Group, based on content published by Semgrep: “Security Should Be the Path of Least Resistance”.
Key questions
A: The best approach is to make security checks fast, early, and actionable.
Q: Why do noisy security alerts cause teams to ignore static analysis findings?
A: Because repeated false positives turn the tool into background noise.
Q: What breaks when application security testing is moved too late in the delivery cycle?
A: Late testing turns vulnerabilities into backlog, which increases alert fatigue and encourages teams to work around controls.
Practitioner guidance
- Embed scanning in developer workflows Run static analysis in pull requests, merge requests, and the IDE so findings appear while the developer still has full code context.
- Reduce alert noise before rollout Tune rules to suppress trivial or redundant findings and review false-positive patterns so the tool earns trust instead of eroding it.
- Pair findings with immediate remediation guidance Require concise explanations, likely attack scenarios, and fix instructions for each alert so developers can resolve issues without leaving the workflow.
Bottom line: Security friction turns protective controls into bypass incentives when developers cannot resolve findings quickly in their normal workflow.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 12:56 pm
Security friction is a governance failure, not just a UX problem. When controls are so disruptive that developers work around them, the organisation has already lost the ability to shape secure behaviour at the point of code creation. That failure is especially visible when security is treated as a post-build checkpoint instead of a delivery constraint. The practitioner conclusion is simple: if a control cannot survive daily workflow pressure, it will not govern risk for long.
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: Should organisations automate fixes for AI-generated vulnerabilities?
A: Yes, for repeatable flaw classes where the fix is well understood and the risk of delay is high. Automated remediation should handle predictable issues such as input validation, secret handling, and object reference mistakes, while humans focus on architectural decisions and exceptions. That division is the only scalable way to keep pace with AI-assisted delivery.
👉 Read our full editorial: Developer security friction is the real barrier to secure code