Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
SPEAKER_00 (00:00):
Let's talk about
vibe coding for a second.
You know the feeling.
The code is flowing, the testsare passing, you and your AI
assistant are on a roll.
And then six weeks later, you'restaring at the code thinking,
why did we do it that way?
(00:21):
That feeling that you arefeeling, that's called security
drift.
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
(00:42):
secure coding, softwaresecurity, and how to build safer
systems without slowingdevelopment down.
You can jump in at any episode,at any time.
No homework required.
This episode is sponsored byMAISE.
One of the biggest problems insecurity right now is that every
vulnerability or cloud scannersays everything is critical, and
(01:06):
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:29):
of scaling that security teamsreally need right now.
Learn more about maze atmazehq.com slash devsec.
If you use Copilot, ChatGPT,Cursor, or any AI-powered coding
assistant, even occasionally,this episode is for you.
I want to pause for a second anddefine what I mean by security
(01:51):
drift because clarity iskindness and important.
Security drift is when softwarekeeps functioning, but the
security assumptions it wasbuilt on slowly change, without
anyone explicitly choosing tochange them.
So the code still works,nothing's actually obviously
broken, but the protections thatyou thought were there aren't
(02:14):
quite the same anymore.
And this doesn't come from baddecisions, this comes from
convenience.
AI assistants are very good athelping you move fast, but they
are terrible at knowing yourthreat model.
They optimize for what compiles,what looks idiomatic, and what
they've seen before.
(02:36):
They do not optimize for yourenvironment, your data
sensitivity, or your risktolerance.
Essentially, they don't have anycontext.
And that's a very normalscenario where this can happen.
So imagine this (02:51):
you ask your
assistant to generate a helper
function.
It gives you something thatworks.
Great.
Later, you ask it to extend thatlogic and it copies a pattern
from earlier.
Then someone else asks it torefactor a file and it removes a
check because it looks like it'sredundant.
(03:13):
No one made a conscious decisionto weaken security.
It just drifted.
The code still works, the testsstill pass, but the
authentication logic is just alittle bit thinner, the
validation is just a little bitlooser.
Maybe some of the loggingdisappeared.
This is not necessarily an AIproblem, but it is definitely a
(03:37):
workflow problem.
How do we avoid this?
The bad, but unfortunately, verycommon approach that I see is
treating AI-generated code ascorrect by default.
It looks clean, it compiles, itfeels professional.
I'm sure it's good.
But AI is extremely confidenteven when it's wrong.
(03:58):
And confidence does not ensuresecurity.
A better approach is reviewingAI-generated code the same way
you'd review code from ateammate.
And this helps.
But it still assumes thatreviewers remember to look for
security issues every time whilethey're trying to move fast.
And this is where drift couldpotentially sneak in.
(04:19):
The best approach is notreviewing harder, it's
constraining the patterns AI isallowed to introduce.
So what I mean by that is youexplicitly decide which
security-sensitive patterns areacceptable and you make
everything else harder for it touse.
In practice, this looks like afew very specific things.
(04:42):
So you keep one or two knowngood examples of how your team
does authentication,authorization, validation, or
secret handling.
You treat those examples as thesource of truth and you expect
the AI-generated code to alwaysmatch them.
If the code does not match, itdoes not get merged.
(05:02):
Not because it's bad, but it'sinconsistent.
And wherever possible, you backall this up with automation.
So feed all of those goodexamples into a reg server or
add it to your prompts that youwork with every day.
Then you add on top of thattests, linters, or static
analysis that double-check thosepatterns so humans don't have to
(05:25):
remember them every single time.
When AI is forced to stay insidea known pattern, it stops making
security decisions on yourbehalf that you're not
necessarily aware of.
And that's how we get speedwithout getting security drift.
If you do just one thing afterthis episode, please do this.
Pick one place where AI writescode for you and add a
(05:49):
guardrail.
There's a manageable way thatyou can do this.
Step one, identify where AIshows up in your workflows.
Is it generating functions,tests, configurations,
infrastructure as code?
Whatever it's doing.
Step two, pick onesecurity-sensitive area.
Authentication, authorization,input validation, secret
(06:13):
handling sensitive data, yourchoice.
Step three, make a rule.
AI can suggest code here, but itmust be reviewed against a known
secure pattern.
So this could be an internalcode example, a checklist item
in your PR template, or a simplecomment such as, was this
(06:34):
written by an AI?
If yes, was security explicitlyreviewed?
Step four, if you can, automateall of it.
Use a reg server, prompts, lintrules, tests, static analysis,
anything that can help you catchdrift.
And just to be clear, we are notbanning AI.
(06:55):
We are protecting the securityassumptions that your system
depends on every day.
Vibcoding's not bad.
But speed without boundariesallows for subtle, quiet,
unnoticeable changes that aren'talways good.
When you add secure guardrails,you keep the speed and the
(07:18):
security.
That's not us slowing down,that's us maturing.
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 Jenka, also known as
SheHacksPurple.
(07:39):
And I teach secure codingtraining for software
developers.
You can find me online atshehackspurple.ca.
Thank you for being here.