When most people hear software supply chain, they think about open source dependencies. Libraries, packages, Ruby gems, NuGet packages. But if that's all you're securing, you're missing quite a bit of attack surface. Because the modern software supply chain, it isn't just code anymore. It's people, it's tools, and it's all the paths in between them. 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 MAES. 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 write code, ship software, use CI pipelines, or rely on tools that you didn't personally build, this episode is for you. For years we've talked about supply chain security as if it's just about dependencies. And to be clear, dependencies matter a lot. They're very important. But modern attacks don't stop there because attackers don't think in categories like a lot of us do. They think in paths to exploit. They don't have to follow rules like we do. Any person, tool, or service or process that can influence your code or your build or your deployment is part of your software supply chain. And that includes things we don't always label as security problems. So let's walk through a realistic scenario together. No one exploits your app, no one breaks your cryptography, no one hacks production directly. Instead, an attacker compromises a developer account or a CI token or a browser plugin, a build script, a GitHub action that you didn't write, but it's part of your CI. And from there, they don't need to be loud or big or make huge changes. They might just need to change one little thing to cause a huge problem. Maybe it's a dependency version, a build artifact, a pipeline step, a config file. And suddenly malicious code is flowing downstream. It's been signed, packaged, and deployed by systems that you and your team trust. This is why so many supply chain incidents feel very confusing and frustrating after the fact. Nothing looked hacked or breached or broken. Everything behaved normally. So how do we avoid this? A bad approach is treating supply chain security as only a dependency problem. Teams scan libraries, patch CVEs, and feel like they've solved the problem, they can wash their hands of it, but this is not enough because dependencies are only one slice of this system. You can have perfectly patched libraries and still ship compromised software. A better approach would be securing some parts of the supply chain. So dependencies for sure, and then maybe also the CI. Perhaps we look at access control. This would help, but it would be inconsistent. And unfortunately, attackers are very good at finding that one unguarded path that you didn't think about, the one thing you missed is their specialty. The best approach is thinking in terms of influence and paths. And when I say influence, I mean anything that can change your software or how it is built without going through your normal code review steps. So ask yourself, what can change my code? What can change my build? What can change what gets deployed? And then put guardrails on all of those paths. When you protect how software moves, not just how it's made, supply chain attacks get much, much harder for attackers to pull off. If you do just one thing after this episode, please do this. Map one supply chain path and then lock it down. Pick an application and then answer this question. From a developer writing the code to the same code running in production, what touches it? This might include your source control, your CI pipelines, build scripts, package registries, artifact repositories, deployment tools, cloud credentials, whatever. Validate that every one of those systems cannot be influenced without your team knowing about it and approving that change. If you find one or more are not secure, add a guardrail. Even if you find several issues but just fix one, you are way ahead. You don't need to secure literally everything today. That's okay, but please, please fix one. Supply chain attacks succeed not because teams are careless, but because modern software systems are incredibly complex and fast. When we stop thinking in silos and start thinking in paths and flows, security becomes clearer and more manageable. This is not about walking down every single thing or making your job super difficult and painful. It's about ensuring your systems are truly safe. 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.