Making the OWASP top ten in the vibe code era​​​​‌‍​‍​‍‌‍‌​‍‌‍‍‌‌‍‌‌‍‍‌‌‍‍​‍​‍​‍‍​‍​‍‌​‌‍​‌‌‍‍‌‍‍‌‌‌​‌‍‌​‍‍‌‍‍‌‌‍​‍​‍​‍​​‍​‍‌‍‍​‌​‍‌‍‌‌‌‍‌‍​‍​‍​‍‍​‍​‍‌‍‍​‌‌​‌‌​‌​​‌​​‍‍​‍​‍‌‍​‌‍‌‌​​‍‍‌​‌‌​‌‍​‌‌‍​‌‍‍‌‍‌‌‍‌‍‌‌‌​‍‌‍‌‍‌‍​‌‍‌‌​‍‍‌‍​‌‍​‍‌‍‍‌‌‍‍‌‌​‌‍‌‌‌‍‍‌‌​​‍‌‍‌‌‌‍‌​‌‍‍‌‌‌​​‍‌‍‌‌‍‌‍‌​‌‍‌‌​‌‌​​‌​‍‌‍‌‌‌​‌‍‌‌‌‍‍‌‌​‌‍​‌‌‌​‌‍‍‌‌‍‌‍‍​‍‌‍‍‌‌‍‌​​‌​‍​‌‍​‌​​​‌‍​‍‌​‌‍‌‍​‍​‌​​‍‌​‍​​​‌‌‍‌‍​​​‍‌​‌​‌‍‌‌​‌‌‌‍‌‌​‍‌‌‍​‌​​​‌‍​‌‍​‍​‍

Making the OWASP top ten in the vibe code era - Stack Overflow

June 5, 2026

Making the OWASP top ten in the vibe code era

Ryan welcomes back Tanya Janca, now part of the OWASP Top 10 team, to discuss what changed in the latest OWASP Top 10 release, how the list shifted from “outdated components” to a broader software supply chain focus, and why they added memory safety and vibe-coding as awareness items.

