# OWASP Top 10 2025: Vibe Coding and Supply Chain Risks

**Podcast:** Dev Interrupted
**Published:** 2026-06-23

## Transcript

Welcome back to Dev Interrupted.
I'm your host, Andrew Ziegler.
And on the show, we've been learning how the world of autonomous agents are pushing deployment speeds to the limit with security paying the ultimate price.
And we've been covering the ongoing software supply chain crisis with leaders like CEO Dan Loring of Chain Guard.
And today we're pushing the topic even further with a returning guest who also happens to be OWASP Distinguished Member and Hacker of the Year.
Yes, joining me is a favorite who has proven throughout her career that security isn't a product.
practice and that it can be purple too.
She's the best-selling author of Alice and Bob Learned Application Security and Alice and Bob Learned Secure Coding, which we covered on the show.
She's a former rock star and most recently project leader for the OWASP Top 10 2025.
Tanya Janka, aka SheHacksPurple, welcome back to the show.
Andrew, thank you so much for having me.
We're so excited to have you.
And I just want to start by saying, you know, it's always so impressive for me to read your list of credentials and your background.
I think you've had such an amazing career and you have such a really unique perspective to bring to our listeners, especially with your passion around security.
As I say constantly, we just never give enough of a spotlight.
to that topic.
And so I'm really happy to have you here, especially with all of the work you've been doing with OWASP.
I'm really excited to dig in.
So you served as a project leader for the top 10 in 2025.
What was that like?
Can you maybe kind of orient some of our listeners who maybe are less familiar with that world?
So OWASP is an international nonprofit where we have over 300 chapters where people meet in person every month.
Over 100 open source projects.
We have international conferences that move around the world.
And then there's a nonprofit foundation as well.
And our most popular project of all time that is over 20 years old is called the OWASP Top 10, which is supposed to be the top 10 risks to web apps.
But it actually is just the top 10 risks to software in general.
And this time, there's 13.
Has that ever happened before?
No.
So we had to decide what to put in the what's next.
And we had a tie for number 10.
And then there was another one that was just extremely noteworthy.
And then we had to talk about vibe coding.
So I was like, let's just, you know, in the what next, there's just three extra items that I was, we're not going to do another top 10 for two to three years.
And I'm like, we can't just not talk about vibe coding.
We can't.
skip that.
And so the team talked about it and they're like, well, what's the worst that can happen as the community yells at us?
And no one did.
So, yay!
And that's a signal in and of itself that there's so many top of mind, critical security topics that we all need to be talking about that we have to throw away the templated approach we use to talk about them, like the bracket.
We had to expand the bracket because now there's more threats than ever.
How did y'all kind of approach that challenge?
And you say vibe coding makes the list.
So I'm curious, you know, in this world where you're kind of scoping out problems for web apps, but really, you know, all software, what were some of the biggest things that are standing out to you now that maybe didn't stand out years in the past when you've made this list?
Absolutely.
So the way that they, so I mean, the first top 10 list, let's just be really blunt, a bunch of experts just got together, had a couple bottles of wine and just made the top 10 things they always found in Penthouse.
And then going forward, they're like, okay, so we probably need some data.
As it goes.
So then you start getting the data practice to figure out what are actually these application security problems that are plaguing developers.
Yeah, but the issue is gathering data.
So guess who gives us data?
A couple of great pen testing companies who are so awesome to anonymize and share their data with us, which is extremely effortful.
Then we have a whole ton of static analysis and dynamic analysis vendors who then just show us what they know how to find.
Right.
But what we really care about and what data I wish we could have that no one will ever, ever give us is.
specifically incident response data and breach data.
So I know that there's the Verizon breach report and there's a CrowdTrack report in the Microsoft, whatever, right?
But those are really big public breaches.
I mean, the average AppSec nerd responding to attacks that are happening that make a giant mess of everything.
It's like, what was that?
What caused that?
What hurt your company?
Because that's what we actually care about the most is because...
This top 10 list is an awareness document.
And I actually don't care about vendors are good at finding this.
I care about this is what will help you move the needle on protecting your organization and your customers.
And so when we got to talking about it, Andrew, you were talking about like what really stood out.
So what we used to have on the list was using outdated and vulnerable components.
So you use a library and there's like 12 CVEs in it.
And you're like, is that really a good life choice that you're making here?
And we expanded that to include the entire software supply chain.
So is your CI locked down?
Can just anyone push code to prod?
You know, your code repo isn't set to public by accident because I have found that on customer sites more than once.
Are there secrets, places they shouldn't be?
So every single thing you do to create and maintain your software till the day that you retire that software.
So we changed that.
Another one was, so we used to just have, you know, you're bad at logging.
And now we have, you're really bad at error handling, and you're really bad at logging and monitoring.
Because those, we separated them because they just cause so many problems.
And then Vibe coding.
So we didn't have any data to support this except for every single day lived experience.
So you throw vibe coding in this mix.
What does vibe coding's danger profile look like?
Okay, so I define vibe coding.
So using an AI to assist you to write code, awesome.
Assuming you still do the general application security program that you would, you review the code, you make it your own, you understand it.
and agree it's good before you commit it.
To me, vibe coding is the AI is writing everything.
You have no time to review it or you're not taking the time to review it and you're just committing what the AI says.
And Andrew, I teach secure coding and I teach a lot of code review right now and I teach how to use the AI assistant and I have like this prompt library that we use.
And last week I was teaching it with a new client.
And all of us used the same security prompt and the same build prompt.
And there were 60 of us.
And 59 of us got some really good code.
And the 60th person, he's like, is this bad?
This seems bad.
And we're writing in Python.
And I don't know if you know, but there's like a Python linter.
And there's a comment that you can put to say, ignore the following lines.
And Claude had added that and then intentionally leaked secrets.
Yeah.
Wow.
And that was in your security workshop.
So you're like a jackpot.
Exactly what I'm talking about.
These are the dangers of not going back and reviewing your code.
Because it also goes back to, you know, there were 60 people in the room.
59 of them got it right.
That's the reality of agentic engineering or vibe coding.
And if you don't then have the right kinds of structures and harnesses and looking at like hooks and like actually looking at the code, then when you sometimes are that one out of 60.
You're not going to have the protection needed to even understand it's there.
And that was with the secure coding prompt that applies.
So I took basically my yellow book, the secure coding, Alice and Bob book, and I boiled it down to 84 things and I turned it into this guideline and then I turned it into prompts and it applies it as a prompt before it like as it's building the code for you.
And it still did that.
So you took everything within your book, distilled it down to like a prompt that effectively worked like a skill to drive the whole process.
And it still immediately encountered these major problems.
Oh, yeah.
So it goes back to then like, this is why this becomes a sticky.
vulnerability is a sticky problem we have to pay attention to because it's lurking underneath everywhere right now.
Like you said, it's a lived experience every day.
We cover that constantly here, how that's just the reality of engineering now.
It's so true, Andrew.
And I have examples just over and over and over again.
Like when I work with clients and we're reviewing things and we just see, surprise, it decided to remove all the error handling when we switched from Python over into Java.
I don't know why, but it's like, oh, I'll just let the global exception handler catch everything and remove Tanya's beautiful error handling.
I'm like, no clue, no.
And in this case, we're just talking about like the static analysis kind of world.
Like it's leaving weird little things left over in your files or like there's something hanging out, maybe of a secret that's leaked somewhere.
And these are things that are just like obviously big problems to see and find and root out.
There's another element of...
this that I'm sure y'all thought extensively about.
And that's that, you know, this list and the way that we talk about vulnerabilities, they tend to be really compartmentalized.
Like there's this vulnerability and this vulnerability.
And we talk about them as if they live in completely different lands.
Like they're not side by side next to each other in the same files, in the same process.
And so then when you combine that with an agent or any kind of agentic kind of.
whether it's an external person or your own coding assistant, now they have the forethought that maybe chain and combine these different elements that we haven't even thought of before.
So defending security is now just no longer like identifying the patterns.
It's understanding how are they combined, which is not a practice that I think is natural for a lot of security engineers.
I absolutely agree, Andrew.
Honestly, like, so when I learned security, so I was a software developer for a long time.
And then I got a professional mentor that was teaching me about pen testing.
And the first mentor who I write about in my books taught me what not to do.
And then previous mentors since then have all taught me more ethical lessons.
But like when I started speaking at conferences, it was just so I could get him free.
I just wanted to learn from all the other people.
And a lot of people all focused on these are the vulnerabilities.
But when I started teaching, I was like, I don't think I want a developer to memorize 600 CBEs or just like a list of 10 things.
What I really want is for them to know how to write safe code.
So I'd rather teach them the defense.
So for instance, you should always lock the front door before you leave rather than teaching them, you know, someone might rob you, someone might do this, they might do that.
And like having them memorize all of these dangers, instead it's like a best practice is that you always lock your door or, you know, a best practice is that, you know, you handle your errors, you fail closed, right?
And teaching them those patterns, there's way less to learn.
And specifically, like when I teach those 42 things, and a lot of them are like three or four things that are actually just one complete security control.
And if we could just, you know, all apply those security controls, and by control, I mean the code that does the security thing.
So manages your session or, you know, verifies your identity, which is called authentication, right?
So if we could just...
do those controls and follow whatever the best practices are for each one, it doesn't matter what the top 10 says.
And I know like I helped write the new top 10.
So I still think it's valuable because a lot of developers, and I'm one of them, is like, why?
Why do I have to do that?
Right?
So knowing the why is important to a lot of people.
But I think that if we're going to only have so much of their attention, I'd rather teach them the what you should do rather than that this is the scary boogeyman.
Exactly.
And especially because everyone's drowning in information right now.
And there's definitely an asymmetry between these defenders and cybersecurity engineers and the perpetrators and hapless, unprotected agents that are, you know, causing a lot of pain for the software power world that we live in right now.
And it's really just like a matter of days now between major incidents that we all are constantly talking about, whether they're breaches or outages.
And we come back to guardrails and security things, but you also get a lot of data exfiltration and groups that are able to combine these insecurities in really unique ways to take advantage of unprepared companies and enterprises, right?
We are coding at the speed of light.
We're delivering customer value at a speed never before seen.
Do you see this chart?
Do you see how it goes up and to the right and how great that is?
And at the same time, you know, when they close that Zoom call, they're like, oh, God, like I got.
I have a pile of code to review.
I have to understand what we've built and where the direction's going.
And so people make compromises.
And security oftentimes slides and slides and slides down this list.
So what do you think engineered leaders should do right now to have kind of like a wake-up call, use this OWASP top 10 as a roadmap for figuring out how am I going to protect my org while still like taking advantage of all the cool stuff in the world right now?
Okay, so...
I feel that the OWASP Top 10 is a really good tool for getting people to pay attention to security.
I usually don't like the whole fear, uncertainty, and doubt thing that the security industry marketing teams are so good at.
Yes.
But it works.
And so if software developers are like, oh, I don't care about this, it doesn't matter.
It's a thing that can make them care.
Because they, like, you know, for each example, we have like these giant breaches to show that it's true.
And it explains the concept and it helps them understand the why.
But if they're already on board and you already have a positive security culture, I don't think as much as I love the top 10 and me and Tarsten and Neil, we all worked really hard on it.
If you already have a positive security culture and everyone already cares, and that is not everywhere.
But if you're already on that ship.
Instead, I would start with either teaching them what to review for.
And that's something, you know, you can hire out for, but you can also do it internally, right?
Like there's a secure code review project from OWASP.
There's all sorts of things, right?
So quite frankly, you could buy my book and you could show them.
And I'm doing free lessons each month on my book on YouTube.
And so there are cheap options to learn, okay?
teach them what to do if they're already aware that it's a priority.
Another thing, and again, this is like a little self-serving, I created a free AI secure coding prompt library, which you can go get right now at securemyvibe.ca.
And I know, right?
I love that URL so much.
It's a great one.
Thank you.
But basically, it takes...
So there's like a main system prompt that you would add for, you know, your code main instructions, like in your settings, like instructions for code that run every, so every time you generate code, do this.
And then I have a whole bunch of things that, quite frankly, we just turn into skills together if we work together.
And one's like a code review one.
One's, you know, I'm building an API.
One is, you know, I'm doing a threat model.
And it guides you of what to fill in and then create security requirements for you.
So, you know, if you do have to build authentication from scratch, these are the security requirements to make sure you don't screw it up.
What an incredible resource.
Thank you.
Thank you.
And so, again, it's not perfect.
Right.
So reminder, you still have to review the code after, even if you use the code review task, you still if you're going to submit work as your own, you should know what it says, you should understand it.
And if you don't understand it, ask the AI to walk you through it.
So I would start with that.
And I think a lot of us need to modernize our AppSec programs, because quite frankly, no one wants to have like a backlog with like 40,000 critical vulnerabilities.
Right.
And right now what I see is You know, devs are expected to produce like 100x the code that they previously did.
And then they run the stack analysis tool.
And it's like, do you know how wrong you are?
Because you're very wrong.
And then it gives you like 5 trillion bugs that you're supposed to fix.
And people are just pushing by it.
And so we need to try to get as much security in the generation of the code as we can.
then run the code review, then do the other steps we would do.
Oh, goodness.
It almost sounds like you're saying we should shift that security left in the code generation process.
I know.
Are we saying these things again?
We're all back full circle, I guess.
I know.
I agree with you.
The practice has got to go in early because agentic rework is a nightmare.
Anybody who has been trying to play this game of whack-a-mole with outputs, you know that it's always better to be extremely aligned at the very beginning.
It's great that you have these proto skills or these prompts that are proto skills.
People can fill them out with their own kind of information.
I think all of the best skills work this way.
They start by interviewing you, understanding what really matters and what it should care about for you, and then kind of like transforming into exactly what you need.
I think that's a great place for people to start.
You know, use your actual roadmap.
Don't use a boogeyman.
Don't use some abstraction of security.
Use the hard real code that people are reading and writing every day and put practices in people's harness.
and just kind of reboot your security practice in general and remembering that it's like everybody's responsibility because it's not just the engineers writing code anymore.
The surface area of the code in your organization's broader than it's ever been.
And vulnerabilities are popping up everywhere, even like in stuff getting vibe coded in your marketing department.
So.
Yes, yes.
I, I, I knew, so I work for so many companies and one of the companies apparently like the CEO just got super pissed at the marketing team for not doing things he wanted.
And then he missed the flight.
And while he was sitting there stranded in the airport, he programmed, like he vibe coded an entirely new website for the company and then published it.
their real one.
So he like rage coded.
He like rage vibe.
He rage vibe coded.
And then like they made up by Monday and put like the real website back.
But then the marketing team got on board with what the CEO wanted.
Right.
And yeah, I wanted to say two more things.
So one other thing about if you do it at the code generation level.
So right now, a lot of us are not paying for all the tokens we're using.
And one day we're going to have to actually pay the real price and it's not going to be $20, Andrew.
I say that all the time on this show, Tanya.
But if we do the security, as much of the security as we can at the code generation level, we will save a gazillion dollars.
That's exactly right.
Better learn now.
And the other thing is, so when you see a breach in the news or whatever, that's a material breach.
What that means is that there's some legal reason that they have to inform us.
There's at least 100 more breaches for every one of those that they do not legally have to inform us and they're not telling us.
And then for all of those, there's many, many more security incidents where there isn't a specific data breach, but there is still a problem and an incident that was caused.
And in Canada, the tax people are called CRA, Canadian Revenue Agency.
And in 2025, there's an article about how they had hidden 42 material breaches.
How many security incidents do you think they had?
Right.
And so when we see things in the news, that is the tiniest, tiniest tip of the iceberg of what is actually occurring at all of these companies and businesses.
And we are losing trillions and trillions of dollars a year to this.
And so we need to get ahead of this.
I am trying to help the best I can.
I have some projects in the work that I am, when I have something good to report, I'll let you know when I have something to show.
But not only do we have to start security earlier, we need to completely rethink the way we do security because the tool set we have, first of all, just pisses devs off.
It really does.
And it is not working.
It is not affordable.
It's not fast enough.
And it is getting sideswiped or...
put to the side all the time, circumvented, I think is the word.
And we need something that actually works.
And what we're doing is not working.
Exactly.
Security has always been this like skeleton in the closet for companies.
And now we're accumulating those skeletons at a rate never before seen.
The closet isn't even big enough.
And frankly, all of that.
In all of that time, while we're accumulating all of this stuff that we don't know what to do with, how do we learn from it?
Do we even have to report this?
It just becomes this accumulated baggage on the company and everything that you're building.
You have to remember that all of those skeletons in your closet is an attacker's learning.
It's something an attacker is leveraging over you.
It's something that is out there in the wilds.
producing those skeletons, right?
And so that thread is growing bigger and larger.
Those skeletons have to come from somewhere.
And this goes back from the asymmetry of defenders versus attackers and the security space.
Like we've talked a little bit here about like just having good security practices and doing them early because of the compounding benefits like financially and also just security wise later on downstream.
But there's also the reality of, you know, we're building and shipping software and we're pretending that like the...
The package-based ecosystem that we use to modularize and run all of our software just is going to keep working as usual.
We're just going to have lots more velocity on it.
But in reality, it's coming apart at the seams and becoming one of the biggest vulnerabilities that any of us could possibly think of.
And it all always exists outside of our org.
This becomes everyone's responsibility.
And so the software supply chain risk is larger than ever before.
did y'all think about that with your list?
But how do you think about that personally with how you advise folks to think about how their software interacts with the rest of the world?
So I actually have a slightly different take than what we put in the document.
So in the OWASP Top 10, we talked about how supply chains are being attacked.
So, you know, someone is attacking your code repository, they're doing malicious dependencies, you know, they're trying to attack the pieces that you use.
to create and maintain your software.
But I actually have a slightly different opinion that kind of goes one layer up from that.
And if you look at the Verizon breach report, CrowdStrike, all of those great, smart, amazing folks that put those annual reports together, they call it a supply chain attack.
But if you're the type of nerd that reads that stuff, which I am, if you look at some of the things that they call a supply chain attack, What actually happened for some of the biggest ones is it was actually one software developer employee, one human being that was compromised.
And because they're so powerful and they have so much access, it broke open multiple parts of the chain.
And when I hear a company call themselves a supply chain security company, and all they do is tell you if your dependencies are safe, I'm like, well, you're doing 1 19th.
in my opinion, of the job.
To me, there's so many different parts.
And basically, in my opinion, the software developer themselves has become a target.
And it's amazing.
There's another podcast called Darknet Diaries, and there was this woman on there called Maddie Stone.
And she basically, she's part of Project Zero.
She is this brilliant, amazing human.
And she announced at Black Hat all these vulnerabilities in the Android operating system, whatever, and how she had kind of detected Pegasus, which was this spyware software and the five things that she had found or whatever.
And she said there were around 200 people in the room.
And then later, like a week later, all of those were changed.
And she's like, and there was no recording available yet.
So that means those people were literally in the room and went and changed the code based on what I said.
And then she was saying she went to Israel.
And some men came up to her and talked to her who worked at that company.
And I would poop my pants, Andrew.
She handled it way better than I would have.
Yeah, that's terrifying.
You're so right that the software engineer themselves becomes the attack surface.
Yeah.
And so, like, imagine, you know, I don't know if you read XKCD comic, but there's this comic about, you know, all the different things you can do to, like, encrypt your password in all these safe ways.
And then the guy's like, I have a wrench and I'm just going to hit you with it until you tell me your password.
It's like, I'll just sell two now.
Right?
Because that's what would really happen.
And so, like, as like some of these breaches are like hundreds of millions of dollars, right?
Like they're these huge things.
And so we have to, so as security professionals, we need to protect our developers.
Like physical protection of your building is one thing, but I mean, like protect their workstations, protect their online accounts, protect their passwords, give them a password manager, teach them about digital safety.
And I know that they're ways more knowledgeable than the average person, right?
But they need to be a hundred times more knowledgeable because they're such an amazing target.
Right.
That's exactly the point is that you have to remember something's producing those skeletons in the closet.
There are dangers that are lurking in the space in which you work and they're invisible to you because you work from your living room, but you underestimate how much is connected to all of the machines that you can log into.
And there are so many ways to get compromised now in such a small localized way.
that can have these catastrophic effects, even just the idea of trying to code something up on your computer.
And so you throw together a little project.
And so it's going to grab a few dependencies, strap something together for you really fast.
And then before you know it, there's a pre-install script on one of those NPM packages that has now all of your environmental variables.
And this happens constantly to the point where...
Packages get huge packages that any LLM would reach for as, oh, I want to build a website.
This is one foundational building block I'm going to grab for every time.
Those ones get targeted.
And then in a matter of minutes.
Then they would get like a deployed, like someone would control their like their like container deployment.
They would deploy like a new version.
All of these AI workflows and stuff are going to download it and run it.
And now it's just like they've all been compromised in the surface area of that is huge.
And it's quantified in a way where it's like we've never really had to quantify it in that way, in that level before.
It's like that kind of compromise is not new.
The speed at which it happens is.
terrifying.
There have been projects where I've worked on and where it's like the only way that I could secure myself was to stand completely still.
Just I had to stop what I was doing.
And it's like, you can't pull anything.
I can't trust these packages.
There's a serious issue that's affecting a lot of things I know that I know are related to what I'm working on right now.
I literally can't even work on it.
Because I'm too afraid of what vulnerability you might pull in.
And so that is a new way of working, I think, for a lot of engineers.
And I think a lot of folks are still not aware of those lurking threats.
If your AI bill went up this year, but you can't show what it bought, this one's for you.
Andrew and I are hosting a live workshop, Life Beyond Token Maxing, AI efficiency for the long term.
We'll get into why token counts fall flat in executive conversations.
where AI is moving the bottlenecks in your pipeline, and how the APEX framework builds on existing productivity metrics frameworks to measure what matters in the AI era.
Everyone who registers for the event gets early access to our new guide on measuring efficiency in the AI-driven SDLC and controlling the executive conversation around these discussions.
The link is in the show notes.
Come hang out with us on June 25th.
If I could offer a small amount of technical advice, I would, if possible, disable post-install scripts for your entire organization by default.
And I know that that will break some stuff.
You will find those things very, very quickly.
And then you examine them and decide, is this post-install script trustworthy?
Right?
And then you run or do not run it.
Also, if you're doing NPM auto update, make it so that everything you auto update is seven days old or older.
Because the NPM ecosystem within 24 to 48 hours seems to be able to find things.
They're working their buns off on it.
And so if you make it seven days or older, that is a lot better.
So if you could just like, if everyone could just do those two things, that would be a huge improvement just to start.
I love that.
You just shifted that left for me.
I'm going to start doing that myself.
And I'm sure this is something that I would have learned if I would have taken one of your proto prompts and turned it into a skill.
And it probably would have pushed me to do that practice.
So this is, I think, a good reminder for folks that there are a lot of things that we could be shifting left earlier now in our process.
And just those small little things can have huge improvements.
I appreciate that tip.
I actually, so I have a new podcast that are five minute security lessons for software developers.
And both of those things were in my lessons.
And so it's called DevSec Station and it's just five or six minutes long.
So yeah, if people want that little time and I give you homework because I'm a teacher and I can't help it.
But one of the homework is those things.
Amazing.
Well, we're definitely going to include those links so folks can go check out your security tidbits because I think these are just little reminders we all need.
That way we can find those earlier ways to be more secure.
So we've talked about how like...
There's a lot of different places that our security breaks down.
There's an asymmetry and attackers and defenders and how ultimately this comes down to building stronger practices, having those conversations earlier, but then also getting side by side with developers in the way that they're working, understanding it, and then figuring out how to secure it.
Because engineers have become this incredibly vulnerable surface area for organizations.
threat is really hard to, it becomes like a boogeyman.
And like you said in the beginning, Tanya, like it's hard to teach apps like security against this like boogeyman kind of thing.
How do you fight the boogeyman?
Well, you just know what good is and you cultivate strong habits yourself.
And, you know, I think security largely is not really.
a knowledge problem.
You've said before that it's a training problem.
I completely agree with you because it's not that we don't understand these things.
It's just that we don't know how to necessarily apply them and we don't have the rigor to know when we should stop ourselves and reconsider what we're doing.
So what are some like training habits that you've been instilling in your classes right now that are kind of improving the way that they start to make this shift?
Oh, my gosh.
So I teach all of the basic security controls.
So the first one, the number one, if you were going to do one single thing, period, would be input validation.
So every single piece of input to your system.
So that means something that's in the URL parameter, something that's in a hidden field.
A hidden field says, oh, my gosh, malicious actor, look here, it's going to be so good.
So anything that comes into your system that you don't completely control, untrusted.
validating that it is exactly what you're expecting and if not rejecting it, don't fix it, right?
And then escaping or sanitizing out special characters that you must accept and then doing it on a trusted system with an allow list rather than a block list.
So if everyone did that, we would be awesome.
And so what we do is we talk about that and then I'm like, let's look at some code.
So then we look at bad code where we're doing that wrong, right?
So We're getting the data and using it and then validating it after, or we're validating with a block list or whatever.
We're just doing it wrong so that they can spot it from then on.
Then it's like better code.
So it's like, let's fix that one thing.
And then we do the best code, which is like, here's 12 layers of defenses of how we could make this rock solid.
Now, do you need 12 defenses every time?
No, you don't.
You don't want to spend $2 million.
defending something that's worth $100,000 in less lives or national security or extraordinarily valuable intellectual property or something else like that's involved, right?
So then you talk about how many precautions do we actually need, right?
And so if they can spot a problem easily, stuff will stop getting past them.
Because what you want to do...
instead of like having people memorize stuff is what you want to do is teach them pattern recognition and good habits.
And so if they can just spot it, you can't stop seeing it, Andrew.
Like you just, you see it all the time from then on.
It's like if you, so I used to own a blue Honda Fit.
Oh, yeah.
So once you have a blue Honda Fit, once you own a car, you always see your car everywhere else.
It's like, oh, there's my car again.
You think everybody has your car.
But it's like a bias, right?
Because now you're paying more attention to it than you ever would have before.
And so you have to hijack that same part of your brain that is obsessed with your Honda Fit.
Exactly.
And so when we see patterns and we have this pattern recognition, you're going to see it all the time.
And then you're not going to tolerate it.
And with us needing to review code, that's what we really need is to know just the basic security controls and how to spot when they're not there, like not where they should be, or that they're not looking right.
Exactly.
I love also too how you remind us that, you know, security is a gradient and you have to understand where on that gradient you have to invest your time.
This is difficult.
for a lot of engineers.
And we love zeros and ones.
We love checking that box completely.
And so a security practice in doing it and what we would think of as like a half-assed way is a really hard pill to swallow when you're going to be like, I'm going to be this application security nerd and transform how secure my org is, right?
And so, but you have to remember that like not every level of investment is worth all of that effort and security, but then also too, what is the level of sensitivity of what's going on inside of that?
that system that you're trying to secure.
So there's actually a lot of nuance that's subjective to evaluating and understanding those things.
And so it's about pointing out the patterns and also probably having earlier conversations about what secure looks like.
And that probably also means that if you aren't already provisioning full kind of environments for your developers to work in, that sounds like a great place to start so that they know like, oh, this is what a secure.
coding environment for my org looks like, right?
Absolutely.
I was a software developer longer than I've worked in security.
So in July is 29 years in IT for me, and I programmed for years before that.
And so I was a dev way longer than I worked in security still.
And it's funny, Andrew, because sometimes the security team will be like, are you one of them or one of us?
And I'm like, I'm one of them, I'm sorry.
I'm just a really security obsessed dev.
And I did like so I find that like I can be a little more compromising than some other security people because I'm just like I don't want to die.
You're realistic.
You're being pragmatic.
Yeah, because then I get more of what I want.
Because if you die on every hill, guess what?
You're going to they're just going to go around you all the time.
Software developers are like water.
I don't know if you've ever had water damage at your home, but water can just go around everything.
Right.
And so when the software.
When a software developer obeys policy, it's because they're being obedient and a well-behaved employee, not because they damn well have to.
They can go around any technical control we give them if they really want to.
And so if you die on every hill, like, first of all, you're going to be dead every day.
You're going to have terrible relationships and you're not going to get a lot of what you want.
And if you can be more reasonable and just look at, like, this is legitimate business risk or this isn't.
Like the hardest part was just learning how to communicate clearly.
And I still sometimes struggle with explaining it in a way where everyone gets what I'm saying.
But once I could do that, I got way more of what I wanted.
And sometimes I'm talking to the security team and explaining like, listen, I know that the standard is TLS 1.3 and they're doing 1.2.
But like our little, you know, static web page, no one cares.
No one cares.
A nation state would be required.
So before Mythos was released, a nation state level effort would be required to break this encryption for what?
Our website's public.
No one cares.
No one cares.
Calm down.
Calm down.
Anyway, sorry.
I love that.
It's what you just said a moment ago about engineers being water.
I could not agree with that.
I'm going to go back to something that was said on the show way back.
Maybe almost over a year and a half ago, we had Tara Hernandez from MongoDB, and we were hosting an event in San Francisco.
She's on the stage with Rob Zuber, CTO of CircleCI.
We're talking about making development easier in an agentic world, and she said something that really stuck with me.
Make the golden path the easy path.
They were talking about the realm of developer experience and how to ship things while using like, oh, the tooling and like the processes that you want.
But security is one of those processes.
And so if you create.
friction in your security adoption within your org, engineers are going to flow around you.
You might as well have a pool in your attic, right?
And so it's not going to work out well and you're not going to have visibility.
We all know about shadow IT, shadow AI, shadow everything.
Developers love a shadow.
And so...
You're not going to win that war.
What you do have to do, though, is understand why they're flowing around what you want.
Why is what you want different from what they want?
Because secretly, it's not.
It's just that you're talking past each other.
So if you're in a situation where like, oh, we've set up this tool, we've set up this golden path, we want everyone to go through this review and then do it like this and submit it here, and you find no one's doing it.
Well, is it a visibility problem?
Is it an unnecessary friction?
Is it something you introduced without asking them what they were even doing or doing discovery on what you would need to do to meet them where they're at?
Being told to do something is really different from being partnered up with on how we're going to build something more secure.
Is that a mindset difference that you see at companies that are more successful with their security?
Oh, absolutely.
Absolutely.
I've been writing this blog series called The Psychology of Bad Code.
And I did a talk on it.
And now, you know, when you blog, you can just be as nerdy as you want because there's no time limit, right?
Isn't it great?
I know.
And basically, I had read all these behavioral economic books, which is the reason why people make the decisions they do, and then interventions of things we can do to help them choose the happy path.
So not social engineering, where you make people have fear, you put pressure, you manipulate.
This is more about...
presenting everything in a different way to help them make the right choice.
So for instance, in Canada, if you're an organ donor, you have to go and sign up to be an organ donor.
But in other countries, you're an organ donor by default.
Well, guess what?
90 plus percent of people are organ donors and the few that don't want to opt out.
Where in Canada, you have to opt in and a very small percentage of us are organ donors.
And I think that sucks as a person that's an organ donor.
And so if we can re-architect.
The way the systems are so that we guide them like with secure defaults, with policies, with culture and all these things so that, like you said, the happy path is the secure path.
And so these behavioral economic interventions, essentially, they've done all these scientific experiments to prove that when you do it this way, you get more of what you want.
And then if a developer doesn't do it, they're making an active decision not to.
And most of the time.
It's because there's a business requirement or there's some sort of incentive that's making them do that.
Right.
And so one of the things I talk about is perverse incentives where we're like, we take security seriously.
But then you're given zero time to fix bugs.
The projects have no time to like do the secure code review or the threat model or any of the things.
And it's not even on the schedule or in the project charter.
And then you only get promoted or get raises when you release features.
Well, actually, we don't take security seriously.
In fact, it sounds like security is pretty damn optional when you look at how we're incentivizing developers at a lot of places.
And so I'm trying to give people as many ideas as I can so that they can make the incentives, bring people where they want them to go or set up the defaults or whatever.
I think I'm on blog post number six now.
And I'm going to do...
10 different ideas.
And then I give many, many examples for each one.
So I think I just did one on documentation and like how to get people to actually write the documentation they're supposed to.
Because when we have no documentation, Andrew, and then there's a security incident, it sucks even more than it needs to.
You don't even know where to start.
It was like, what do you mean?
I didn't write this code.
I didn't review this code.
I didn't even write docs or read those docs on the code.
Like, what do you mean docs?
And we're getting really abstracted away from the stuff we're building.
But, you know.
You're reminding us, Tanya, that security is a practice and it's a responsibility of everybody within an organization.
It's not just a product you can buy or a checkbox that you can check.
And, you know, the work that you're doing at She Hacks Purple and OWASP, it's transforming how folks are able to build securely.
I think that everything we talked about today is only going to become more important.
And why do I think that?
Well, because last time we talked, everything we've talked about since has come true and has only become more important.
So I just know that we're going to have to have you back again in the future to do another check-in on security and the world.
But in the meantime, you're shipping a lot of stuff that's helping teams ship and learn how to build securely.
It looks like there's a lot of resources and entry points for folks to come into your world and figure out how they can become more secure coders.
So where do you think folks should go to start learning about you or otherwise engage with some of the stuff that you talked about?
If you want a list of literally everything, go to newsletter.
dot she hacks purple dot cam once a month i will give you all the content i created i'll send you little presents like the ai prompt library which i sent out last month um you'll get all the events i'm doing the podcast every single thing that i do each month plus you get a silly meme oh well i love the silly memes sign me up and so i'm going to be on the email list And I hope to see our listeners there as well.
And we're going to include all these links in the show notes so that you can go and become a more secure coder yourself.
And Tanya, thanks again for coming on Dev Interrupted.
It was a blast to talk with the Queen of Purple and cover all things security in the last year.
Thanks again.
Oh my gosh, Andrew, it's always a pleasure with you.
See you next time.