If you're a software developer and you think security attacks are only about production systems, I have some bad news for you. You are now part of the attack service. And no, that does not mean that you're doing a bad job. Hi, I'm Tanya Jenka, also known as SheHacks Purple. 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. If you write code, use an IDE, install dependencies, copy code snippets from the internet or perhaps Stack Overflow, or use AI coding assistance, this episode is for you. For a long time, security teams focused on applications, firewalls, servers, production environments. But attackers, they follow the value and the easiest way to get the thing done. And today the fastest way into a company is often not through prod. It's through you, the software developer. Why? Because software developers are essentially superheroes with literal superpowers. You have access to source code, access to secrets, access to CIs, access to deployment credentials, and a lot more. Let's walk through a very realistic attack example. So you're building an awesome new feature, right? You need a library. So you search for it, maybe through your package manager, maybe you use an AI assistant. The package you find looks legit. The name is close to what you expected. The README looks fine, so you install it, right? But what you might not see is that this package was created last week. And it contains a really small post-install script. And that script quietly grabs environment variables. And suddenly your cloud credentials are in the wrong hands. Nothing was technically exploited, so no alerts were fired, but now the attacker is literally inside your supply chain. You should notice what did not happen here. No one hacked your application, no one broke your authentication logic, no one exploited a zero day in your production app directly. They went through you. Not because you're careless, but because this ecosystem that we use makes it so, so easy to make mistakes. A bad approach, which is pretty common, is to assume security starts after your code is written. Developers focus on features and the security team and all their reviews, that happens later, right? If they happen at all. Yeah. So this might help a bit, but it relies on memory, attention to detail, and all of us having perfect judgment all the time. Humans are not very good at that, especially when we're all facing deadlines. So the best approach, the one I'd like you to do, is assuming developers are targets from the very beginning and designing workflows accordingly. And that means adding guardrails. It means creating secure defaults. It means using tooling that catches problems early before all the damage has been done. If security is built into the developer experience, developers can do the right thing without even having to think about it. We want to make it easy to do the right thing. So if you do just one thing after this episode, do this. Look at your own workflow and ask yourself a question. If someone wanted to get into our environment, where could they go through a developer? This might be your dependencies, it might be your CI, it might be secrets that are stored in local configs instead of a secret management tool. You don't have to fix every single thing, but I want to ask you to try to identify one weak point, and then I want you to fix that weak point. And I realize this is an open-ended thing, but try to think of something and then fix it. This is not about blaming software developers. Good developers make insecure choices because they work in insecure systems. If we fix the system, improvements start to happen automatically. You are not the problem, it's the way the system is set up. 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.