[

The OWASP Top 10 for 2025 is the latest standard awareness document for developers and web application security that represents a broad consensus about the most critical security risks to web applications.

Learn more about Tanya’s work at her website and her new podcast DevSec Station . You can learn how to prompt your AI for secure code with her prompt library .

Read Tanya’s articles on our blog.

Congrats to Populist badge winner Rob Kielty for winning the badge on their answer to How can I tell IntelliJ's "Find in Files" to ignore generated files? .

TRANSCRIPT

[intro music]

Ryan Donovan: Hello, everyone, and welcome to the Stack Overflow podcast, a place to talk all things software and technology. I am your host, Ryan Donovan, and today we are talking about the OWASP Top 10, or Top 13, as it may be. And my guest for that is a returning customer, Tanya Janka. Hello.

Tanya Janka: Hi, Ryan. Thank you so much for having me back.

RD: It's always a pleasure. So last we talked, you were doing your security work, but now you are part of the OWASP team. Can you tell us a little bit about how that came about?

TJ: Yeah, absolutely. So I've run a chapter before. I've run a project before. And basically, OWASP was like, what are you going to do next for us? Because of course, I'm going to do something. And there was a bunch of different projects that I met with to talk about joining which one. And then I don't know if you know Star Brown, but she is head of projects at OWASP. So she's a staff member, and she's pretty great. And she said the top 10 team kind of needs to be dragged across the finish line. And you are like a person that gets things done. And, you know, you love OWASP. They love OWASP. Like, what if I made an intro? So I met with Andrew Vanderstock, who's the executive director, but also is on the top 10 team. And he's like, Tanya, all of us have 400 things going on. And we're a bunch of wild cats and we need some herding. Do you feel like herding cats? I'm like, AppSec cats? That sounds great! And so we met and we had one meeting and basically, I took notes. These are your action items. This is what we're doing. I'll see you next week. And then the next week, Neil's like, can we just tell you how much we love you? Why did you not join our group like 10 years ago? I'm like, I don't know. I guess I was doing some other silly project. We get along so great.

RD: Silly projects like the Canadian election security, right?

TJ: Yeah. Yeah. Silly projects like that. Like trying to make the first secure coding law in Canada that I'm currently working on.

RD: The OWASP, in general, when I found it, it's an amazing resource for what is considered the vulnerabilities du jour, right? Every year you have the top 10. This year, what's different? What's shifted for the top 10?

TJ: So we actually only do the OWASP top 10 every three years, which sucks. It's because it's so hard to get data. So data aside, what changed? two big things changed essentially. So one, we got to take some stuff off the list, which was great. So cross-site scripting used to be its own item on the list, server-side request forgery, cross-site request forgery. Various individual vulnerabilities used to be on the list. And we did such a good job of promoting that it was an issue that the industry responded and it fell off the list, which brings me great joy. But the two really big changes are we changed using outdated and vulnerable components to the entire software supply chain. So your IDE, your CI, your code repository, every single thing that you use to maintain or create a piece of software, all of that is part of your supply chain. And if it's being attacked, we're in trouble. Right. So I was like, listen, I know we don't have the data to fully support this. So let's ask the community what they think. And across the board, 100% of them are like, this needs to be on the list. So we're like, we are correct. If hundreds and hundreds of community members agree, then it's probably good. And then the other one is mishandling of exceptional conditions. So originally when we looked at it, poor code quality was, and I was like, no, poor code quality, that's all of them. That's everything. And I was like, let's be quite blunt. What is the remediation of poor code quality? What if you tried sucking less? Have you tried not sucking? That's completely unconstructive and totally unhelpful. So I was like, that is an unacceptable bucket. Now we're going to break things down further. What do we see? And so we had lack of application resilience. So your app does not know how to get back up or stay up versus mishandling of exceptional conditions, which means your error handling is not right. So something's happening and you are just doing a poor job of reacting and responding and/or preventing it in the first place. And they tied. Like the numbers were almost exactly– I think it was off by two or something. It was so close. Like when you have millions and millions of results. And I was like, listen, if we resolve mishandling of exceptional conditions, we solve almost all of application resiliency. But if we just do application resiliency, it does nothing for mishandling of exceptional conditions. And we're only allowed to put 10 things on the top 10. I want to fight for the one that is going to solve two issues. And they're like, you know what? It's like a pretty reasonable answer. And then we started writing and writing and I've written books and I used to be a songwriter and I love writing. So I did a lot of the writing where Brian did a lot of the, like all of the data. And then Neil did the website and the releasing and the publishing. And, you know, you all sort of like team different things, right?

RD: Yeah, yeah. There's a bunch of stuff I want to get to before we get to that. So you talked about the difficulty of getting data and the data that you gather. What is the data and how do you gather it?

TJ: This is the best question ever. So for everyone listening, next time, I want your data. Basically, what people are willing to share with us is generally we have a whole bunch of cool like pen tester boutique shops that will share their anonymized reports with us. And then we have a whole bunch of vendors that make static analysis or dynamic analysis tools, and they'll share their data with us. What we do is we look at CWEs, so common weakness enumerators, which is like a pattern, like injection is a pattern that is covered by that, versus not using CVEs, which is common vulnerability enumerator, which is a specific individual vulnerability in a product. So if you are… sillily running Windows Server 2018 R2 Service Pack, blah, blah, and so am I, we have the same exact vulnerability, right? So we want to look at patterns because we're looking at custom software and each piece of custom software is a beautiful snowflake. The data that I really, really want, like the Spice Girls, is I would love to see postmortem reports because then we could have the supply chain information, right? Then we could have the vibe coding and all the other types of things of how this actually happened because injection is a problem still, and it's still on the top 10 because it still sucks very badly. But how did that injection happen? Did a software developer write that code? Did an AI assistant write that code? Did they copy it from our favorite forum in the entire world? Where did they get this? Is the injection actually part of a third party dependency that they installed, and maybe that dependency was intentionally malicious, right? Like how did that injection actually happen? Because not a lot of developers are doing SQL injection anymore. Like pretty much all of them know better. And so the data that we got versus the data that we desire to have. So next time we do a data call. I'm going to do some begging. We'll see how it goes. Because Brian got most of the data. I only brought in around 2 million records. So I brought in like two or three vendors at the last minute. Well, compared to what Brian got. But I only joined the project in– so we talked about in July, and I think we had our first meeting in September, and we released in December. That's pretty fast for a three-year iteration. But could you imagine, like, an organization where you did software development saying, hey, can we have all your postmortem reports from your security incidents? They're like, no, you may not.

RD: Sure. And I know that for certain breaches, companies have to disclose it. And a lot of people do just postmortem reports anyway. Are those helpful? Because I remember when I first looked at a WASP, it had a huge list of CVEs and I was like, wow, that's pretty thorough.

TJ: Yes and no. So I was at a conference called Snowfrog last week in Denver, and I gave this talk. Partway through, I was like, okay, so it's an AppSec conference, so almost everyone works in application security. I was like, who here is having software security incidents? And maybe a third of them put up their hand. And I was like, okay, so for the rest of you that are having incidents and don't know, let's talk about that. Because if you have software on the internet, I assure you, you are being attacked. And a lot of people just don't even know what to look for. They're not even aware that it's occurring. And so here I am asking not only that you are able to notice, but that you are capable of responding and that you actually have the time and the energy to do a postmortem and write that report up for me and then share it in an anonymized version. Like when I help people with their– because I do consulting, blah, blah, blah, right? I'll work with their AppSec programs and I'm like, you know, let's get some metrics on the incidents you've had. And most of them, they don't have anything like that. They don't know that, you know, we've had this many incidents and this percentage was AppSec and that's how much it cost us. And this is how many hours it took us. And this is, you know, what we're looking at and why it's worth investing in our program. Like most of them just have their hair on fire.

RD: The preemptive security stuff is still a little distant, isn't it?

TJ: Because what I care about, Ryan, is not what a stupid scanner finds. What I care about is what is getting in, like what is being attacked more often and what is working with these attacks. Unfortunately, we're not really getting a lot of data on that. Like when we look at, for instance, the Verizon breach report or the breach report annual from CrowdStrike, there's a couple other people that released some. And thank you to Mandiant as well. Like there's a bunch of companies that are doing really cool work in that space. But even just the way that they're reporting it, sometimes in my brain, it's different. So like they're talking a lot the past two or three years, oh, there was this giant supply chain attack. But when I look at it, I'm like, they compromised a software developer. They compromised a person. And then that broke open multiple parts of the supply chain. That wasn't an attack against the supply chain. That was against a human being, an extremely privileged, powerful human being. So I don't know.

RD: I mean, I've talked to security folks like that does seem like the weakest part of a security system is the people, right? Those are the cheapest attacks to do.

TJ: And we're not protecting them. Ryan, we are not protecting software developers. Almost every time I go give training at a company, I'm like, how many people have had any sort of secure coding training before? No hands. Like every time. Unless I've already been there and I'm coming back. And then we're like. Why is this happening? I'm like, why do you think? We have this giant attack surface that we're like, la, la, la, it does not exist.

RD: Right, right. So I want to talk about the supply chain attacks. I think this encompasses a lot now. It used to be just like, update your software. But now everybody has so many dependencies, so many files from NPM. How bad are those?

TJ: So the answer used to be, do auto update. Now the answer is please don't do auto update.

RD: I know that there's other folks, like Dino has the JSR, I think, that has some sort of verification. Are there other ones like that that have good security, good controls? And what are the good controls there?

TJ: There are options like .NET, where there's a giant company behind it, and they have a security program, and they're trying to do the thing, right? And then we have volunteers. for NPM and other organizations. And those volunteers are doing a lot of work. They're working very hard. They're being diligent. I am not insulting their work. But the system, the way it's set up, it's not set up in a way where they are capable of succeeding. Does that make sense? Like they don't have a security team that is on it full time that is hired to do this work, as far as I know. I'd love to be corrected on that. What would a best practice be? So I would ideally... every time you open up some code, I would want to update as many dependencies as I can in dev to the point where they're seven days or older. Why? Because if something is malicious intentionally, we usually catch it in the first seven days and it gets pulled out of wherever the place is. So if you can set for seven days or older, that would be good. Then I want you to do all the tests and make sure you love it and it's got all the stuff you want, then pin it. Right? And if you can have a lock file and check that lock file in, that'd be great too to your code repo. And then promote up the chain with that pin so it doesn't accidentally get switched out for something else that is a surprise. Because we don't like surprises as security nerds. We're anti-surprise party. And then ideally you would run something called a software composition analysis tool and have it set with reachability. So reachability means, so first of all, they'll tell you you have 20 dependencies. Ha ha ha, like the number would be that low. And those dependencies have dependencies who have friends, who have roommates, who have other friends.

RD: They call two people.

TJ: Right, exactly. And then it'll say, you know, these ones have vulnerabilities. However, the actual vulnerability is reachable from within your code path. So the way you call it goes down in such a way that eventually you get to the part of the code in the dependency that has the problem. So I would fix those ones for sure right away, right? Don't release code that you know has a big problem in it. That would be ideal. And then there's also a newer type of company. And there's a bunch of them. And I kind of don't want to name drop because I don't want to promote any specific companies, but basically where they do dependency health. And so they'll say like, yes, this dependency was updated two weeks ago, but it only has one maintainer and that guy lives in North Korea. How do you feel about this dependency? Right. And it's like, maybe I want a different dependency or we haven't found any vulnerabilities in it, but it hasn't been updated in four years and it has no maintainer. Well, I don't think that dependency seems very healthy either. That is a new type of tool. And we don't have a magical acronym name for that type of tool yet. So just dependency health, if you're going to look it up. I mean, if we could run one of those two once in a while and take a look at those results and see how we feel about the dependencies we've chosen, that would be helpful. And then between those two vendors, they will tell us if they notice something, it has become malicious, like the polyfill situation. Like there's so many, right? Where it was a legit dependency and then it wasn't.

RD: Yeah, because of– maybe it was the XZ one where it was just one maintainer who burned out and basically gave it away to a bad actor.

TJ: Well, that bad actor, that person was volunteering on the project for two years, building trust. And then they said, hey, can I step down? Which is normal when you volunteer somewhere. I remember I used to run a nonprofit and I stepped off the board. And the moment I stepped off the board, like the organization essentially collapsed. Like there was some sort of weird, well, “I want to be the leader, I want to be the leader” arguments amongst them. And it collapsed within like a month. After me running it for years, which was quite disappointing, as you can imagine. And so when you hand over the reins to something, to a volunteer that has been volunteering for you for years and you think is great and you think you know them, and then they go and you're like, wow, this whole time you were waiting to do that. Wow. The patience involved as a person that has personally experienced this. Like not with code, but still, right? Like where you see this giant change. And so I feel like I don't know how you would know. Because I've also had open source projects where people came and volunteered and then they're just like, great. Either usually I find they're great or they show up, they do one or two bug fixes for you, then they just disappear on you. And so that's generally what we can expect is either they're going to show up and be great or they're going to show up and then they're going to disappear because they get busy. And that's usually the worst case is like, oh, they did five bug fixes. And then I haven't seen them for six months.

RD: You know, I've seen companies that do the sort of supply chain health and will adopt abandoned open source projects to make sure that they're secure. And it seems like with the sort of .NET example, like one of the solutions for this security issue is to have money on the line, right?

TJ: Yes. Well, quite frankly, we as an industry are building production products that people's lives literally depend on sometimes with hobbyist work. And then we're upset when it's not professional quality. When Log4J happened, people were giving those, I think there were three maintainers, they were giving them such crap. I'm like, those guys have dishes to do. They have kids. They have a partner that might be like, hey, I haven't seen you in three days. What's going on? This is their hobby. And then people were pooping on them. I'm like, no, no, no, no, no. They're not getting paid for this. And also, did you volunteer to do a security review of their code? No, you didn't. Did you give money to their project so they could afford to have a pen test? No, you didn't.

TJ: So speaking of security reviews of code, recently the Anthropics Mythos came out and was finding wild bugs everywhere, including in OpenBSD, I think, a 30-year-old bug.

TJ: And OpenSSL as well.

RD: Oh, really? Another one.

TJ: I think they had seven heart bleed level vulnerabilities in OpenSSL.

RD: What does that tell you about the sort of security level for these projects that everybody depends on?

TJ: So I teach secure coding and we review code together and most code is garbage. It does the thing, but from a security perspective, that's not what we were taught. Like I went to college in the 90s. I graduated in 2000 and they taught me, Ryan, that I should save all the secrets of my code. And I should not only save the production secret, but every single level. So the dev environment and the Q8, so that we could compromise every level of the system so that we wouldn't lose it. And that was the best practice. That's what I was taught. And so most of these people have never had training. Even if they just got out of college or university, there was no secure coding training. And then they're working on this, especially the free projects. There's no security team, right? And people are like, well, why don't the security people volunteer? I'm like, because there's so much paid work to do. We can literally never finish it. I would never go to bed. When I switched from development to software security, I went from having all my work done each day and inbox zero almost every single day to it doesn't matter how late I stay. I'll never finish the work just from today, ever. I actually stayed overnight several times at work when I was doing security for incidents and stuff like that. And you will never, ever finish the work just in an enterprise. How would I have time to go secure a whole bunch of open source projects? No, I don't have time for that. And why would I do it when I could be paid a small fortune to do it for a company, right? Why would I do that? I like money. I know it doesn't seem like it because I do so much work for free because I am always doing community work and stuff. I know it seems like maybe I hate money, but I do kind of like it.

RD: Well, yeah, yeah. I mean, not enough to do the, you know.

TJ: To only do paid work.

RD: Only do it for the money. The Mythos announcement sort of says on the other side, like, yeah, all code is garbage, but maybe all the hackers are garbage too, right? Like, these bugs sat around for years. Yeah, I mean, or maybe people have been getting in and not being caught.

TJ: So one thing is that mythos is looking in a different way because it's not a human. It's looking not like a human. It's looking from a different perspective, right? So there's that. Just like how my threat model is different than your threat model. Like if someone knocks on your door in the middle of the night, you're like, some jerk woke me up where I'm like, oh my gosh, I'm going to be murdered, right? Like we have different threat models. But then I also think that we just haven't had time to examine every single thing. So a hacker. Why are they looking at OpenBSD? What purpose would they be doing? Did someone pay them to do a thorough code review or not? Because like when I was at Elections Canada, we paid someone to come and do a code review and we fixed everything. Then we paid someone to come and do a pen test and we fixed everything. Then we paid someone else to come and do a code review. And that dude found a ton of stuff. And then we paid for another pen test and we fixed every single thing that that person found. And then election day was actually super boring, which was great. Nothing happened and we were not in the news and it was just lovely. I feel like there's probably still bugs in there somewhere because we only had four opinions. Do you know what I mean? And there's just so many opinions we could have. And also, did FreeBSD have a full-time security team? And what other things were the security team doing? And so I feel like… there’s this lady named Katie Paxton Fear who I had on my podcast years ago and then now we're friends and she totally tolerates me. And she pen tests APIs. That's her jam. And she said 100% of APIs she's ever tested. She has had an access controller, broken authorization problem. 100% throughout her career. She's never not found it no matter what. And she's good, but like... is she the best in the world? Who knows, right? But she finds it every single time. And so we're not doing a great job. And I have lots of ideas on what we could do. I think we need to find a new way to do this. Maybe security controls shouldn't be rewritten by every single team, right? We buy identity products. Why don't we have authorization products? Why don't we have input control products? Why don't we have error handling products so that we actually know a security incident is happening?

RD: I think there are access control and auth products out there, but I think it's very easy for a team to write their own OAuth implementation.

TJ: It's very easy for them to write one. I don't know if it's very easy for them to write one perfectly.

RD: No, of course not. But you just implemented it. Why would you pay for that?

TJ: And then on top of this, we have people that are using AI to help them. And Ryan, this is kind of embarrassing, but I usually do my trainings in– I do a lot of JavaScript and Python because that's really popular, but I will redo all the examples into another language for clients. So this client was like, we want Java Spring Boot. I'm like, that's cool. That's cool. Because Spring Boot has like tons of really cool stuff in it. So I'm like, this is great. I can show off all the cool features. This is awesome. So I had 80 examples. And I got the AI to switch them over to the new language. Oh, so I started reading them and started reviewing them and I ran out of time. I didn't get to all 80. So we get to like number 64 and we're reviewing the code and we're reading it. And it decided to remove all of my error handling altogether for my best– my beautiful error handling gone. And it changed it so that the global exception handler caught every error and then just spat the stack trace onto the screen like a jerk. And I was like, this is– ah! And so I was like so embarrassed in front of the client. They're like, why would you do that? Didn't you just tell us not to do that? I'm like, I'm embarrassed. I'm sorry. I coded this example. And I'm like, I suck so bad. And so like if I could run out of time and like I can read the code and I can see it's wrong.

RD: Sure.

TJ: Like I looked at it and was like, no, no, no, please don't do this. This is a bad example. This is not the best example. But what about someone that doesn't know?

RD: What about mishandling exceptional conditions, right? Is a… try catch and then log it, is that not enough?

TJ: So sometimes when I review code, I'll see try, and then the person does something, and then catch, and then there's nothing. And then end. So first of all, if you're going to catch an error, handle it. Do something about it. Roll back your transaction and start again. Feel closed. Do not feel open. Don't try to fix a transaction halfway through. Please don't do that. No, no, no, no. Roll back to the very beginning of the thing you're doing and start again. If they're halfway logged in, they are not logged in. You're halfway through transferring that money. Nope, nope, nope. You stop everything. You roll all things back. You begin again. And we log it. And we need to log, you know, a timestamp, we need to log what they're trying to do. We need to log if they succeeded or they failed. So whether they fail or succeed, I want a log. Any security control, input validation, output encoding, anything that's security related, I want a log. So it's like they tried to log in, failed, tried to log in, failed, tried to log in, failed, tried to log in, got in. Okay, that's normal. That's normal. But what if they tried to log in 300 times and it was only one second? That's not normal, right? So what if it triggers an alert? After certain points, like this kind of feels brute forcey, kind of feels like a bot, not very human-ish. Maybe I should say something.

RD: Well, I think, you know, a lot of people will, you know, put in a try catch to get it to stop warning them all the time. But for, you know, what you're saying is like a lot of people won't put those in until they're bit.

TJ: I agree with that as well. If we are not catching our errors– so first of all, we're professionals. We want to make beautiful, amazing, reliable software. We want to make high quality software. And if your software crashes, I think we all generally agree that kind of sucks and that's not high quality. And then we want it to be safe and secure and robust and tough and rugged. And if it falls down every time, like if it trips a little bit and it just falls on its face, then again, that's not good. So error handling is where malicious actors like to hang out. So one of the tools of the trade of pen testers and also malicious actors is fuzzing. And that's where basically this automated tool just starts putting junk into every single input it possibly can. It starts with the letter A. And it's like, great, would you like 50 A's? Would you like 5,000 A's? Would you like 50,000 of the letter A? And it just starts crap, like shellcode, everything it can think of, special characters, and it sees what sticks. And the moment the error message is different. Or the amount of time it takes is different. Or the behavior of the app comes back different. It's like, oh, yeah. I'm going to now tell whoever's operating me, go poke there. Go dig in there. And then that's where the high-paid pen testers, security researchers, those people with that beautifully curious mind starts digging in there. And then they're like, ha-ha, I just did this. And they turn it into something. That is the mishandling of the exceptional condition. And this is where a lot of security incidents end up. So we don't catch it. We don't warn. The person continues, continues to find things until eventually they're in because we just didn't even know that they've been digging away at us for like six months.

RD: So you also mentioned that there's a baker's dozen this year. You mentioned the tie. So there was two extras after that. What's our two extras?

TJ: Yes. So the two extras are– so one is memory safety. Memory safety is a big issue. I don't know if you saw the article by Mozilla. They rewrote Firefox into Rust, I believe, because it's memory safe. And the number of bug bounty submissions, it basically solved 76 or 74% of all of their bugs. By doing that, that's pretty painful, right?

RD: That's a lot.

TJ: Yeah. Memory safety is a really big deal. Having to manually handle and manage all your memory, it's very complex. People get it wrong a lot. I'm teaching a lot of Secure C++ this year. And that is a huge part of the fun we get to have together is: how do I do this properly? How do I not get burned by this, right? Like off by one, dangling pointers, all the fun stuff. We felt that even though the OWASP top 10 risks to web apps is web-focused and memory safety is not a huge thing on the web, it's still just so fundamentally important. And a lot of people tend to think of our list as for all applications, and we really want to raise awareness about it. And then the 13th one, we had a lot of talks about this. It is really fun and a pleasure to be able to have a technical debate with such brilliant, knowledgeable people who have worked in the field even longer than me, who care just as much as me, who ferociously want to solve this problem, right? And I was like, vibe coding is going to kill us all. This has to be something we talk about. And they're like, there is literally zero data in our data set that supports this.

RD: How old is the data set though, right?

TJ: So the data set, we got most of it in 2025. I think we got a little of it in late 2024. But even if we didn't, we know what's wrong.

RD: We've seen the Twitter threads, right?

TJ: Yeah. There's many papers that show that it's insecure. Just me making my training examples. I do this bad, better, best thing. And I just ask it, make a login form that does this. And it does every bad thing I wished that it would do generally. Now it has improved. Now sometimes. Once in a while, I have to remove a security control for the bad example, but rarely. It's usually crap to begin with. And because it's trained on not good data. And so we talked about it and I was like, listen, the purpose of this document is to raise awareness. Do you think this is– and they're all like, yes, obviously it's a problem. And I'm like, we're not trying to make it one of the 10. We're not saying that we have data. Like, we'll just say blatantly there isn't data support this, but we know it's a problem. And I want to give best practices as of what we know now that people should do. And so eventually they gave in to all of my whining. I don't know if you remember the OWASP top 10 in 2017, but there was a lot of community pushback and they actually had to redo the list and throw someone off the team because basically one of the examples happened to be the solution was buy his product. That's not what was written, but it described exactly what his brand new product did, right? And it was very direct and clear what the solution was. And the community really pushed back and they're like, you don't have data to support this. We feel that this is vendor interference. This is not acceptable to us as a community. And so they were really nervous about how it would go. But I'm like, let's just be transparent. We know we don't have the data. We'll just say exactly that.

RD: And there's no specific product that solves the vibe coding issue, right?

TJ: Not yet.

RD: I mean, people are trying to get security AI or fix it, but yeah, it's a large problem.

TJ: I have some ideas that I'm going to work on later this year and see if I can come up with some things. I have something to offer on this. So I write books. So I took my most recent book and I distilled it down into a secure coding guideline, which is at securecodingguideline.com. And so I was telling people, take that and turn it into prompts. And people were like, do it for me. So now I've done it for you. So if you go to securemyvibe.ca , you can get AI secure coding prompts that I made from boiling down my entire book. And essentially, the first one is just one that you put in your memory every time that just applies my guideline. It's like, you know, these are the things you have to look for. And if it doesn't have those things that redo the code until it has those things, then show it to the user and tell them the security assumptions you've made. Then there's a secure code review prompt. There's a “I'm building a serverless app” prompt. And the idea is like you fill in the blanks. And it helps you show the AI exactly what you want. And it gives security specifications, like requirements, as part of the prompt you deliver. And so it's free if people want to get– so I'm trying hard, but I can't do it all. I need people to ask the AI to make it secure.

RD: You know, you can lead the horse to water, right?

TJ: Splash the water on its face.

[music]

RD: Well, it is that time of the show again, where we shout out somebody who came on to Stack Overflow, dropped a little knowledge, shared some curiosity, and earned themselves a badge. So today, we are shouting out the winner, a very populous badge winner, somebody who dropped an answer that was so good, it outscored the accepted answer by 10 or more points. So congrats to Rob Kielty for answering, how can I tell IntelliJ find-in files to ignore generated files? Curious about that? We'll have the answer for you in the show notes. I am Ryan Donovan. I edit the blog, host the podcast here at Stack Overflow. If you have comments, questions, concerns, topics to cover, email me at podcast@stackoverflow.com. And if you want to reach out to me directly, you can find me on LinkedIn.

TJ: I am Tanya Janka and I give secure coding training. And if you want to find me, just look up She Hacks Purple. That is me everywhere. I just launched a podcast and it is called DevSec station. And it's five to 10 minute little mini lessons on secure coding and supply chain security and whatever is in Tanya's brain right now. So the first season is supply chain security. And so if you're like, I just want a really, really short podcast, that would be mine if you want to check it out.

RD: All right. Thank you for listening, everyone. And we'll talk to you next time.

[outro music]

]