Latest / The MonkCast / Tanya Janca on AI Slop, Vibe Coding, & the Future of AppSec

Transcript

Tanya Janca on AI Slop, Vibe Coding, & the Future of AppSec · The MonkCast

• speaker-0: Hello, my name is Kate Holterhoff. Welcome to another MonkCast episode. My guest today is Tanya Jenka, a security expert and secure coding and AI trainer at SheHacksPurple. Tanya, thanks so much for joining me here to talk about AI Slop and security. speaker-1: Thank you so much for having me, Kate. speaker-0: This is going to be a fantastic conversation. Super excited to chat about all things security with an expert here. So the way that AI has affected security, we can all agree it's tremendous. It's wide reaching. Everybody's seen the repercussions of this and it's only accelerating, right? So this is an in movement thing that's happening to us all. And I'm excited to have an expert on here to help. augment my own understanding of this situation. I guess let's just begin with some introductory information. know, Tanya, can you tell us a little bit about yourself and what it is that you do? speaker-1: Absolutely. I was a software developer for about 17 years, and then I switched over to the dark side, and by that I mean application security. And I wanted to be able to learn as much as I could, and so I started speaking at conferences so that I could get a free ticket. And then before I knew it, I started flying all around the world speaking everywhere because when I was younger, I was also a professional musician and I did acting and comedy as well. ⁓ So like I was in Rolling Stone, I played the Van's Warp Tour, I did a lot of things when I was younger. So when I speak about DevOps, I jump up and down, I get very excited. And so before I knew it, I was speaking everywhere. And so it's been 10 years of me kind of like looping the planet, speaking about security. And so... Basically, one day someone said, hey, could you come and train our devs? Could you talk eight hours instead of one? And I was like, yeah, I could talk forever on this. And so now I own a training company, and I train people how to make more secure code and how to do AI a little more safely. speaker-0: Fantastic. ⁓ my God, what year were you on the Warped Tour? I mean, I attended that. speaker-1: at 2005 and I just did one date. was just in New Mexico because I was a little tiny artist. ⁓ But I mean, I've played guitar a long time. speaker-0: That's... Yes, well, you I hope you bring that up all the time. Appropriate situations and inappropriate because I think that is super cool. Yeah. speaker-1: So if people see me and they want to karaoke with me, the answer is yes. speaker-0: All right, we're going to talk after this. this is ⁓ next time you're in Atlanta, we're doing it. ⁓ Okay, fantastic. So ⁓ I guess let's set the scene here a little bit. ⁓ How would you characterize the security landscape today in our AI and agentic present? speaker-1: I would say it's sort of like ⁓ we're driving a car and we've had about 25 beers and we're going three times the speed limit. That's what I would say of how I would describe the safety right now going on around software development. ⁓ my God. Yeah, basically from what I'm seeing is pretty much everyone is using the AI to write a significant percentage of the code that they release, if not all of it. Most software developers have never had any training on how to review code to make sure it's safe. so some of them are still reviewing it. Lots of them still aren't. And we are releasing code faster than ever before. And the security team had trouble just keeping up with DevOps. And I say that respectfully, because I also, like when I did application security, it is hard to try to keep up. There's one of you, there's 100, 200, 300 of them. And then now they have rocket fuel, right? And then on top of that, the AI was trained on basically the worst code it could be trained on, the internet. You know what's on the internet? My terrible GitHub repo. It's full of intentionally vulnerable things, projects I haven't updated in years, demos, just crap. And it doesn't know Tanya made this insecure on purpose. It doesn't know that I haven't been keeping it up, right? speaker-0: ⁓ my god. speaker-1: It trained on all of these things across the internet where there isn't a security team that is diligently testing and verifying and doing all of the things. And then it thinks that that's normal. And so we taught it, essentially, that security is optional and low priority. So yeah, that's what's happening. speaker-0: Whoa, okay. Well, I love that we're starting in this dark place. I mean, also maybe we could characterize it as like an action movie. We're driving a car at terrible speeds here. ⁓ Okay, you know what? This is what I'm seeing as well. ⁓ So yeah, I'm glad we are on the same page here and that we are going to, I don't know, take this idea of security ⁓ seriously because ⁓ yeah, I feel like the vibe coders out there possibly aren't. So I have been... reading some of your musings on your blog, you have a newsletter, so you do a lot of great exploration for, I guess, what you're seeing in the industry, in addition to advising folks on how they maybe can be better in this situation. ⁓ The framing for that seems to be around the psychology of vibe coding and security ⁓ specifically, at least in some of your most recent posts. I was interested in this concept that you articulated around context collapse. ⁓ Could you talk to us about that? speaker-1: Yeah, so the AI has no idea what we're thinking, right? Even if you are working with the AI for quite a while, it can only remember so much and then it forgets. I don't know, if you've used Clode and had it forgot something that it did for you yesterday and the chat's just gone and you're like, ⁓ crap. And so it doesn't have the context that we have. There's this thing that I remember one of my old bosses, I don't know if he made this up or if this term is universal, but corporate memory. And so we had this woman named Simone that we had worked with and she'd worked there like 20 years. And he's like, hey, corporate memory, get over here. Is this this? Is this that? Because I was a new employee and she just always knew the answer. She was so great. ⁓ And she had all this context about how different pieces worked or why we'd made some major decision or who switched teams and why. And that was a thing I needed to learn when I had just got to that organization. The AI not only does it not have that context in the first place, but it forgets constantly. So it's not like a human that actually has a real memory. And so, you you're asking it to do this, you're asking it to do that, it's doing this, doing and then it's forgetting some of the things as it goes. And your context that you've tried to give it, which is always incomplete, has collapsed. And then it's giving you advice that isn't very secure or necessarily great design advice because it doesn't understand all the other pieces that you're working with. in a way a human being can, right? When you have a senior engineer that's worked somewhere a decade, that person is invaluable, right? Because of the context that is in their head. And I know that some people are trying to build some of these things out with rags servers and knowledge bases and stuff. And I don't know if you saw Mia Jojovich, the famous actress from Resident Evil. opened source. speaker-0: It's really cool. speaker-1: cool ⁓ AI memory thing called a palace. don't know if you've heard of like the memory games that you can do where you build a palace in your head to remember. So she built an AI palace and shared it. So go Mia. ⁓ Yeah. Multi-talented. ⁓ I feel like, so yeah, my blog has definitely been focusing on the psychology of bad code and ways that we can change our environment and our processes so that we can support developers and always making better decisions. But I also released, and I didn't open source it, so it's still under copyright, but I'm giving it away free to the whole world, an AI secure coding prompt library. my most recent book, Alice and Bob Learned Secure Coding, I essentially boiled down the first two-thirds of it into a prompt library that you can use for various different ⁓ things that you're going to do. And ⁓ so I make money by teaching it. So if you want me to implement it with you, that costs money, but you can implement it yourself for free. And so there's a prompt that you can put in your memory so it runs every single time and it applies a significant percentage of my secure coding guideline so that every single time it's generating way more secure code. And then I have, you know, a secure code review prompt. I have a prompt for threat modeling, a prompt for I'm going to build an ⁓ API, and then it gives you essentially all the secure design requirements that I would give a new project team. But it gives it to CLODE, and then there's a few blanks that you have to fill out. like, ⁓ I'm using this technology, I'm using this framework, you know, this is how I plan to connect, et cetera. And so it guides you in setting up your context, and then it gives security requirements. And so I'm trying on both fronts. So on the technical front of giving technical tools, and then also how can we redesign our systems and support our software developers, and just consistently making better decisions. speaker-0: Sounds like a very worthwhile project. ⁓ And is it all right if we put a link to that in our show nuts? speaker-1: Yes, I would love that. So can get the secure coding prompt library at securemyvibe.ca. And it's .ca because I'm Canadian and that's probably the silly accent that you hear. And at some point I will say, a boot and then I will deny it later. speaker-0: All accents welcome. That's great. That's great. I got the flat Midwest thing. No apologies. ⁓ Okay. Amazing. All right. So that helps. I guess to take a step out, what's your general attitude towards vibe coding? I know many of the grumpier developers are kind of like, no vibe coding at all. We hate it. I've written a little bit about AI, ⁓ open source. ⁓ policies for maintainers and whether or not they are permissive or say, know, absolutely no. So, yeah, where do you sit on that? you all about everybody is now a developer and we're all going to be vibing our way into an idyllic future or are you kind of like, let's stop that? speaker-1: So, okay, so first of all, because I am a teacher, I have to teach for a second. And so I define vibe. So there's using an AI to help you code, and then there's vibe coding. And this is my opinion, and I have strong opinions, which is why I write a blog. And all five of my readers agree. I know, I know. I write books and people buy them. So clearly, like, at least there's speaker-0: There's dozens of us! speaker-1: probably six or seven people that agree. anyway. for me, when I say vibe coding, I mean the AI is writing all the code. And we are producing code at a velocity that is completely unheard of. And we have very little time to review. And most of it is under the control of the AI rather than the human. There are lots of people that are using the AI to help them write a function or troubleshoot or do a new feature. And then they are making all of that code their own and changing it. And that is very different than the idea of live coding of, okay, so make me an app that does this and then you press commit, right? I feel that those two are very different. And yeah, so I am absolutely pro using really cool tools to do cool things and use it like I use the AI every single day. I use it for all sorts of silly personal things like, ⁓ so I used to be a professional musician. My voice was really ⁓ out of shape essentially. And so recently I... I got the AI to make me a training plan to work out my voice again. And then last night I was singing Adele, right? And it took like a few weeks to like work my muscles because I'm terrible. I'll just go and sing the terrible song and then have like a really sore voice the next day, like a moron instead of like warming her. So I actually had to spend like three or four weeks warming up before I could start. And I'm still like building the voice back up. And like the AI helped me make a plan where I could do like, you know, 12 minutes per day before I start building stuff out by myself in my apartment. And so I use it all the time for all sorts of things. It's very valuable. Is it as good as a real singing teacher? No. ⁓ But is it way better than what Tanya was gonna do, which was just like make a playlist and sing along till her throat hurt? Yes. And so I feel like we should use amazing tools, but we should also use them safely, right? I would say one of the key problems with AI is for people who are inexperienced. So for instance, because I used to sing before, so I was a professional singer for about 12 years before I took my first singing lesson. And then how everything changed. I didn't know about warming up your voice and how you basically add rocket fuel to every single thing you're doing and everything becomes effortless then. And that could just take eight minutes before practice and everything would change, right? So now that I know that, I behave differently. But if I had asked the AI to make me a plan and I didn't have any of that experience, maybe I would end up with terrible results. And so as a senior engineer and a person who's written code forever, I can look at it and be like, ⁓ actually, no, Claude, I do not want the global exception handler to handle every error in my app. We're going to do proper error handling. Thanks, bud. So I can spot that and I can see that very easily. But a junior developer certainly can't and an intermediate developer, I don't know. It depends on their training and experience, right? And yeah, that's why I'm hoping universities and colleges are going to address that, but I have very low hopes since they already just don't cover security at all. Or they certainly don't cover secure coding despite covering coding. ⁓ So I think absolutely we should use cool, awesome, amazing new technologies. I think it's going to sound really, really lame, that we need to go back to first principles with security for every new technology. So input validation, output encoding, right? So the AI is telling us something. Don't just blindly trust it. Verify. Check it. Read it with your amazing, gorgeous, powerful developer eyes, right? ⁓ If we're going to output something, we're going to take the AI and connect it to something else. Super danger. Super danger connecting two super powerful things. We need to maybe do a threat model and talk about, you know, what could go wrong and what we're going to do about it. And so I feel like if we apply first principles to every new technology, we can do a great job. But what I've seen over and over again, like when we came up with APIs, when we came up with serverless, when we came up with cloud, is we're all so, so, so excited. And I'm excited too, let's be clear. we forget about security and we just rush to production with this cool, beautiful thing we just made that's not actually that gorgeous because it's only pretty on the outside, right? And there's some serious security insecurity on the inside. ⁓ So I feel like absolutely we should use AI all day long. We should just try to be a little safer about it. speaker-0: Okay, okay. And so, you you mentioned junior developers and maybe even, you know, mid-level developers who need this sort of help. So I'm interested in how your, I guess, guess your day-to-day has changed in terms of training then. So, you know, you mentioned your teacher hat. Like, has AI changed what you need to teach or just like how urgently you need to teach it? Like, are the vulnerabilities AI introduces fundamentally different from the ones developers have always made or is it the same OWASP top 10 just like at this crazy volume? speaker-1: both. So I helped write the new OWASP top 10 that came out in December 2025. And all those things are still absolutely happening. And the AI is doing those things quite regularly. The code from the AI has improved drastically since 2022 in Chat Cheapy Tiki. It has drastically improved, but it's still, I would say, below average. speaker-0: So items... speaker-1: if you look at an average software developer. it's still, it's not, and the average software developer is still writing insecure code, right? So I want it to improve. ⁓ I do think that we're creating vulnerability significantly faster than ever before. I think that we have every single person, so you mentioned this in the other question and I didn't address it. Every single person in the organization is now generating apps. That's a serious problem that I see. Security teams, so I'm working with two different companies now to modernize their AppSec program to include AI and like how are they going to secure that. And the ones that I'm working on, we're just working with the development teams, but like I think we need to know what the marketing team is releasing. So there's a few things I think we need to do. I think that, so I'm going to be extremely, extremely biased here, right? I think that we need to have some sort of prompt that runs 100 % of the time that code is generated, period, across the entire organization. doesn't matter if you're a developer or the CEO, this prompt runs and it applies whatever your secure coding standard or guideline is or just use mine. If you want mine, go to securecodingguideline.com. It's free. Or get my prompt library and it'll just do it for you, whatever works for you. But something needs to run every single time. And if you're writing your own, a thing to add to it, which is already in mine, is tell me the security assumptions that you have made, Mr. AI. Because it'll be like, ⁓ but I assume that you're going to take out this ridiculously terrible auth and add your own that's actually production grade. Well, thank you. I assume you're going to do a secret manager and not put all the secrets in the code like I did, right? Winky face. ⁓ So it will then tell you the things. The other thing I think that we need, I think that our traditional or classic or legacy or whatever nice pleasant words you want to use for the current set of AppSec tools. So I know that all of them are like, it's this plus AI. And that's nifty and nice. And I get that if you have spent years making a product that you're not just going to go throw it in the garbage, but we need brand new tools. We need brand new tools that work in a completely different way. I don't want an MCP server that calls an old AST type of AppSec tool that scans the code after I've made it and gives me a list of 400 vulnerabilities that I then need to fix. No one's fixing those. No one has time for that crap. I don't want you to tell me how wrong I am later. I want you to make me right in the first place. And so we need a new set of tools. Just to be clear, I don't think we should throw the old ones in the garbage. What I want to do is have a new tool that clicks into my AI in some sort of way and it forces it to generate significantly higher quality code. And that's what I'm trying to do with the prompts, but the prompts are like level kindergarten of the efforts here of what I want to see. And then we double check with stack analysis, software composition analysis, pen testing, blah, blah, blah, blah, blah, blah, blah. insert your favorite acronym here as a double check. Because right now, you know, everyone's creating things very, very quickly. And people are just not all running those old double classic tools and double checking. So I want to make sure that what they're releasing is not a piece of hot trash. ⁓ And if we could do that where we're generating something that is significantly more secure to start, we'll do better. Because ⁓ Things like Mythos, which for those that are under a rock and don't listen to anything except for this one podcast, and you probably actually already covered it three times because I know your podcast is awesome. So Mythos is a new anthropic release of Clode, or AI model essentially, that specifically finds vulnerabilities. One of my friends worked with it and she said, First of all, you have to create a testing harness. It was actually like several weeks worth of engineering hours. Like was a lot of work to set it up. But then over and over and over and over again, it chained together several vulnerabilities to make actionable, extremely terrifying exploits in minutes. And they've had to do huge amounts of fixes. That's awesome. But like basically every pen tester ever is now using the AI. One of my friends, runs a pen testing company locally here in Victoria, and he went to a CTF and he got the AI to do the capture the flight contest for him. And he's like, I only had to intervene on the very last challenge. it's still, and I finished the whole CTF in something like 27 minutes, where usually it takes a few days. And he did it all by himself without a team. And he just had to help with the last challenge and then he got it. And he's like, and you know, that's not even a super fancy model. I've been training a long time. I've just been training it a few months. And so every pen tester has this rocket fuel now and is finding things faster and deeper and better and differently than ever before. And so we can't be generating even worse code than before. It's just, and we can't, we can't make a backlog that's bigger than we already have. It's just completely unacceptable. So we need something that's generating better code so that every time we fix a bug, it's repairing other bugs that we don't even know about yet. I know have strong feelings and a big imagination and I'm working on it. I'm working on solving these problems, people, but I'm hoping others are working on it too. I know they are. speaker-0: No, this is the real talk I was hoping for. So yeah, please. ⁓ This is great. speaker-1: So many people, Kate, right now, they keep writing me and they're like, hey, we'd like to advise your new startup. And I'm like, awesome, what are you doing? And they're like, we're doing DAST plus AI. We're doing SAS plus AI. No, don't do something old and add AI to it. The people that have already been kicking butt at that have already added AI two years ago to it. So you are reinventing a wheel that's already beautiful, nice, and shiny. Throw that in the garbage. Do some sort of crazy brain, come up with something completely new and super weird. I just want to hear super weird stuff. I do not want to hear about things that already exist, like this is a pen and I added AI to it. I don't care, right? Like we need to think completely outside the box if we're going to solve this problem. We can't just keep doing those same old things we did that never ever worked before. speaker-0: Yeah, yeah. Well, ⁓ to the point of doing things differently, I was very interested in the bug bounty situation. So, Curl got rid of theirs, Hacker One, there's all these ways that bug bounties have been integral to how security is enforced, maybe? I don't know. But it ended up being this sort of like white market as a counter to the black market, which is what we keep hearing about with like, you know, the Vercell breach that ended up with, you know, the shiny hunters thing. you know, so we were hearing about these. ⁓ horrible ⁓ things going on. was NPM had their terrible situation recently. We could just listen to the But ⁓ it seems to me that the bug bounty paradigm is no longer working. Do you have a sense of like, I mean, is that true? Do they have a place? mean, I don't know. What's your stance on bug bounties? speaker-1: One of my friends at DEFCON last year was like, give me your wrist. And then he put a bracelet on it that said, bug bounty is a scam. He's like, I made you a friendship bracelet, Tanya. Well, I feel like, ⁓ so first of all, if a bug bounty is done really, really creatively, like, I don't know if you've heard of Luta Security run by Katie Missouri. So she's the person that invented bug bounties at Microsoft back in the day. So she's pretty darn brilliant. When she runs a bug bounty, she did hack the Pentagon and all of those things. So if you invite brilliant security researchers to take a look at your system after you've already done an extremely thorough AppSec program on it, they will find novel and ingenious ways to find bugs. And that's what a bug bounty was supposed to be. It was also supposed to be, oops, like some person was just using it in some completely weird way and they found a problem and it's a way for them to report it, something that got missed by a real program. It was never meant to be instead of an AppSec program. And so what happened is people in depressed economies found that, you know, if I run Zap or Burp Suite, on these things, I can find one cross-site scripting, I can report it, I can get 500 American dollars, and that's really good pay in some countries. Like, that's a month's salary in some places, right? And so companies were sold this beautiful marketing story of like, we'll do all of this, and then they're paying $500 for something that their staff could find in two seconds. And I've seen that a lot, unfortunately. So what we want is to have a mature AppSec program before we... and we've cleaned up our backlog before we ever consider doing a bug bounty. So, like, for instance, Shopify did a really impressive bug bounty. They had quite the amazing AppSec program. And what they did was is they would pay bounties, and then they would actually fix the Ruby gems themselves for every single person that programs with the Ruby programming language and framework. that, so they have put millions of dollars into securing the Rails framework. and all those gems. And so that's magical and that's, feel, a great use of money and time, right? And contributing back, which is what very, very, very few organizations do. But for the most part, it's like this kind of pyramid scheme sort of thing and like lots and lots and lots of people working for free and not getting paid. And we just hear about the super cool ones that make lots of money, like drug dealers where they have all the cool bling and stuff, but really most people are actually not making a lot of money and are working a lot of hours for free, unfortunately, in some of those systems. So I don't participate in that and very, very rarely ever recommend that as part of an AppSec program that I work on. don't think, like, I think you can do it well. And if I've had clients, I just refer them usually to Luda mostly because I know and trust Katie and like I've seen her work and it's very good. But I feel like now with the AI being able to find, so if you look at Hacker One, like the top several things, they're all AIs, right? And so I feel like this part of the economy is gonna go whenever anyone right now is like, ⁓ I wanna become a pen tester. I'm like, do you? speaker-0: Do you? speaker-1: Because there's certain jobs that I think are going to be replaced by AI. unless you're exceptional, and you don't know you're exceptional when you start. Right? Like when I started as a programmer, I didn't realize that I was doing significantly more work than all of my peers or that I got promoted extremely quickly. was like, I was talking to different CEOs when I was 20 on behalf of my company. was like a big weirdo. Anyway, that's fine. I was writing programs that wrote programs for me so that I didn't have to do boring programs. And my boss was like, what the hell, Tonya? And that's fine, right? And I graduated top of my class and got the awards and I'm that person, right? And that's okay. But lots of people are just normal and all of them need jobs too. And I think that becoming a junior pen tester right now feels pretty hopeless. application security where you work with developers, you build the whole program, you still do testing, but you also do code review and you do this umbrella of many different skills. I don't think that job's going to go away anytime soon. If anything, I think we're going to need to hire twice as many AppSec people because the marketing team just released a new app. And they need someone that can help them do that safely. And what will happen is you're going to be, you know, the expert on running the AI and getting it to do a great pen test, right? And then we're still going to have those brilliant security researchers that look at things in this magical, unique way that still find problems. But I think that everyone's going to use AI going forward, but I think that bug bounties are going to change very drastically. And I think that people are just going to buy their own AI agent instead of doing a whole program. I'm sorry if you run a bug bounty company, can write me hate mail later. speaker-0: Okay, yeah. No, ⁓ the bug bounty thing, we're hearing about it a lot. I actually had Daniel Stenberg come on the podcast to talk a little bit about the curl bug bounty and why he decided to dissolve it. it's very much in flux. I feel like that's possibly uncontroversial. Maybe that's a controversial thing to say. Things have to change. ⁓ speaker-1: Every business is changing. My business is changing. I do not teach a single thing that I taught one year ago. also sometimes I have met with a company, done a sales call. We've started to plan the training and they're like, sorry, we laid everyone off. Canceled. Yeah, more than once. ⁓ And then on top of that, like, you know, I gave a talk at RSA last month and someone put up their hand. They're like, no offense, but why would I even bother paying to train any of my devs right now? when the AI just writes the code anyway, why would I train them in secure coding? And I'm like, because no one is checking what the AI is writing. And they're like, ⁓ there's static analysis. I'm like, you think you can catch a business logic flaw with static analysis? Good luck. Right? Like, we need to teach software developers completely different skills, because their job has completely changed. Right? And so maybe the bug bounty programs will just change and adapt. That's what I'm doing. speaker-0: That makes sense to me. ⁓ I love this framing around just full paradigm shifts of we can't just put a patch on it, we can't try to tape it together with the bailing while chewing gum like we have in the past. These things actually need to change in formative ways. We need to think from the ground up. And actually something that you said, so we kind of talked about DevTools needing to be recreated, that we don't just want to use an MCP server for stitching together to ... legacy tools, if you will. ⁓ So I'm also hearing though that maybe we need to rethink the SDLC. And what made me get there was when you discussed the marketing teams coming out with their own apps. ⁓ So do you imagine, I mean, gosh, there was this big emphasis on like the resurrection of waterfall around spec-driven development and spec-based coding with AI. But it sounds a little bit like maybe we need like AppSec. integrated in more departments. I don't know, ⁓ are you, to simplify my question, which is becoming more of a comment than a question, are you then seeing a future where the SDLC needs to be reinvented as well? speaker-1: That's literally a contract that I signed yesterday. There you go. I'm with the company. ⁓ So I think we need to completely reimagine the system development lifecycle. I think that, ⁓ so in my most recent book, and like that's where I put all my thoughts, right? So sorry I keep referencing it, but chapter five we talk about all the different technologies and how to secure them. And so in the prompt library what I did was I made a prompt for each one. If you're going to build a WebSocket, these are the security requirements I want you to have and fill in the blanks of certain details to give it context. And then it's going to build it in this more secure way because you gave it these requirements. So in the old SDLC, when you did requirements gathering, I would throw that into your basket. there's an API? These are your API requirements. There's a WebSocket, your serverless blah, blah. And so they would start with that from the beginning. Right? And so now, you know, if the marketing team's going to do a whatever, if we can get them to call, you know, if they're using Clode, it's called skills. So it's like, we're building a web app that does these things. Okay. So what are the pieces? So these are the skills that you need to use while you're building that one. Right? And so if we could give them training just to know, they don't have to understand the skills. It's built into it. That's why it's called a skill. Right? But just understanding, ⁓ it's going to have an API. I need to call that API security skill. I need to call whatever it's called underscore security skill. Right? I just need to add that. Or we make a prompt that says, if you're writing code, you do these things. And if the code contains an API, you call this skill. If it's called this, you call this. And that's what we were literally designing yesterday morning together. because there was like a part of the training where we did like a breakout and we just like built skills together because we're nerds and that's what we do. ⁓ Anyway, it was super, super fun ⁓ building things like with people as you're teaching them. It's like really great. Anyway, so if you could do that, then the marketing team doesn't even have to know that. the fact that they like if you can enforce it on them. So some people call this a guardrail, like a technical guardrail. So, know, when you're driving, there's actual guardrails on the side of the road. So I live on Vancouver Island and we have the most dangerous highway in Canada. It's called the Malahat and it's one kilometer up on the cliff on the side of the ocean. So if you fall off it's very bad and we have guardrails. And ⁓ years ago one of my bandmates, not on the Malahat, on a different highway, he fell asleep on the road after one of our gigs and he hit the guardrail and it woke him up. Yeah. I'm so glad he's okay. But now in Canada, we actually have these other little things that we put before you hit the guardrail that go, buh-bum-bum-bum, and make a sound to wake you up before you even hit a guardrail, right? Because we're improving, we're improving, right? And so if we can build these technical guardrails on top of our AI so that if anyone, like the CEO... One of the companies I was working with, the AvSec team, basically took a giant poop there. They pooped their pants, I swear. Because over the weekend, the CEO decided to publish a new website for their whole company because he was frustrated with the marketing team. And he was on a trip and he was like, I missed my flight. And so I was at the airport and I was like, what am I going to do? And I'm like, I'm so angry with the marketing team. I'm just going to build us a new website. And he just published over top. speaker-0: ⁓ no. ⁓ speaker-1: Yeah, and the OpsSec team's like, just have to go change my pants now. And anyway, they ended up rolling back, ended up being okay. And the marketing team and the CEO made up. And there was some improvement. And the security team was like... And yeah, if the CEO did that, but there was a bunch of secure guardrails to make sure that it would be at a maturity level that the security team was okay with, I feel like it could be different. I also think that our publishing needs to have some checks. And that's what the DevSecOps promise was. But what the DevSecOps delivery was, a backlog of like 40,000 critical vulnerabilities that no one wants to talk about. So I think we need to... So there's three things. So one, guardrails on what we're creating so that it's more safe to begin with. Once we publish it, there's a whole bunch of sets of things that test it, make sure it's actually safe, and stops it if it's not. And then once we deploy, another thing that we have been terrible at as an industry this whole time, is we have almost zero observability and response. and detection for custom software. And so while we're at it, while I'm making a wish list, are you listening, startup founders? We need some, I gave a talk last month at Snowfrock and I was like, okay, everyone here, basically everyone's a software developer. They work at an AppSec at that conference. And I was like, so who here, you know, responds to and detects abseq incidents and about you know a quarter or third of people put up their hands. I'm like for everyone whose hands not up I hope your arms just tired because all of you are having security attacks all the time and if you don't know this this talks for you right and then throughout the talk I kept saying okay you know who you are right but I remember interviewing somewhere and I was like, listen, I don't want to do incident response. And they're like, oh, you don't have to. We don't have any incidents. And I'm like, will you put in rating that I don't have to respond to incidents after 5 PM? I was part of my job description. And they're like, really? I'm like, And oh, yeah. They were having incidents. Their data was for sale on the dark web at that. Like, their data was for sale actually on Pastebin. Not even the dark web. god. speaker-0: God speaker-1: Yeah, my first week I reported 26 active incidents and my boss was so pissed and she's like, I feel like you really tricked us in your job interview. And then I did end up responding to incidents but not past 8 p.m. And really I just wanted to make sure I didn't spend the night at the office like I had at my last job. I just wanted to be able to have some sort of life, ⁓ Because I knew that from the interview that they needed some help. speaker-0: Sounds like it. Yeah. Oh my goodness. I mean, asking folks to live in a state of panic is unacceptable. At least one should be compensated well, I'll say that much. Well, so I feel like a thing we've been dancing around is supply chain security. speaker-1: Yeah, absolutely. speaker-0: So, you know, I mentioned breaches. We had the Axios NPM package ⁓ compromised. There was the PRT scan. So that, we could have a laundry list here. what I would like to hear you maybe discuss a little bit is like, do we need to rethink just, you know, the way that we, well, especially with open source, but maybe with everybody, you know, ⁓ what is your read on whether the ⁓ supply chain trust model is working right now? and just to summarize my understanding of at least, is that anyone can open a PR, maintainers of volunteers. All of this we've discussed was fundamentally broken in a lot of ways. And again, maybe we don't have the, I don't know, the solution for this yet, but in this era of cheap, convincing, and AI-generated contributions, where do we stand on supply chain security specifically? speaker-1: So I want to expand the definition of supply chain security to include every single thing that you use or touch or need in order to create and maintain your software until the moment that it is completely decommissioned. And so that includes your code repository, that includes your desktop, that includes the software developer as an employee being attacked directly. I've submitted a paper to Black Hat and DEFCON ⁓ and the AppSec Village as a backup. No offense, Irez. Irez runs it and he's like, if they want to accept it, I'll accept it. I love the AppSec Village. It's the best. But if you can be on the big stage, you want to be on the big stage. And so I'm planning to release a framework of the 19 different attack surfaces that I feel exist. And I've mapped it as a model and then I've created a defense framework. And then I also made a maturity model because I'm anal retentive as a person. ⁓ And so I'm going to release that in three months in August publicly for people to download when I give the talk. ⁓ But when I look at software supply chain security companies, they are doing one of the 19 surfaces in my opinion. And they're doing a pretty good job of that one. And the one that they're all doing, or 98 % of them are doing, is just dependencies. And there's a bunch of different things you want to worry about with dependencies, ⁓ first of which is, is it intentionally malicious? Does it contain known or unknown vulnerabilities? Once I put it into my application, if there is a vulnerability, is there a reachable path from my code such that that vulnerability could execute or not? Because when you do math, you include the math library. But do you do all of math? No, we don't have time to do all of math. So maybe we're just doing geometry, but it's actually in the calculus module, so maybe we're fine, right? So are we using a library that's not safe? If we are using it, are we using it in a safe manner? Is it being auto updated? And then could the maintainer have been taken over? Could it not have integrity? So we uploaded it from the wrong place and got the wrong copy. There's so many different things just in the third party component section of the supply chain. But we need to defend our CI. We have these pipelines that are the most powerful tool that's... Or AI is the most powerful tool that's ever existed in the software development ecosystem, in my opinion. It can go download random things from the internet. build it into your application, then publish your app, like publish infrastructure, up the infrastructure, publish your app on top, boot up your app and connect it to the freaking internet without you touching anything, right? Almost none of those are monitored. Almost no one gets a notification when a new admin is added. Most of them, the runner and the deployer are the same user. And by that I mean the thing that commits the code and then tests it and does all those other things is the same user, if it's compromised, that then releases to production. Right? And we have no alerts on any of this. I was working on a contract because that is what I do. with this lovely company that I worked for many years that they're great people. And it was my first week and we're looking at the CIs and I'm clicking around because obviously, a hacker click, obviously you have to click everywhere. So I click on this guy's name and it said, you know, page one of like 28. And I was like, what? And this one employee had been making new pipelines and setting them to auto run for years. He had 2,800 pipelines that he ran just for fun. was like 20. something thousand dollars per month in cloud bill from this one guy effing around. Yeah, and no one had caught it and no one knew. And so the next day I come into work and I'm like, yo, I wanna meet with that guy and discuss that. And they're like, ⁓ we fired out of him last night. When we brought it up with him, he was like, ⁓ it's just fine. And it's this and that. And when we showed him the bill, he hadn't even thought about it. And like, he was just grossly negligent. And like, we don't even know all the other things this person was doing and like, he's gone. And I was like, ⁓ okay, I probably would have met with him and talked to him a few times before I fired him. But it was my first week, right? speaker-0: Tanya. ⁓ my god. speaker-1: Yeah, exactly. And like they had no idea that that was even happening. And we just found out because I am a curious person and I just have to click on everything and I asked the right questions. because I'm an incident investigator and like that's what you do, right? Is you just like are like, what's this? ⁓ And that's okay, right? But we have these crazy powerful systems. Malicious actors have seen that it is so much easier to compromise one of those. So we used to worry about injection capes. And if you got injection, if you were lucky, you would be able to control that database. If you're extraordinarily lucky, that database was extremely poorly patched and way out of date, and you might be able to get remote code execution, and then you are in their database, you know, like little section of their network, and maybe you could pivot around if you're really, really, really, really, really lucky, right? But now, imagine you attack a software developer themselves. You break open several different parts of the supply chain with one hit. And software developers are human beings and that means we're vulnerable to things like social engineering. We click on links, we receive emails, we also have to remember 35,000 different passwords. And so maybe we wrote one down because we are just humans. We're using the AI and we're trusting the AI and it's telling us you're absolutely right, even if we're not sometimes. Right? And so malicious actors, if you look at The Verizon breach report, the CrowdStrike report, ⁓ Microsoft releases an annual thing as well. And if you're a giant nerd, maybe you read them like me. Anyway, ⁓ so they are calling it a supply chain attack, but when you look at what they call a supply chain attack, I would say about half the time, so maybe a third of the really big breaches that we have had over the past couple years, it was actually a direct attack against an individual software developer that broke up several different parts. of the supply chain and then it was a complete organizational compromise. attack, software developers are an attack surface. They are a target and we need to defend them like very, very carefully. We need to train them. We need to give them tools that protect them. We need to explain why they need to be protected and give them the power to do so. Because they're smart. They're very, very smart. They're better protected than say like my mom who is She was a mathematician, she's a very brilliant woman, but she's not a technologist, right? And so we have lots of smart people out there that don't have the same skill set or power as a software developer. Software developers, they're like superheroes on our networks and our systems, and we need to make sure that they're safe. speaker-0: I like that. That's a great CTA. So before we wrap up though, I do want to hear a little bit about this legislation you're involved with, which is the Canada's petition E-7115. Could you talk a little bit about what that is? speaker-1: Yes. So I worked for the Canadian federal government for almost 14 years when I was younger. I feel very passionate about protecting ⁓ my nation, my fellow citizens, my family. I did counter-terrorism. I quote unquote hacked the prime minister's website and other things when I was part of the government. I ran the election across Canada in 2015. I was the CISO for that. So I did a whole bunch of cool things when I worked for them. I built them a lot and a lot of software. ⁓ And then, but I was very frustrated from the inside. I felt like I couldn't make meaningful change. Like I'd write a policy and then no one would follow it. Right? I would want to talk about security and they'd be like, ⁓ you can't do that. And so I was like, I'm going to leave and haha, joke's on you. I'm going to quit and work for you for free, you losers. Because I'm so smart. ⁓ And so I started writing letters and I started lobbying and I started being in the news and writing blogs and making videos and all these things. to try to make them change and it wasn't working. And so then I found a member of parliament and we started doing a letter writing campaign together. I approached ⁓ the chief information officer in person of the CRA, the Canadian Revenue Agency. ⁓ I did all sorts of things. I spoke at conferences. I went to Ottawa repeatedly. I spoke to CSEC. I spoke to Treasury Board. Like, I am in their face and nothing was happening. And so that member of parliament got voted out. A new one got voted in, Jeff Kibble. And so I have been working with him and we made a petition. We now have enough signatures. So it closes May 26th, but we have enough signatures. And what this means is that he is going to present it. So first of all, they're going to check the signatures and it's going to be fine because we have almost 700 and you need 500. And so even if they remove some people, we're fine. So then the next steps, so I thought that they voted on it in question period and it turned out that I was incorrect. My stepfather was a political analyst for 25 years and that's what he had told me the process was, but it has changed it turns out since he retired. And so now they're not going to vote on it in question period. What's going to happen is he's going to present it to Parliament and read it to them and explain it to them. for those of you that don't know and that's okay, 7-1-1-5 points out that the Canadian public is paying a huge price of safety and financial cost because we are having data breaches and security incidents constantly in the federal government. We see some of it in the news, but it is the tip of the iceberg, I assure you. What we are seeing is 0.01 % of what's happening in my opinion. And so we are paying hundreds and hundreds of millions of dollars per year because of these mistakes. And so that is... ⁓ The way a petition is you have to have a prayer, so that is my prayer. And then a request. And my request is that they create a secure coding policy, which I wrote and sent to them already. And I created prompts that enforce it, and I offer that for free too. And I want CSEC, the Communication and Security Establishment Canada, to enforce it. And so every single piece of software from now on released or maintained by the federal government, there'd be like, you know, obviously like a certain window for them to become compliant. But right now there's no guidance on that. There's no international standard. Like I know there's ISO 27001, NIST, ITSG, if you're in Canada, none of those cover secure coding. Like some say you should do secure by design and you should secure your supply chain, but that's all it says. So mine has 84 specific things that you need to do and then you will build secure software. If you do those things, you will build excellent software. And so I've supplied that to them for free. They don't have to use that. They can write their own. But if this passes, so basically he has to read it and then they have to create a formal written response for me about what Canada is going to do. And I am so excited to see what the response is and the response had better not damn well be we can't tell you because security. because that is the letter I keep receiving in responses to the letters I have been sending for years. I've been sending letters since 2021. Like, wow. All the time. I know I should have a social life and I should probably join a volleyball team. However, I write letters. And I really, really want us to protect Canada. In 2021, CRA lost two, I have four parents. They lost two of my parents. identities and they have to have credit monitoring for the rest of their lives. Right? This is not acceptable to me. This is humiliating to me that my industry is doing such a bad job. And by my industry, I mean the information security industry. Software developers are developing amazing, beautiful software. It's our job to make sure they do it safely and we're not succeeding right now. And so if we get this, if they do this, If they make a law about this, which is what the ask is, then I can try to encourage that in various other countries. I've already been in contact with the EFF. I've spoken to people briefly from other countries. If this passes, this is going to push a lot of other countries, especially the Five I's, towards this. Like, we could change the world. And so if you are Canadian and you are listening, please call your member of parliament and tell them to support this. It's not a vote, but if one of them then speaks up after Jeff Kibble and says, I support this, it'll be completely different. And so I know lots of people have been calling. I've reached out to all of the leaders from OASP across Canada, but every single voice matters right now more than you know. And so between now and probably the end of June when this actually gets presented, I really need the support if you're listening. speaker-0: Well, I'm so glad I took the opportunity to ask you about this. Super interesting. And I can see why you're so passionate about this subject. ⁓ Sounds extremely necessary from an industry perspective, especially with the acceleration that we're seeing around vulnerabilities and these incidents. ⁓ Okay. I got through maybe half of the questions I had for you, but I am going to wrap us up here. We'll just have to have you come back. ⁓ So before we go, Where are you directing folks who want to hear more from you? What social channels do you prefer? And how can folks keep in touch? speaker-1: If you want to know what I'm doing on a regular basis, go to newsletter.shehackspurple.ca and sign up for free. I will send you every single piece of content that I created that month. I will send you a silly meme, a little brief letter about what I'm up to, and invite you to every single event and thing that I will be doing. That's the easiest way to keep up with all the things. you just search she hacks purple, I am that on every single platform you can think of. I publish content at least once every day. And if you sign up for the newsletter and you have a thing to say, just hit reply. I actually read those. And so I'm less responsive on social media. I'm much better on the newsletter. And yeah, if you need some training, just let me know. speaker-0: Fantastic. All right. Well, let's go ahead and wrap up there. I have really enjoyed speaking with you today, Tanya. Again, my guest is from SheHacksPurple. My name is Kate Holderhoff. I'm a senior analyst at RedMonk. If you enjoyed this conversation, please like, subscribe, and review the MonkCast on your podcast platform of choice. If you're watching us on RedMonk's YouTube channel, please like, subscribe, and engage with us in the comments.