WEBVTT
00:00:00.160 --> 00:00:05.599
Let's talk about something that developers and security professionals almost never say out loud.
00:00:05.839 --> 00:00:09.279
Sometimes security tools make things worse, not better.
00:00:09.839 --> 00:00:16.160
More alerts, more noise, more work, and sometimes not even more security.
00:00:17.440 --> 00:00:18.800
It's true.
00:00:19.359 --> 00:00:23.199
Hi, I'm Tanya Jenka, also known as SheHags Purple.
00:00:23.440 --> 00:00:30.399
Welcome to DevSecSation, a podcast for software developers who want to build more secure software.
00:00:30.640 --> 00:00:40.640
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.
00:00:40.880 --> 00:00:44.560
You can jump in at any episode, at any time.
00:00:44.960 --> 00:00:46.799
No homework required.
00:00:47.520 --> 00:00:50.079
This episode is sponsored by MAES.
00:00:50.560 --> 00:01:00.719
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.
00:01:00.960 --> 00:01:12.319
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.
00:01:12.640 --> 00:01:24.079
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.
00:01:24.319 --> 00:01:29.519
Learn more about maze at mazehq.com slash devsec.
00:01:30.400 --> 00:01:41.519
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.
00:01:41.920 --> 00:01:45.599
Security tools usually fail developers for one single reason.
00:01:45.840 --> 00:01:51.599
They optimize for coverage, not for reality or normal developer behavior.
00:01:51.840 --> 00:01:56.799
They're really good at answering the question, is it possible that this thing could exist?
00:01:57.439 --> 00:02:04.000
But they're often quite bad at answering questions developers usually care about, such as, does this matter right now?
00:02:04.239 --> 00:02:06.480
Does this cause legitimate business risk?
00:02:06.799 --> 00:02:09.840
Is someone going to actually hack this and find this?
00:02:10.159 --> 00:02:14.800
When tools don't respect developer time, developers stop trusting them.
00:02:14.879 --> 00:02:19.360
And when the trust is gone, even a good signal can be ignored.
00:02:19.599 --> 00:02:21.919
Here's a pattern you might be familiar with.
00:02:22.159 --> 00:02:23.439
You run a scan.
00:02:23.680 --> 00:02:26.400
It finds hundreds or even thousands of issues.
00:02:26.639 --> 00:02:33.280
Some are low, severity, some are theoretical, many aren't even reachable from within your code.
00:02:33.599 --> 00:02:37.439
You do not have time to fix all of them, so you start triaging.
00:02:37.680 --> 00:02:42.080
Eventually you learn which alerts that you feel you can safely ignore.
00:02:42.319 --> 00:02:45.360
But then one day, something important shows up.
00:02:45.520 --> 00:02:49.439
But by then it looks like the rest of the noise.
00:02:50.319 --> 00:02:52.479
This isn't a developer failure.
00:02:52.719 --> 00:02:58.719
This is what happens when tools don't distinguish between possible and meaningful.
00:02:59.280 --> 00:03:01.039
So how do we avoid this?
00:03:01.520 --> 00:03:07.599
A bad approach is enabling every security tool with default settings and then hoping for the best.
00:03:07.919 --> 00:03:12.800
This creates something called alert fatigue pretty much instantaneously.
00:03:13.360 --> 00:03:16.479
Developers don't ignore security because they don't care.
00:03:16.879 --> 00:03:18.479
They ignore noise.
00:03:18.639 --> 00:03:22.000
And that approach all it does is create noise.
00:03:22.560 --> 00:03:27.599
A better approach is asking developers to manually triage the findings.
00:03:27.759 --> 00:03:30.159
And this could work for a while.
00:03:30.400 --> 00:03:38.800
But it turns security into a consistent tax on the developer's time, and eventually speed, time, and deadlines are gonna win.
00:03:39.120 --> 00:03:49.840
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.
00:03:50.080 --> 00:03:55.439
This means carefully tuning them at the start and continuing to tune them as time goes on.
00:03:55.680 --> 00:04:02.719
For developers, this looks like failing builds only on issues that are high severity and that are reachable.
00:04:03.039 --> 00:04:07.439
Highlighting net new problems, not every single historical one.
00:04:07.840 --> 00:04:14.960
Surfacing findings at the moment, you can still fix them cheaply, which means as early as possible in the SDLC.
00:04:15.360 --> 00:04:19.360
When tools behave this way, developers can learn to trust them.
00:04:19.600 --> 00:04:25.120
And trusted tools can help us change behavior for the better, and then everyone wins.
00:04:25.839 --> 00:04:30.079
If you do just one thing after this episode, please do this.
00:04:30.720 --> 00:04:37.600
Pick one security tool you already have and tune it so that it's finally respecting your time.
00:04:38.000 --> 00:04:40.720
Here's how to do that as an individual developer.
00:04:40.959 --> 00:04:44.800
So choose the tool that you personally interact with the most often.
00:04:44.959 --> 00:04:50.480
So that could be SCA, SaaS, secret scanning, whatever affects your time the most.
00:04:51.120 --> 00:04:55.040
Step two, identify which findings you never act on.
00:04:55.600 --> 00:04:56.560
Be honest.
00:04:56.879 --> 00:05:00.560
If you always ignore lows, mark them informational.
00:05:01.040 --> 00:05:05.759
If unreachable findings never get fixed, then just filter those out, right?
00:05:06.240 --> 00:05:14.079
Step three, make the tool loud only for things that you would actually stop to fix right away.
00:05:14.240 --> 00:05:19.519
So for example, high severity and reachable from within your code.
00:05:19.839 --> 00:05:24.079
Newly introduced issues, like in that PR you just merged.
00:05:24.399 --> 00:05:25.519
Secrets at all.
00:05:26.160 --> 00:05:29.360
If you can't change the global settings, you can do it locally.
00:05:29.759 --> 00:05:36.160
Add documentation, scripts, or filters to your repo so your team sees the signal, not the noise.
00:05:36.319 --> 00:05:39.680
If you aren't sure, ask the application security team for help.
00:05:39.839 --> 00:05:43.920
You shouldn't need permission to reduce noise in your own workflow.
00:05:44.079 --> 00:05:47.439
So for clarity, security tools are not bad.
00:05:47.680 --> 00:05:51.360
They just often weren't designed with developer behavior in mind.
00:05:51.519 --> 00:05:55.199
And when tools earn trust, developers are willing to use them.
00:05:55.360 --> 00:06:01.519
And when developers use them, security improves naturally and everyone wins.
00:06:02.560 --> 00:06:05.199
Thanks for listening to DevSecStation.
00:06:05.360 --> 00:06:10.800
If you enjoyed this episode, please subscribe, share it with a friend, or leave a review.
00:06:10.959 --> 00:06:13.360
It helps more people discover the show.
00:06:13.600 --> 00:06:18.639
If you'd like to learn more, I'm Tanya Janka, also known as SheHacksPurple.
00:06:18.800 --> 00:06:22.399
And I teach secure coding training for software developers.
00:06:22.639 --> 00:06:25.920
You can find me online at shehackspurple.ca.
00:06:26.639 --> 00:06:28.639
Thank you for being here.
00:00:00.160 --> 00:00:05.599
Let's talk about something that developers and security professionals almost never say out loud.
00:00:05.839 --> 00:00:09.279
Sometimes security tools make things worse, not better.
00:00:09.839 --> 00:00:16.160
More alerts, more noise, more work, and sometimes not even more security.
00:00:17.440 --> 00:00:18.800
It's true.
00:00:19.359 --> 00:00:23.199
Hi, I'm Tanya Jenka, also known as SheHags Purple.
00:00:23.440 --> 00:00:30.399
Welcome to DevSecSation, a podcast for software developers who want to build more secure software.
00:00:30.640 --> 00:00:40.640
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.
00:00:40.880 --> 00:00:44.560
You can jump in at any episode, at any time.
00:00:44.960 --> 00:00:46.799
No homework required.
00:00:47.520 --> 00:00:50.079
This episode is sponsored by MAES.
00:00:50.560 --> 00:01:00.719
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.
00:01:00.960 --> 00:01:12.319
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.
00:01:12.640 --> 00:01:24.079
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.
00:01:24.319 --> 00:01:29.519
Learn more about maze at mazehq.com slash devsec.
00:01:30.400 --> 00:01:41.519
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.
00:01:41.920 --> 00:01:45.599
Security tools usually fail developers for one single reason.
00:01:45.840 --> 00:01:51.599
They optimize for coverage, not for reality or normal developer behavior.
00:01:51.840 --> 00:01:56.799
They're really good at answering the question, is it possible that this thing could exist?
00:01:57.439 --> 00:02:04.000
But they're often quite bad at answering questions developers usually care about, such as, does this matter right now?
00:02:04.239 --> 00:02:06.480
Does this cause legitimate business risk?
00:02:06.799 --> 00:02:09.840
Is someone going to actually hack this and find this?
00:02:10.159 --> 00:02:14.800
When tools don't respect developer time, developers stop trusting them.
00:02:14.879 --> 00:02:19.360
And when the trust is gone, even a good signal can be ignored.
00:02:19.599 --> 00:02:21.919
Here's a pattern you might be familiar with.
00:02:22.159 --> 00:02:23.439
You run a scan.
00:02:23.680 --> 00:02:26.400
It finds hundreds or even thousands of issues.
00:02:26.639 --> 00:02:33.280
Some are low, severity, some are theoretical, many aren't even reachable from within your code.
00:02:33.599 --> 00:02:37.439
You do not have time to fix all of them, so you start triaging.
00:02:37.680 --> 00:02:42.080
Eventually you learn which alerts that you feel you can safely ignore.
00:02:42.319 --> 00:02:45.360
But then one day, something important shows up.
00:02:45.520 --> 00:02:49.439
But by then it looks like the rest of the noise.
00:02:50.319 --> 00:02:52.479
This isn't a developer failure.
00:02:52.719 --> 00:02:58.719
This is what happens when tools don't distinguish between possible and meaningful.
00:02:59.280 --> 00:03:01.039
So how do we avoid this?
00:03:01.520 --> 00:03:07.599
A bad approach is enabling every security tool with default settings and then hoping for the best.
00:03:07.919 --> 00:03:12.800
This creates something called alert fatigue pretty much instantaneously.
00:03:13.360 --> 00:03:16.479
Developers don't ignore security because they don't care.
00:03:16.879 --> 00:03:18.479
They ignore noise.
00:03:18.639 --> 00:03:22.000
And that approach all it does is create noise.
00:03:22.560 --> 00:03:27.599
A better approach is asking developers to manually triage the findings.
00:03:27.759 --> 00:03:30.159
And this could work for a while.
00:03:30.400 --> 00:03:38.800
But it turns security into a consistent tax on the developer's time, and eventually speed, time, and deadlines are gonna win.
00:03:39.120 --> 00:03:49.840
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.
00:03:50.080 --> 00:03:55.439
This means carefully tuning them at the start and continuing to tune them as time goes on.
00:03:55.680 --> 00:04:02.719
For developers, this looks like failing builds only on issues that are high severity and that are reachable.
00:04:03.039 --> 00:04:07.439
Highlighting net new problems, not every single historical one.
00:04:07.840 --> 00:04:14.960
Surfacing findings at the moment, you can still fix them cheaply, which means as early as possible in the SDLC.
00:04:15.360 --> 00:04:19.360
When tools behave this way, developers can learn to trust them.
00:04:19.600 --> 00:04:25.120
And trusted tools can help us change behavior for the better, and then everyone wins.
00:04:25.839 --> 00:04:30.079
If you do just one thing after this episode, please do this.
00:04:30.720 --> 00:04:37.600
Pick one security tool you already have and tune it so that it's finally respecting your time.
00:04:38.000 --> 00:04:40.720
Here's how to do that as an individual developer.
00:04:40.959 --> 00:04:44.800
So choose the tool that you personally interact with the most often.
00:04:44.959 --> 00:04:50.480
So that could be SCA, SaaS, secret scanning, whatever affects your time the most.
00:04:51.120 --> 00:04:55.040
Step two, identify which findings you never act on.
00:04:55.600 --> 00:04:56.560
Be honest.
00:04:56.879 --> 00:05:00.560
If you always ignore lows, mark them informational.
00:05:01.040 --> 00:05:05.759
If unreachable findings never get fixed, then just filter those out, right?
00:05:06.240 --> 00:05:14.079
Step three, make the tool loud only for things that you would actually stop to fix right away.
00:05:14.240 --> 00:05:19.519
So for example, high severity and reachable from within your code.
00:05:19.839 --> 00:05:24.079
Newly introduced issues, like in that PR you just merged.
00:05:24.399 --> 00:05:25.519
Secrets at all.
00:05:26.160 --> 00:05:29.360
If you can't change the global settings, you can do it locally.
00:05:29.759 --> 00:05:36.160
Add documentation, scripts, or filters to your repo so your team sees the signal, not the noise.
00:05:36.319 --> 00:05:39.680
If you aren't sure, ask the application security team for help.
00:05:39.839 --> 00:05:43.920
You shouldn't need permission to reduce noise in your own workflow.
00:05:44.079 --> 00:05:47.439
So for clarity, security tools are not bad.
00:05:47.680 --> 00:05:51.360
They just often weren't designed with developer behavior in mind.
00:05:51.519 --> 00:05:55.199
And when tools earn trust, developers are willing to use them.
00:05:55.360 --> 00:06:01.519
And when developers use them, security improves naturally and everyone wins.
00:06:02.560 --> 00:06:05.199
Thanks for listening to DevSecStation.
00:06:05.360 --> 00:06:10.800
If you enjoyed this episode, please subscribe, share it with a friend, or leave a review.
00:06:10.959 --> 00:06:13.360
It helps more people discover the show.
00:06:13.600 --> 00:06:18.639
If you'd like to learn more, I'm Tanya Janka, also known as SheHacksPurple.
00:06:18.800 --> 00:06:22.399
And I teach secure coding training for software developers.
00:06:22.639 --> 00:06:25.920
You can find me online at shehackspurple.ca.
00:06:26.639 --> 00:06:28.639
Thank you for being here.
