Malicious Dependencies Aren’t an Accident

Malicious dependencies are not accidents. They are often intentionally designed to look trustworthy so developers install them without hesitation. In this episode of DevSec Station, Tanya Janca explains how attackers use typosquatting, dependency confusion, fake packages, and even AI-generated recommendations to compromise developer environments and steal credentials. 

This episode is sponsored by Maze.

You’ll learn:
• how malicious packages trick developers
• why dependency attacks work so well
• how attackers abuse trust and speed
• why “just be careful” is not an effective defense
• practical ways to add safer guardrails to your development workflow

Tanya walks through a realistic example of a dependency stealing AWS credentials, explains why this is a workflow problem instead of a developer failure, and shares practical steps you can take immediately to reduce risk in your own projects.

One practical action from this episode:
Require new dependencies to go through pull request review, and add lightweight checks that help your team verify package names and sources before installation.

DevSec Station is a podcast by Tanya Janca, focused on short, practical lessons that help software developers build more secure software.

Follow Tanya:
• https://shehackspurple.ca
• https://newsletter.shehackspurple.ca
• https://linkedin.com/in/tanya-janca
• https://www.youtube.com/shehackspurple
• https://TanyaJanca.com  

This episode is sponsored by Maze.
One of the biggest problems in security right now is that every vulnerability scanner says everything is critical, and honestly, no one has time for that.

Maze uses AI agents to investigate vulnerabilities in context, so you can focus on the issues that are actually exploitable in your environment, 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 need right now.

Learn more about Maze https://mazehq.com/devsec

Episode Transcript

SPEAKER_00 (00:00):
Let me tell you about a package manager that
stole AWS credentials.
It didn't use a zero day.
It didn't exploit avulnerability.
It relied on one thing.
Someone installing the wrongpackage name.
And yes, that happens way moreoften than you think.
Hi, I'm Tanya Jenka, also knownas SheHexPurple.

(00:24):
Welcome to DevSecStation, apodcast for software developers
who want to build more securesoftware.
In each episode, I'll share ashort practical lesson about
secure coding, softwaresecurity, and how to build safer
systems without slowingdevelopment down.
You can jump in at any episode,at any time.

(00:45):
No homework required.
This episode is sponsored byMAISE.
One of the biggest problems insecurity right now is that every
vulnerability or cloud scannersays everything is critical.
And honestly, no one has timefor that.
MAZES uses AI agents toinvestigate vulnerabilities in
context, so you can focus on theissues that are actually

(01:08):
exploitable in your environmentand not just theoretically
scary.
Their AI agents also generateand prioritize fixes that knock
out multiple vulnerabilities atonce, which is honestly the kind
of scaling that security teamsreally need right now.
Learn more about maze atmazehq.com slash devsec.

(01:31):
If you install dependenciesregularly, use autocomplete in
your package manager, copyinstall commands from Stack
Overflow, or let AI suggestlibraries to you, this episode
is definitely for you.
There's a myth that maliciousdependencies are rare occasions.

(01:52):
They're accidents.
Someone accidentally uploadedsomething bad and whoops, here
we are.
But that is not what ishappening right now.
Most malicious dependencies areintentionally created.
They are named very carefully.
Their release is timedstrategically.
They are absolutely 100%designed to blend in.

(02:19):
This is malicious actors,socially engineering software
developers every single day.
So here's how this usuallyworks: an attacker looks for
popular packages, internalpackage names, or commonly
mistyped names.
So maybe the real package iscalled aws-helper.

(02:41):
So they publish aws-helpers oraw underscore helper.
Or they upload a package withthe same name to a public
registry that your toolingprefers.
The package looks fine.
The readme is copied over, soit's a perfect copy.
The description sounds superlegit, and then you install it.

(03:04):
What the package does next isquiet.
It reads your environmentvariables.
It grabs the AWS keys, theGitHub token, the CI
credentials, whatever, and thenit sends them to someone else.
Nothing in your app visiblybreaks, the app still works,

(03:25):
there are no errors, there's noalerts, except now your
credentials are in the wronghands.
And here's the very importantpart.
This didn't happen because youwere reckless or careless.
It happened because theecosystem we work in makes it
very, very easy to trust thewrong thing.

(03:48):
So how do we fix this?
A bad approach, which I'm seeinga lot of, is trusting
dependencies based on namerecognition.
It looks right, it sounds right,it installs cleanly, I'm sure
it's fine.
But this approach fails becausenames are cheap and attackers
know exactly which onesdevelopers expect to see.

(04:10):
It's easy for them to fake this.
A better approach might betelling developers to slow down
and be more careful.
You should double check thename.
You should read the README.
You should trust your instincts.
This might help a bit, but itstill relies on attention to

(04:31):
detail, memory, and perfectjudgment.
It relies on us having a lot ofwillpower, and that's usually a
losing proposition.
And when we're busy, we'retired, or we have a deadline,
that's exactly when mistakeshappen.
That's when they happen to me.

(04:51):
So the best approach we couldtake is adding intentional
friction at the moment where adependency is being added.
So that means systems that makeit harder to install the wrong
thing and easier for us tonotice when something's not
quite right.
When a pause is built into ourworkflow, developers don't have

(05:14):
to remember to be cautious.
The system just does it forthem.
It literally reminds them to doit.
If you do just one thing afterthis episode, please do this.
Lock down how new dependenciesare introduced into your
project.
So you can choose, but here's apractical way to do this.

(05:36):
So step one, pick one repo thatyou are working on regularly.
Step two, look at how you andyour team add dependencies.
How are you currently addingthem?
Can anyone add a new dependencydirectly?
Or does it go through a pullrequest with a review?
If it's not already required,make this change.

(05:56):
New dependencies must be addedthrough a pull request and
reviewed by at least one otherhuman.
So if you add it, you can'treview it.
Someone else needs to.
Step three, add one lightweightcheck.
It could be a script that flagsnew dependencies and PRs.
An SCA policy that highlightsnew packages.

(06:17):
Or even a simple checklist itemin your PR template that says,
is this dependency name exactlywhat you expected?
Even that little reminder canhelp.
Okay, so now step four.
If you use AI coding assistance,treat dependency suggestions as
untrusted input and neverinstall directly from an AI

(06:39):
suggestion withoutdouble-checking the package name
and the source.
Assume there might be a problemevery single time.
You don't need to fix yourentire supply chain today, but
we want to add friction at thatmoment where the mistake is most
likely to happen.
Malicious dependencies areworking because they exploit

(06:59):
trust and speed.
It's not because developersdon't care about security.
If we can add small pauses athigh risk moments, we can
dramatically reduce the chancesof something bad slipping
through.
This isn't about slowingdevelopers down.
The pause is just a few seconds.
It's about slowing attackersdown.

(07:21):
Thanks for listening toDevSecStation.
If you enjoyed this episode,please subscribe, share it with
a friend, or leave a review.
It helps more people discoverthe show.
If you'd like to learn more, I'mTanya Janka, also known as She
HacksPurple.
And I teach secure codingtraining for software
developers.

(07:41):
You can find me online atshehackspurple.ca.
Thank you for being here.