WEBVTT
00:00:00.400 --> 00:00:02.799
But let's be honest for a second.
00:00:03.200 --> 00:00:10.960
If annual security training truly worked, we wouldn't keep seeing the same mistakes over and over, would we?
00:00:11.839 --> 00:00:14.560
And it's not because developers don't care.
00:00:15.119 --> 00:00:24.239
It's because annual training asks humans to be perfect while using systems that are anything but.
00:00:25.199 --> 00:00:28.960
Hi, I'm Tanya Jenka, also known as SheHacksPurple.
00:00:29.199 --> 00:00:36.159
Welcome to DevSecStation, a podcast for software developers who want to build more secure software.
00:00:36.399 --> 00:00:46.399
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:46.640 --> 00:00:50.320
You can jump in at any episode, at any time.
00:00:50.719 --> 00:00:52.560
No homework required.
00:00:53.359 --> 00:00:55.679
This episode is sponsored by Maze.
00:00:56.320 --> 00:01:06.480
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:06.799 --> 00:01:18.159
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:18.480 --> 00:01:29.920
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:30.159 --> 00:01:35.359
Learn more about maze at mazehq.com slash devsec.
00:01:35.760 --> 00:01:42.879
If you're a developer who's ever made a security bug in their code, then afterthought, how did this happen?
00:01:43.040 --> 00:01:43.840
I know this.
00:01:44.000 --> 00:01:45.920
How'd I let this happen?
00:01:46.239 --> 00:01:48.640
This episode is for you.
00:01:49.120 --> 00:01:51.599
Here's the core idea of this episode.
00:01:52.000 --> 00:01:57.760
Most security issues don't happen because developers don't know what they're supposed to do.
00:01:58.000 --> 00:02:03.200
They happen because the easiest path is the insecure one.
00:02:03.599 --> 00:02:08.800
When we rely on training alone, we're relying on memory and willpower.
00:02:09.120 --> 00:02:15.439
But when we rely on defaults instead, we're shaping behavior automatically.
00:02:15.680 --> 00:02:20.639
And in live systems, defaults will win every single time.
00:02:21.439 --> 00:02:25.520
So I have a story for you: a very normal developer day.
00:02:25.840 --> 00:02:31.919
You're busy, you're juggling several different tickets, you're context switching all day long.
00:02:32.159 --> 00:02:38.800
You spin up a new service, you copy a config from another repo, you leave the settings as is because they work.
00:02:39.039 --> 00:02:40.319
Nothing feels wrong.
00:02:40.560 --> 00:02:42.479
You didn't ignore security.
00:02:42.719 --> 00:02:46.000
You just followed the path that was already there.
00:02:46.240 --> 00:02:50.479
And if the previous service was okay, this one should be too, right?
00:02:51.680 --> 00:02:55.520
But that's the thing about insecure defaults.
00:02:55.759 --> 00:02:57.840
They don't feel like a bad decision.
00:02:58.080 --> 00:02:59.199
They feel normal.
00:02:59.680 --> 00:03:02.240
You're saving time, you're following the flow.
00:03:02.560 --> 00:03:06.400
And most training doesn't change what feels normal.
00:03:06.800 --> 00:03:10.240
But the right systems can, and they do.
00:03:10.560 --> 00:03:12.479
So how do we fix this?
00:03:13.120 --> 00:03:18.560
A bad approach would be trying to solve security problems with only annual training.
00:03:18.879 --> 00:03:22.560
More slides, more lectures, wah wah, wah.
00:03:23.120 --> 00:03:24.960
But no real change.
00:03:25.360 --> 00:03:31.439
This approach often fails because annual training is easy to forget, especially under pressure.
00:03:31.759 --> 00:03:34.479
And no one is at their best when they're rushing.
00:03:34.639 --> 00:03:39.360
And as software developers, we often find ourselves rushing in our line of work.
00:03:40.000 --> 00:03:47.759
A better approach is hoping developers remember what they learned in the annual training that they did six months ago.
00:03:48.080 --> 00:03:51.919
Be careful, double check, don't forget.
00:03:52.319 --> 00:03:53.919
And this helps a bit.
00:03:54.080 --> 00:04:01.599
I mean, I give training, it definitely helps, but it still depends on constant attention, energy, and willpower.
00:04:01.840 --> 00:04:05.919
And willpower is a terrible security control on its own.
00:04:06.240 --> 00:04:15.039
The best approach is training that explains the why, and then changing the defaults in your system to match.
00:04:15.439 --> 00:04:21.439
So if the secure option is the easiest option, people will take it automatically.
00:04:21.600 --> 00:04:28.000
And with training, they understand why they should not undo those nice secure defaults we just made.
00:04:28.240 --> 00:04:32.800
This isn't about locking things down so that they're unusable or slowing down teams.
00:04:32.959 --> 00:04:38.240
It's about designing workflows that work with human behavior instead of against it.
00:04:38.560 --> 00:04:42.560
If you do just one thing after this episode, please do this.
00:04:42.800 --> 00:04:49.279
Change one default in one repo or project that you work on for the better.
00:04:49.600 --> 00:04:54.240
Here's how to do that in a way that you as a developer might have control over.
00:04:54.480 --> 00:04:58.319
Step one, pick a repo your team actively works on.
00:04:58.560 --> 00:05:04.800
Step two, identify one default that could lead to security problems if someone forgets to change it.
00:05:05.040 --> 00:05:11.920
So this could be a config file that includes insecure settings that you know you're supposed to change later, except no one does.
00:05:12.160 --> 00:05:18.000
A CI job that runs without security checks like static analysis or software composition analysis.
00:05:18.319 --> 00:05:25.439
A code template that skips authentication or logging or validation or anything else that you know should be there.
00:05:25.759 --> 00:05:31.839
A script that assumes secrets are present in plaintext, meaning that you have a leak somewhere.
00:05:32.079 --> 00:05:36.879
Step three, flip that default on so that it's secure from now on.
00:05:37.120 --> 00:05:39.199
Make the secure option automatic.
00:05:39.439 --> 00:05:46.399
Make the insecure option require explicit choice and make it effortful to actually put into action.
00:05:46.639 --> 00:05:54.959
Step four, leave a comment or a commit message explaining why the default exists so future you and your teammates don't undo it.
00:05:55.199 --> 00:05:57.279
You're not fixing everything today.
00:05:57.519 --> 00:06:02.720
You're creating one small nudge that prevents the same mistake from happening again and again.
00:06:02.879 --> 00:06:06.079
And this is how real security improvements can happen.
00:06:06.319 --> 00:06:13.600
It's not through perfect behavior, it's through systems that support you in always making the right decision.
00:06:13.839 --> 00:06:20.879
When you change a default so that it's secure, you're protecting every future change that touches that code.
00:06:21.199 --> 00:06:23.279
And that is win.
00:06:24.240 --> 00:06:26.879
Thanks for listening to DevSecStation.
00:06:27.120 --> 00:06:32.480
If you enjoyed this episode, please subscribe, share it with a friend, or leave a review.
00:06:32.639 --> 00:06:35.040
It helps more people discover the show.
00:06:35.279 --> 00:06:40.240
If you'd like to learn more, I'm Tanya Jenka, also known as SheHacksPurple.
00:06:40.480 --> 00:06:44.160
And I teach secure coding training for software developers.
00:06:44.399 --> 00:06:47.600
You can find me online at shehackspurple.ca.
00:06:48.319 --> 00:06:50.319
Thank you for being here.
00:00:00.400 --> 00:00:02.799
But let's be honest for a second.
00:00:03.200 --> 00:00:10.960
If annual security training truly worked, we wouldn't keep seeing the same mistakes over and over, would we?
00:00:11.839 --> 00:00:14.560
And it's not because developers don't care.
00:00:15.119 --> 00:00:24.239
It's because annual training asks humans to be perfect while using systems that are anything but.
00:00:25.199 --> 00:00:28.960
Hi, I'm Tanya Jenka, also known as SheHacksPurple.
00:00:29.199 --> 00:00:36.159
Welcome to DevSecStation, a podcast for software developers who want to build more secure software.
00:00:36.399 --> 00:00:46.399
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:46.640 --> 00:00:50.320
You can jump in at any episode, at any time.
00:00:50.719 --> 00:00:52.560
No homework required.
00:00:53.359 --> 00:00:55.679
This episode is sponsored by Maze.
00:00:56.320 --> 00:01:06.480
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:06.799 --> 00:01:18.159
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:18.480 --> 00:01:29.920
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:30.159 --> 00:01:35.359
Learn more about maze at mazehq.com slash devsec.
00:01:35.760 --> 00:01:42.879
If you're a developer who's ever made a security bug in their code, then afterthought, how did this happen?
00:01:43.040 --> 00:01:43.840
I know this.
00:01:44.000 --> 00:01:45.920
How'd I let this happen?
00:01:46.239 --> 00:01:48.640
This episode is for you.
00:01:49.120 --> 00:01:51.599
Here's the core idea of this episode.
00:01:52.000 --> 00:01:57.760
Most security issues don't happen because developers don't know what they're supposed to do.
00:01:58.000 --> 00:02:03.200
They happen because the easiest path is the insecure one.
00:02:03.599 --> 00:02:08.800
When we rely on training alone, we're relying on memory and willpower.
00:02:09.120 --> 00:02:15.439
But when we rely on defaults instead, we're shaping behavior automatically.
00:02:15.680 --> 00:02:20.639
And in live systems, defaults will win every single time.
00:02:21.439 --> 00:02:25.520
So I have a story for you: a very normal developer day.
00:02:25.840 --> 00:02:31.919
You're busy, you're juggling several different tickets, you're context switching all day long.
00:02:32.159 --> 00:02:38.800
You spin up a new service, you copy a config from another repo, you leave the settings as is because they work.
00:02:39.039 --> 00:02:40.319
Nothing feels wrong.
00:02:40.560 --> 00:02:42.479
You didn't ignore security.
00:02:42.719 --> 00:02:46.000
You just followed the path that was already there.
00:02:46.240 --> 00:02:50.479
And if the previous service was okay, this one should be too, right?
00:02:51.680 --> 00:02:55.520
But that's the thing about insecure defaults.
00:02:55.759 --> 00:02:57.840
They don't feel like a bad decision.
00:02:58.080 --> 00:02:59.199
They feel normal.
00:02:59.680 --> 00:03:02.240
You're saving time, you're following the flow.
00:03:02.560 --> 00:03:06.400
And most training doesn't change what feels normal.
00:03:06.800 --> 00:03:10.240
But the right systems can, and they do.
00:03:10.560 --> 00:03:12.479
So how do we fix this?
00:03:13.120 --> 00:03:18.560
A bad approach would be trying to solve security problems with only annual training.
00:03:18.879 --> 00:03:22.560
More slides, more lectures, wah wah, wah.
00:03:23.120 --> 00:03:24.960
But no real change.
00:03:25.360 --> 00:03:31.439
This approach often fails because annual training is easy to forget, especially under pressure.
00:03:31.759 --> 00:03:34.479
And no one is at their best when they're rushing.
00:03:34.639 --> 00:03:39.360
And as software developers, we often find ourselves rushing in our line of work.
00:03:40.000 --> 00:03:47.759
A better approach is hoping developers remember what they learned in the annual training that they did six months ago.
00:03:48.080 --> 00:03:51.919
Be careful, double check, don't forget.
00:03:52.319 --> 00:03:53.919
And this helps a bit.
00:03:54.080 --> 00:04:01.599
I mean, I give training, it definitely helps, but it still depends on constant attention, energy, and willpower.
00:04:01.840 --> 00:04:05.919
And willpower is a terrible security control on its own.
00:04:06.240 --> 00:04:15.039
The best approach is training that explains the why, and then changing the defaults in your system to match.
00:04:15.439 --> 00:04:21.439
So if the secure option is the easiest option, people will take it automatically.
00:04:21.600 --> 00:04:28.000
And with training, they understand why they should not undo those nice secure defaults we just made.
00:04:28.240 --> 00:04:32.800
This isn't about locking things down so that they're unusable or slowing down teams.
00:04:32.959 --> 00:04:38.240
It's about designing workflows that work with human behavior instead of against it.
00:04:38.560 --> 00:04:42.560
If you do just one thing after this episode, please do this.
00:04:42.800 --> 00:04:49.279
Change one default in one repo or project that you work on for the better.
00:04:49.600 --> 00:04:54.240
Here's how to do that in a way that you as a developer might have control over.
00:04:54.480 --> 00:04:58.319
Step one, pick a repo your team actively works on.
00:04:58.560 --> 00:05:04.800
Step two, identify one default that could lead to security problems if someone forgets to change it.
00:05:05.040 --> 00:05:11.920
So this could be a config file that includes insecure settings that you know you're supposed to change later, except no one does.
00:05:12.160 --> 00:05:18.000
A CI job that runs without security checks like static analysis or software composition analysis.
00:05:18.319 --> 00:05:25.439
A code template that skips authentication or logging or validation or anything else that you know should be there.
00:05:25.759 --> 00:05:31.839
A script that assumes secrets are present in plaintext, meaning that you have a leak somewhere.
00:05:32.079 --> 00:05:36.879
Step three, flip that default on so that it's secure from now on.
00:05:37.120 --> 00:05:39.199
Make the secure option automatic.
00:05:39.439 --> 00:05:46.399
Make the insecure option require explicit choice and make it effortful to actually put into action.
00:05:46.639 --> 00:05:54.959
Step four, leave a comment or a commit message explaining why the default exists so future you and your teammates don't undo it.
00:05:55.199 --> 00:05:57.279
You're not fixing everything today.
00:05:57.519 --> 00:06:02.720
You're creating one small nudge that prevents the same mistake from happening again and again.
00:06:02.879 --> 00:06:06.079
And this is how real security improvements can happen.
00:06:06.319 --> 00:06:13.600
It's not through perfect behavior, it's through systems that support you in always making the right decision.
00:06:13.839 --> 00:06:20.879
When you change a default so that it's secure, you're protecting every future change that touches that code.
00:06:21.199 --> 00:06:23.279
And that is win.
00:06:24.240 --> 00:06:26.879
Thanks for listening to DevSecStation.
00:06:27.120 --> 00:06:32.480
If you enjoyed this episode, please subscribe, share it with a friend, or leave a review.
00:06:32.639 --> 00:06:35.040
It helps more people discover the show.
00:06:35.279 --> 00:06:40.240
If you'd like to learn more, I'm Tanya Jenka, also known as SheHacksPurple.
00:06:40.480 --> 00:06:44.160
And I teach secure coding training for software developers.
00:06:44.399 --> 00:06:47.600
You can find me online at shehackspurple.ca.
00:06:48.319 --> 00:06:50.319
Thank you for being here.
