The Most Common Secure Coding Mistakes Good Devs Make

Security bugs aren't usually caused by 'bad developers'. More often, they're the result of good developers making rational decisions under deadlines, competing priorities, and imperfect systems.

This episode is sponsored by Maze.

In this episode of DevSec Station, Tanya Janca explores why common secure coding mistakes are often incentive problems rather than knowledge problems. You'll learn why insecure patterns emerge, why simply telling developers to "be more careful" doesn't work, and how changing your development environment can make secure coding the easiest path forward. 

You'll learn:

•  why good developers still introduce security vulnerabilities 
•  how deadlines, delivery pressure, and operational complexity influence coding decisions 
•  why 'shame and blame' doesn't improve software security 
•  several practical examples of how to replace insecure patterns with more secure ones 
•  how to identify recurring shortcuts and improve them instead of fighting them 

Tanya shares several real-world examples of secure coding shortcuts that teams make every day (from copy-pasted authentication checks to inconsistent secret handling) and explains why these decisions are understandable in the moment, even though they create security problems over time (also known as 'security drift'). She also demonstrates how small changes to defaults, shared libraries, and team patterns can eliminate entire classes of recurring mistakes. 

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

Identify one insecure pattern that keeps showing up in your team's code base and ask why it exists before trying to eliminate it. If you don't know the why, you can't fix it. Then replace that shortcut with an easier, more secure path.

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):
I'd like to clear something up right now.
Most security bugs are notcaused by bad developers.
They're caused by gooddevelopers doing exactly what
the system rewards them fordoing.
They aren't stupid mistakes.
They're rational ones.
Hi, I'm Tanya Jenka, also knownas SheHacksPurple.

(00:23):
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
systems without slowingdevelopment down.
You can jump in at any episode,at any time.

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

(01:08):
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 looked at asecurity issue and thought, I
knew better, why did I do that?
Oh this episode's for you.
There is a very persistent mythin security that insecure code
comes from ignorance, that ifdevelopers just knew more, these
issues would magically go away.

(01:52):
But in practice, most insecurepatterns come from incentives,
from deadlines, performancereviews, feature pressure,
operational complexity.
When the system rewards speed,availability, and delivery,
developers optimize for thosethings and not for security.

(02:14):
That's not negligence, that'sprofessionalism.
I'd like us to look at a fewvery common examples of how this
happens.
You skip input validationbecause the data is internal,
and you're trying to hit adeadline and you know that it's
safe.
You reuse old authorization codebecause it mostly works, and
rewriting it feels pretty risky.

(02:35):
You log less than you know youshould because verbose logs they
cost too much.
You copy a known pattern becauseit worked last time, even though
you know that maybe it's notideal.
In isolation, each of thesedecisions totally makes sense.
They made sense in that moment.
But over time, these shortcutscan really stack up.

(02:59):
And eventually, they can turninto vulnerabilities.
This isn't about bad judgment.
That's not what I'm talkingabout.
It's about local optimization ina very complex system.
So, how do we fix this?
A bad approach would be assuminginsecure code means someone
messed up and then blaming themand shaming them.

(03:21):
That leads to discussions,lectures, more rules, more
shame, and shame does notproduce better software.
A slightly better approach isreminding developers to slow
down and be more careful.
This could help in the shortterm, but it still asks people
to fight incentives usingwillpower.

(03:42):
And willpower is an extremelyfragile security control.
The best approach isn't tellingdevelopers try harder.
It's changing the environment sothat the secure choices are the
easiest and best choices.
Let me give you some concreteexamples of what that actually

(04:03):
looks like.

Example number one: authentication checks. (04:04):
undefined
So instead of copying andpasting authentication checks
everywhere, teams either use atrusted product or they create a
shared helper or middleware andthey use it repeatedly every
single time.
Now the incentives have shifted.
Using the secure pattern isfaster than rolling your own.

(04:27):
Example two, authorizationlogic.
Instead of sprinkling rolechecks all throughout your code
base, teams centralizeauthorization decisions in one
single function.
Developers don't have toremember all the edge cases.
They can just call that helperthat already enforces it for
them.
When.

(04:47):
Example three, input validation.
Instead of ad hoc validation inevery endpoint, teams adopt a
standard validation library orschema.
Skipping validation or writingyour own stops being the
shortcut because the safeversion is already there and
it's easy to use and everyoneelse on your team is doing it.

(05:08):
Example four, error handling.
So instead of catchingexceptions inconsistently, teams
define a standard error handlinglibrary.
Then you do it the same safe wayevery single time.
Example five, secrets andconfiguration.
So instead of letting developersdecide where secrets live, team

(05:30):
make secret management the onlysupported path.
You scan every check-in forsecrets, and if it's not in the
secret manager, it just doesn'twork and does not run and does
not let you check it in.
When?
In all of these examples, wedidn't fix security by giving a
developer a big lecture.
We fixed it by making the secureoption easier, faster, and less

(05:54):
risky than some shortcut thatthey usually did before.
That's how we can eliminateinsecure patterns without
blaming people.
If you do just one thing thisweek after this episode, please
do this.
Identify one insecure patternyour team uses for good reasons

(06:14):
and then make it safer.
How do we do that, right?
Step one, find a securityshortcut that has been happening
for some time.
Perhaps a security tool has beenchirping about that same thing
forever and you have beensuppressing that result.
Perhaps there's a comment thatkeeps showing up over and over
in your PR reviews.

(06:36):
A security incident was causedby this shortcut, or perhaps
there was like a near miss as aresult.
Something that is copied andpasted all the time, but no one
maintains that thing.
Code that has a note on it thatsays fix later, but has never
been fixed.
Developers don't discoverinsecure patterns by knowing
security better and being anexpert on vulnerabilities.
They discover them when the sameproblem shows up repeatedly.

(07:00):
Okay, step two, ask why doesthis exist?
Is it saving time?
Is it reducing risk?
Is it avoiding outages?
Because if you change it and youdon't also fix why it exists,
it's definitely going to comeback and we don't want that.
Okay, so you need to understandthe why.
Step three, improve the pattern.
So for example, replace thatcopy paste auth check with a

(07:22):
shared helper.
Add a safe default wrapperinstead of raw access.
Introduce a lightweightvalidation library instead of ad
hoc checks that areinconsistent.
You are not asking people tostop doing their jobs, you are
giving them a safer way tosucceed.
Good developers don't writeinsecure code because they don't

(07:42):
care.
They rate it because they careabout shipping, stability, and
users.
When we acknowledge that,security stops being adversarial
and it starts becomingcollaborative.
And that is what we want.
Thanks for listening toDevSecStation.
If you enjoyed this episode,please subscribe, share it with

(08:03):
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.
Thank you for being here.