Let me tell you about a package manager that stole AWS credentials. It didn't use a zero day. It didn't exploit a vulnerability. It relied on one thing. Someone installing the wrong package name. And yes, that happens way more often than you think. Hi, I'm Tanya Jenka, also known as SheHexPurple. 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 MAISE. 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 install dependencies regularly, use autocomplete in your package manager, copy install commands from Stack Overflow, or let AI suggest libraries to you, this episode is definitely for you. There's a myth that malicious dependencies are rare occasions. They're accidents. Someone accidentally uploaded something bad and whoops, here we are. But that is not what is happening right now. Most malicious dependencies are intentionally created. They are named very carefully. Their release is timed strategically. They are absolutely 100% designed to blend in. This is malicious actors, socially engineering software developers every single day. So here's how this usually works: an attacker looks for popular packages, internal package names, or commonly mistyped names. So maybe the real package is called aws-helper. So they publish aws-helpers or aw underscore helper. Or they upload a package with the same name to a public registry that your tooling prefers. The package looks fine. The readme is copied over, so it's a perfect copy. The description sounds super legit, and then you install it. What the package does next is quiet. It reads your environment variables. It grabs the AWS keys, the GitHub token, the CI credentials, whatever, and then it sends them to someone else. Nothing in your app visibly breaks, the app still works, there are no errors, there's no alerts, except now your credentials are in the wrong hands. And here's the very important part. This didn't happen because you were reckless or careless. It happened because the ecosystem we work in makes it very, very easy to trust the wrong thing. So how do we fix this? A bad approach, which I'm seeing a lot of, is trusting dependencies based on name recognition. It looks right, it sounds right, it installs cleanly, I'm sure it's fine. But this approach fails because names are cheap and attackers know exactly which ones developers expect to see. It's easy for them to fake this. A better approach might be telling developers to slow down and be more careful. You should double check the name. You should read the README. You should trust your instincts. This might help a bit, but it still relies on attention to detail, memory, and perfect judgment. It relies on us having a lot of willpower, and that's usually a losing proposition. And when we're busy, we're tired, or we have a deadline, that's exactly when mistakes happen. That's when they happen to me. So the best approach we could take is adding intentional friction at the moment where a dependency is being added. So that means systems that make it harder to install the wrong thing and easier for us to notice when something's not quite right. When a pause is built into our workflow, developers don't have to remember to be cautious. The system just does it for them. It literally reminds them to do it. If you do just one thing after this episode, please do this. Lock down how new dependencies are introduced into your project. So you can choose, but here's a practical way to do this. So step one, pick one repo that you are working on regularly. Step two, look at how you and your team add dependencies. How are you currently adding them? Can anyone add a new dependency directly? Or does it go through a pull request with a review? If it's not already required, make this change. New dependencies must be added through a pull request and reviewed by at least one other human. So if you add it, you can't review it. Someone else needs to. Step three, add one lightweight check. It could be a script that flags new dependencies and PRs. An SCA policy that highlights new packages. Or even a simple checklist item in your PR template that says, is this dependency name exactly what you expected? Even that little reminder can help. Okay, so now step four. If you use AI coding assistance, treat dependency suggestions as untrusted input and never install directly from an AI suggestion without double-checking the package name and the source. Assume there might be a problem every single time. You don't need to fix your entire supply chain today, but we want to add friction at that moment where the mistake is most likely to happen. Malicious dependencies are working because they exploit trust and speed. It's not because developers don't care about security. If we can add small pauses at high risk moments, we can dramatically reduce the chances of something bad slipping through. This isn't about slowing developers down. The pause is just a few seconds. It's about slowing attackers down. 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 Janka, also known as She HacksPurple. And I teach secure coding training for software developers. You can find me online at shehackspurple.ca. Thank you for being here.