I often hear people complaining that they wish security would get out of the way and just let them do their jobs, or play their games, or watch their show, or buy the latest widget. “Why do I have to sign in, AGAIN?” “Why do I need to enter a code?” “What was my password?” “No one can read these mangled up words.” “Why am I getting another alert?” Just stop already! People, including developers, just want to get stuff done, or just write code, and not worry about security. They want to do their work, have their fun and not jump through 10 layers of bureaucracy to accomplish anything.
Does all this security friction that we have built onto everything from online commerce to watching TV to building an app actually make us more secure or does it just push people to bypass the restrictions, to find workarounds to the security we so painstakingly put in place eventually making us even less secure?
Security Resistance
This is nowhere more apparent than with software developers, the very people who should be helping us be more secure are often fighting with their tools to get their projects to pass security checks. They battle with pop-ups and notifications and end up suffering from alert fatigue. First and foremost developers just want their code to work, security is a secondary concern, in fact most developers are unaware of secure coding best practices unless they are forced to follow them. To a developer security is often irrelevant until it is mandatory.
Some developers think AI will save them, that AI will find all of the security issues and fix them. But over reliance on AI creates its own problems. Relying solely on AI to find and fix security issues results in a high false positive rate, difficulty in reproduction or traceability, and encourages developers to stop thinking about threat models. AI only security results in reactive security ‘scan and fix’ as opposed to being proactive. AI is another tool that can be extremely helpful when used appropriately but should not be relied only as the only check.
In fact most developers do not focus on security unless they are explicitly prompted to. Many organizations do not provide any security training at all and yet still expect their developers to output secure code. Even colleges that offer security courses often do not make them a degree requirement. Without training and knowledge of common security pitfalls it is no wonder there are so many security issues in software.
There are tools available that can easily spot common security issues in software code before that code finds its way into production. However, most of those tools provide long lists of possible defects, false positive alerts, and poor workflow that actively discourage adoption. The more unreliable and difficult a tool is, the more likely its results will be ignored or worse, not even used at all.
Friction Free
So how do we get developers to actually use static analysis tools to help them secure their code? Simple, reduce the friction. Make the tool easy to use, with minimal complexity, and integrate the tool into existing workflows. Allow the developer to actually develop with autonomy and without heavy-handed restrictions. The tool should offer immediate feedback otherwise it will feel like a punishment. Late feedback also encourages a developer to think that security is someone else’s problem. Noise from tools needs to be minimized, too many alerts or false positives will result in the tool not being trusted and ignored.
If your developers haven’t been trained in secure coding practices get them some! If developers are not trained in security principles, then security will feel abstract and alien to them. It is important that security be added in from the start during the code creation process. Most teams wait until the product is nearly ready to ship before even thinking about security. This makes securing a product all that much harder and likely to be skipped entirely.
Reduce Noise - Actionable Guidance
Developers do care about security, they actually want to write secure code but not at the expense of operability or speed. Developers are under constant pressure and time constraints to ship code and will often ship it knowing it’s insecure just to meet deadlines. Tools that are clunky to use or are overly noisy with false positives will erode trust. Any security friction just adds additional stress to developers' already high workload.
As security professionals, we need to adjust our approach. It is important to remember that your developer experience matters. Start by ensuring your security tools are part of your developers workflow so that issues are surfaced immediately as they are created and when they are easiest to fix. Running scans automatically on pull or merge requests and displaying results inside the code review interface or IDE ensures findings are addressed while context is still fresh in the developers mind. Make sure that the tools you use are heavily tuned so that trivial and redundant alerts are never presented. Check that your static analysis tool is using AI as an assistant to help triage and suppress low-risk findings before they reach your developers. AI should help with prioritizing issues and provide actionable guidance for developers to immediately fix issues as they arise. AI is a useful tool for code review augmentation and developer education but should never been seen as a source of truth or a complete vulnerability detection system.
If your tool is flagging vulnerabilities without explaining how to fix them it will just create friction and frustration. Effective tools pair detection with clear remediation guidance so developers can resolve issues quickly and efficiently. Security alerts should include concise, human readable explanations that clarify why an issue matters. Providing brief descriptions, attack scenarios, or links to documentation helps developers understand the underlying risk and helps to demystify the security process.
Cooperative Culture
Security programs succeed when developers are treated as part of the security team, or even better, when security teams are treated as part of the dev team. By maintaining open feedback channels and adjusting processes accordingly, organizations reduce resistance and build a cooperative security culture. Instead of penalizing teams for the number of defects found, reward them for the number of issues fixed. Organizations that follow these principles turn security into a shared responsibility rather than an afterthought.
Key Takeaways
In practice, this means optimizing security tools for developer workflows: fast incremental scans, intelligent filtering, in-context guidance, and a culture that values developer feedback. Use AI were appropriate but don;t expect it to replace your developers. The message to security teams, don't make your developers’ lives harder, don’t make them jump through hoops and then expect a secure product. The secure path must be the path of least resistance!
.jpg)
