But let's be honest for a second. If annual security training truly worked, we wouldn't keep seeing the same mistakes over and over, would we? And it's not because developers don't care. It's because annual training asks humans to be perfect while using systems that are anything but. Hi, I'm Tanya Jenka, also known as SheHacksPurple. Welcome to DevSecStation, a podcast for software developers who want to build more secure software. In each episode, I'll share a short practical lesson about secure coding, software security, and how to build safer systems without slowing development down. You can jump in at any episode, at any time. No homework required. This episode is sponsored by Maze. One of the biggest problems in security right now is that every vulnerability or cloud scanner says everything is critical, and honestly, no one has time for that. MAZES uses AI agents to investigate vulnerabilities in context, so you can focus on the issues that are actually exploitable in your environment and not just theoretically scary. Their AI agents also generate and prioritize fixes that knock out multiple vulnerabilities at once, which is honestly the kind of scaling that security teams really need right now. Learn more about maze at mazehq.com slash devsec. If you're a developer who's ever made a security bug in their code, then afterthought, how did this happen? I know this. How'd I let this happen? This episode is for you. Here's the core idea of this episode. Most security issues don't happen because developers don't know what they're supposed to do. They happen because the easiest path is the insecure one. When we rely on training alone, we're relying on memory and willpower. But when we rely on defaults instead, we're shaping behavior automatically. And in live systems, defaults will win every single time. So I have a story for you: a very normal developer day. You're busy, you're juggling several different tickets, you're context switching all day long. You spin up a new service, you copy a config from another repo, you leave the settings as is because they work. Nothing feels wrong. You didn't ignore security. You just followed the path that was already there. And if the previous service was okay, this one should be too, right? But that's the thing about insecure defaults. They don't feel like a bad decision. They feel normal. You're saving time, you're following the flow. And most training doesn't change what feels normal. But the right systems can, and they do. So how do we fix this? A bad approach would be trying to solve security problems with only annual training. More slides, more lectures, wah wah, wah. But no real change. This approach often fails because annual training is easy to forget, especially under pressure. And no one is at their best when they're rushing. And as software developers, we often find ourselves rushing in our line of work. A better approach is hoping developers remember what they learned in the annual training that they did six months ago. Be careful, double check, don't forget. And this helps a bit. I mean, I give training, it definitely helps, but it still depends on constant attention, energy, and willpower. And willpower is a terrible security control on its own. The best approach is training that explains the why, and then changing the defaults in your system to match. So if the secure option is the easiest option, people will take it automatically. And with training, they understand why they should not undo those nice secure defaults we just made. This isn't about locking things down so that they're unusable or slowing down teams. It's about designing workflows that work with human behavior instead of against it. If you do just one thing after this episode, please do this. Change one default in one repo or project that you work on for the better. Here's how to do that in a way that you as a developer might have control over. Step one, pick a repo your team actively works on. Step two, identify one default that could lead to security problems if someone forgets to change it. So this could be a config file that includes insecure settings that you know you're supposed to change later, except no one does. A CI job that runs without security checks like static analysis or software composition analysis. A code template that skips authentication or logging or validation or anything else that you know should be there. A script that assumes secrets are present in plaintext, meaning that you have a leak somewhere. Step three, flip that default on so that it's secure from now on. Make the secure option automatic. Make the insecure option require explicit choice and make it effortful to actually put into action. Step four, leave a comment or a commit message explaining why the default exists so future you and your teammates don't undo it. You're not fixing everything today. You're creating one small nudge that prevents the same mistake from happening again and again. And this is how real security improvements can happen. It's not through perfect behavior, it's through systems that support you in always making the right decision. When you change a default so that it's secure, you're protecting every future change that touches that code. And that is win. Thanks for listening to DevSecStation. If you enjoyed this episode, please subscribe, share it with a friend, or leave a review. It helps more people discover the show. If you'd like to learn more, I'm Tanya Jenka, also known as SheHacksPurple. And I teach secure coding training for software developers. You can find me online at shehackspurple.ca. Thank you for being here.