Secure Defaults Beat Secure Training

Security training has its place. But if training alone solved security problems, we wouldn't keep seeing the same vulnerabilities appear over and over again. The real problem usually isn't that developers don't know what to do; it's that the easiest path is often an insecure one.

This episode is sponsored by Maze.

In this episode of DevSec Station, Tanya Janca explains why secure defaults are one of the most effective security controls you can implement, why relying on memory and willpower rarely works under pressure, and how small changes to your development workflow can prevent the same mistakes from happening again. You'll learn why better systems consistently outperform good intentions. 

You'll learn:

•  why training alone isn't enough to improve security 
•  how insecure defaults quietly create recurring security issues 
•  why developers naturally follow the path of least resistance 
•  how secure defaults reduce mistakes without slowing teams down 
•  practical ways to improve security by changing one default at a time 

Tanya walks through a familiar day in the life of a busy developer, showing how insecure defaults become "normal" simply because they're already there. She explains why this isn't a developer problem (it's a systems design problem) and how thoughtful defaults can improve security for every future decision. 

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

Choose one repository you actively work on and improve a single insecure default.

For example:

•  update a configuration file so it starts with more secure settings 
•  enable security checks in your CI pipeline to run every time 
•  improve a project template so authentication, logging, or validation are included automatically 
•  replace scripts that rely on plain text secrets to perform proper secret management instead 

You don't have to redesign your entire development process. One better default today can prevent countless mistakes tomorrow.

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):
But let's be honest for a second.
If annual security trainingtruly worked, we wouldn't keep
seeing the same mistakes overand over, would we?
And it's not because developersdon't care.
It's because annual trainingasks humans to be perfect while

(00:20):
using systems that are anythingbut.
Hi, I'm Tanya Jenka, also knownas SheHacksPurple.
Welcome to DevSecStation, 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

(00:44):
systems without slowingdevelopment down.
You can jump in at any episode,at any time.
No homework required.
This episode is sponsored byMaze.
One of the biggest problems insecurity right now is that every
vulnerability or cloud scannersays everything is critical, and

(01:04):
honestly, no one has time forthat.
MAZES uses AI agents toinvestigate vulnerabilities in
context, so you can focus on theissues that are actually
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

(01:26):
of scaling that security teamsreally need right now.
Learn more about maze atmazehq.com slash devsec.
If you're a developer who's evermade a security bug in their
code, then afterthought, how didthis happen?
I know this.
How'd I let this happen?
This episode is for you.

(01:49):
Here's the core idea of thisepisode.
Most security issues don'thappen because developers don't
know what they're supposed todo.
They happen because the easiestpath is the insecure one.
When we rely on training alone,we're relying on memory and
willpower.
But when we rely on defaultsinstead, we're shaping behavior

(02:14):
automatically.
And in live systems, defaultswill win every single time.

So I have a story for you (02:21):
a very normal developer day.
You're busy, you're jugglingseveral different tickets,
you're context switching all daylong.
You spin up a new service, youcopy a config from another repo,
you leave the settings as isbecause they work.
Nothing feels wrong.
You didn't ignore security.

(02:42):
You just followed the path thatwas already there.
And if the previous service wasokay, this one should be too,
right?
But that's the thing aboutinsecure defaults.
They don't feel like a baddecision.
They feel normal.
You're saving time, you'refollowing the flow.
And most training doesn't changewhat feels normal.

(03:06):
But the right systems can, andthey do.
So how do we fix this?
A bad approach would be tryingto solve security problems with
only annual training.
More slides, more lectures, wahwah, wah.
But no real change.
This approach often failsbecause annual training is easy

(03:29):
to forget, especially underpressure.
And no one is at their best whenthey're rushing.
And as software developers, weoften find ourselves rushing in
our line of work.
A better approach is hopingdevelopers remember what they
learned in the annual trainingthat they did six months ago.
Be careful, double check, don'tforget.

(03:52):
And this helps a bit.
I mean, I give training, itdefinitely helps, but it still
depends on constant attention,energy, and willpower.
And willpower is a terriblesecurity control on its own.
The best approach is trainingthat explains the why, and then
changing the defaults in yoursystem to match.

(04:15):
So if the secure option is theeasiest option, people will take
it automatically.
And with training, theyunderstand why they should not
undo those nice secure defaultswe just made.
This isn't about locking thingsdown so that they're unusable or
slowing down teams.
It's about designing workflowsthat work with human behavior

(04:36):
instead of against it.
If you do just one thing afterthis episode, please do this.
Change one default in one repoor project that you work on for
the better.
Here's how to do that in a waythat you as a developer might
have control over.
Step one, pick a repo your teamactively works on.

(04:58):
Step two, identify one defaultthat could lead to security
problems if someone forgets tochange it.
So this could be a config filethat includes insecure settings
that you know you're supposed tochange later, except no one
does.
A CI job that runs withoutsecurity checks like static
analysis or software compositionanalysis.
A code template that skipsauthentication or logging or

(05:21):
validation or anything else thatyou know should be there.
A script that assumes secretsare present in plaintext,
meaning that you have a leaksomewhere.
Step three, flip that default onso that it's secure from now on.
Make the secure optionautomatic.
Make the insecure option requireexplicit choice and make it

(05:43):
effortful to actually put intoaction.
Step four, leave a comment or acommit message explaining why
the default exists so future youand your teammates don't undo
it.
You're not fixing everythingtoday.
You're creating one small nudgethat prevents the same mistake
from happening again and again.
And this is how real securityimprovements can happen.

(06:06):
It's not through perfectbehavior, it's through systems
that support you in alwaysmaking the right decision.
When you change a default sothat it's secure, you're
protecting every future changethat touches that code.
And that is win.
Thanks for listening toDevSecStation.

(06:27):
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 Jenka, also known as
SheHacksPurple.
And I teach secure codingtraining for software
developers.
You can find me online atshehackspurple.ca.

(06:48):
Thank you for being here.