Why Current Security Tools Fail Developers

Security tools are supposed to help developers build safer software. But sometimes it seems like they create more frustration than security.

This episode is sponsored by Maze.

In this episode of DevSec Station, Tanya Janca explains why many security tools overwhelm developers with alerts, how alert fatigue erodes trust, and why "more findings" doesn't mean "more security." You'll learn how to tune your classic AppSec tools so they surface meaningful issues instead of creating noise that everyone eventually ignores.

You'll learn:
• why classic AppSec tools often optimize for coverage instead of developer workflows
• how alert fatigue develops and why it leads to missed vulnerabilities
• why developers ignore noise (not security)
• how to improve signal-to-noise in your existing tools
• practical ways to make security tools work with your development process

Tanya walks through a familiar scenario: running a security scan that produces hundreds of findings, spending valuable time triaging alerts, then eventually starting to ignore the noise. She explains why this isn't a developer failure; it's the predictable result of tools that don't distinguish between theoretical issues and meaningful risk.

If you do just one thing after listening to this episode:

Pick one security tool you already use (SCA, SAST, or a secrets scanner) and tune it to better respect your time.

For example:
• prioritize high-severity, reachable findings
• highlight newly introduced issues instead of historical backlog
• filter or downgrade specific types of findings your team never acts on
• configure the tool to surface issues as early as possible in your workflow

The goal isn't to ignore security, it's to make the important signals very loud and visible.

DevSec Station is a podcast by Tanya Janca (SheHacksPurple), focused on short, practical lessons that help software developers build more secure software.

Follow Tanya:

• https://shehackspurple.ca
• https://newsletter.shehackspurple.ca
• https://youtube.com/@shehackspurple
• https://linkedin.com/in/tanya-janca
• https://tanyajanca.com

This episode is sponsored by Maze.
One of the biggest problems in security right now is that every vulnerability scanner says everything is critical, and honestly, no one has time for that.

Maze uses AI agents to investigate vulnerabilities in context, so you can focus on the issues that are actually exploitable in your environment, 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 need right now.

Learn more about Maze https://mazehq.com/devsec

Episode Transcript

SPEAKER_00 (00:00):
Let's talk about something that developers and
security professionals almostnever say out loud.
Sometimes security tools makethings worse, not better.
More alerts, more noise, morework, and sometimes not even
more security.
It's true.
Hi, I'm Tanya Jenka, also knownas SheHags Purple.

(00:23):
Welcome to DevSecSation, apodcast for software developers
who want to build more securesoftware.
In each episode, I'll share ashort practical lesson about
secure coding, softwaresecurity, and how to build safer
systems without slowingdevelopment down.
You can jump in at any episode,at any time.

(00:44):
No homework required.
This episode is sponsored byMAES.
One of the biggest problems insecurity right now is that every
vulnerability or cloud scannersays everything is critical, and
honestly, no one has time forthat.
MAZES uses AI agents toinvestigate vulnerabilities in
context, so you can focus on theissues that are actually

(01:07):
exploitable in your environmentand not just theoretically
scary.
Their AI agents also generateand prioritize fixes that knock
out multiple vulnerabilities atonce, which is honestly the kind
of scaling that security teamsreally need right now.
Learn more about maze atmazehq.com slash devsec.

(01:30):
If you've ever opened a securitytool, seen hundreds of findings,
and immediately felt overwhelmedor completely and utterly
annoyed, this episode's for you.
Security tools usually faildevelopers for one single
reason.
They optimize for coverage, notfor reality or normal developer

(01:50):
behavior.
They're really good at answeringthe question, is it possible
that this thing could exist?
But they're often quite bad atanswering questions developers
usually care about, such as,does this matter right now?
Does this cause legitimatebusiness risk?
Is someone going to actuallyhack this and find this?
When tools don't respectdeveloper time, developers stop

(02:14):
trusting them.
And when the trust is gone, evena good signal can be ignored.
Here's a pattern you might befamiliar with.
You run a scan.
It finds hundreds or eventhousands of issues.
Some are low, severity, some aretheoretical, many aren't even
reachable from within your code.
You do not have time to fix allof them, so you start triaging.

(02:37):
Eventually you learn whichalerts that you feel you can
safely ignore.
But then one day, somethingimportant shows up.
But by then it looks like therest of the noise.
This isn't a developer failure.
This is what happens when toolsdon't distinguish between
possible and meaningful.

(02:59):
So how do we avoid this?
A bad approach is enabling everysecurity tool with default
settings and then hoping for thebest.
This creates something calledalert fatigue pretty much
instantaneously.
Developers don't ignore securitybecause they don't care.
They ignore noise.
And that approach all it does iscreate noise.

(03:22):
A better approach is askingdevelopers to manually triage
the findings.
And this could work for a while.
But it turns security into aconsistent tax on the
developer's time, and eventuallyspeed, time, and deadlines are
gonna win.
The best approach that we coulddo here is making security tools

(03:43):
opinionated, make them quiet bydefault, and have them only get
loud when it truly matters.
This means carefully tuning themat the start and continuing to
tune them as time goes on.
For developers, this looks likefailing builds only on issues
that are high severity and thatare reachable.
Highlighting net new problems,not every single historical one.

(04:07):
Surfacing findings at themoment, you can still fix them
cheaply, which means as early aspossible in the SDLC.
When tools behave this way,developers can learn to trust
them.
And trusted tools can help uschange behavior for the better,
and then everyone wins.
If you do just one thing afterthis episode, please do this.

(04:30):
Pick one security tool youalready have and tune it so that
it's finally respecting yourtime.
Here's how to do that as anindividual developer.
So choose the tool that youpersonally interact with the
most often.
So that could be SCA, SaaS,secret scanning, whatever
affects your time the most.

(04:51):
Step two, identify whichfindings you never act on.
Be honest.
If you always ignore lows, markthem informational.
If unreachable findings neverget fixed, then just filter
those out, right?
Step three, make the tool loudonly for things that you would

(05:11):
actually stop to fix right away.
So for example, high severityand reachable from within your
code.
Newly introduced issues, like inthat PR you just merged.
Secrets at all.
If you can't change the globalsettings, you can do it locally.
Add documentation, scripts, orfilters to your repo so your

(05:33):
team sees the signal, not thenoise.
If you aren't sure, ask theapplication security team for
help.
You shouldn't need permission toreduce noise in your own
workflow.
So for clarity, security toolsare not bad.
They just often weren't designedwith developer behavior in mind.
And when tools earn trust,developers are willing to use

(05:55):
them.
And when developers use them,security improves naturally and
everyone wins.
Thanks for listening toDevSecStation.
If you enjoyed this episode,please subscribe, share it with
a friend, or leave a review.
It helps more people discoverthe show.
If you'd like to learn more, I'mTanya Janka, also known as

(06:17):
SheHacksPurple.
And I teach secure codingtraining for software
developers.
You can find me online atshehackspurple.ca.
Thank you for being here.