Let's talk about something that developers and security professionals almost never say out loud. Sometimes security tools make things worse, not better. More alerts, more noise, more work, and sometimes not even more security. It's true. Hi, I'm Tanya Jenka, also known as SheHags Purple. Welcome to DevSecSation, a podcast for software developers who want to build more secure software. In each episode, I'll share a short practical lesson about secure coding, software security, and how to build safer systems without slowing development down. You can jump in at any episode, at any time. No homework required. This episode is sponsored by MAES. One of the biggest problems in security right now is that every vulnerability or cloud scanner says everything is critical, and honestly, no one has time for that. MAZES uses AI agents to investigate vulnerabilities in context, so you can focus on the issues that are actually exploitable in your environment and not just theoretically scary. Their AI agents also generate and prioritize fixes that knock out multiple vulnerabilities at once, which is honestly the kind of scaling that security teams really need right now. Learn more about maze at mazehq.com slash devsec. If you've ever opened a security tool, seen hundreds of findings, and immediately felt overwhelmed or completely and utterly annoyed, this episode's for you. Security tools usually fail developers for one single reason. They optimize for coverage, not for reality or normal developer behavior. They're really good at answering the question, is it possible that this thing could exist? But they're often quite bad at answering questions developers usually care about, such as, does this matter right now? Does this cause legitimate business risk? Is someone going to actually hack this and find this? When tools don't respect developer time, developers stop trusting them. And when the trust is gone, even a good signal can be ignored. Here's a pattern you might be familiar with. You run a scan. It finds hundreds or even thousands of issues. Some are low, severity, some are theoretical, many aren't even reachable from within your code. You do not have time to fix all of them, so you start triaging. Eventually you learn which alerts that you feel you can safely ignore. But then one day, something important shows up. But by then it looks like the rest of the noise. This isn't a developer failure. This is what happens when tools don't distinguish between possible and meaningful. So how do we avoid this? A bad approach is enabling every security tool with default settings and then hoping for the best. This creates something called alert fatigue pretty much instantaneously. Developers don't ignore security because they don't care. They ignore noise. And that approach all it does is create noise. A better approach is asking developers to manually triage the findings. And this could work for a while. But it turns security into a consistent tax on the developer's time, and eventually speed, time, and deadlines are gonna win. The best approach that we could do here is making security tools opinionated, make them quiet by default, and have them only get loud when it truly matters. This means carefully tuning them at the start and continuing to tune them as time goes on. For developers, this looks like failing builds only on issues that are high severity and that are reachable. Highlighting net new problems, not every single historical one. Surfacing findings at the moment, you can still fix them cheaply, which means as early as possible in the SDLC. When tools behave this way, developers can learn to trust them. And trusted tools can help us change behavior for the better, and then everyone wins. If you do just one thing after this episode, please do this. Pick one security tool you already have and tune it so that it's finally respecting your time. Here's how to do that as an individual developer. So choose the tool that you personally interact with the most often. So that could be SCA, SaaS, secret scanning, whatever affects your time the most. Step two, identify which findings you never act on. Be honest. If you always ignore lows, mark them informational. If unreachable findings never get fixed, then just filter those out, right? Step three, make the tool loud only for things that you would actually stop to fix right away. So for example, high severity and reachable from within your code. Newly introduced issues, like in that PR you just merged. Secrets at all. If you can't change the global settings, you can do it locally. Add documentation, scripts, or filters to your repo so your team sees the signal, not the noise. If you aren't sure, ask the application security team for help. You shouldn't need permission to reduce noise in your own workflow. So for clarity, security tools are not bad. They just often weren't designed with developer behavior in mind. And when tools earn trust, developers are willing to use them. And when developers use them, security improves naturally and everyone wins. Thanks for listening to DevSecStation. If you enjoyed this episode, please subscribe, share it with a friend, or leave a review. It helps more people discover the show. If you'd like to learn more, I'm Tanya Janka, also known as SheHacksPurple. And I teach secure coding training for software developers. You can find me online at shehackspurple.ca. Thank you for being here.