April 14, 2026 • 10 mins
What if a supply chain attack didn’t start with a complex exploit… but something completely normal?
A typo.
A copy-paste.
Even an AI suggestion.
In this episode, Tanya Janca breaks down how modern supply chain attacks actually happen inside everyday developer workflows.
These attacks aren’t one big moment. They’re a series of small, reasonable decisions that quietly introduce risk.
You’ll learn:
• Why supply chain attacks are a process, not a single event
• How attackers exploit normal developer behavior
• A simple, step-by-step example of a real attack path
• Why traditional SCA tools often miss real risk
• How to focus on what actually matters
👉 If you do one thing this week:
Run your SCA tool with reachability enabled and fix one real issue. That’s how you start reducing risk.
If you work in DevSecOps, application security, or software development, you need to understand this.
Follow Tanya:
Listen
Watch
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
SPEAKER_00 (00:00):
If I told you a supply chain attack could start
with a typo, a copy-paste, or anAI suggestion, would that
surprise you?
Because that's how a lot of themactually start now.
Not with elite hackers usingzero days, but with a very
normal developer behavior.
Hi, I'm Tanya Jenka, also knownas SheHacksPurple.
(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 episodeat any time.
(00:45):
No homework required.
If you've ever installed adependency without thinking too
hard about it, trusted a toolbecause it looked super legit,
or copied code from a place thatfelt safe, this one's probably
for you.
When people hear supply chainattack, they often imagine
(01:08):
something really dramatic.
Nation-state hackers, zero daysstrung together.
There's this huge super breachthat starts deep inside our
production environment.
But most modern supply chainattacks actually don't start
there.
They start really, reallyquietly.
(01:30):
And they unfold a little bitover time.
We often don't see them until itis way too late.
A supply chain attack is notusually one single mistake.
It's often a series of small,very reasonable seeming steps
that add up to a super huge bigproblem later.
I'd like to walk through a veryrealistic example step by step
(01:53):
with you of how this couldhappen, because they are
happening every day to a lot ofus.
So step one, an attacker noticesa popular internal package, and
the name is mentioned in apublic repo, a blog post, or a
job posting.
The attacker takes note.
Step two, attacker publishes apackage with the same name, or a
(02:16):
very similar name.
Maybe there's a typo, maybe aslightly different scope,
something intended to confuse,maybe an underscore instead of a
dash.
Step three.
That package includes somethingvery small and sneaky.
Perhaps it is a post-installscript, a dependency that phones
(02:38):
home, we call this command andcontrol, a line of code that
collects environment variables,something like that.
Then we get to step four.
You, the unsuspecting softwaredeveloper, installs it.
Or an AI assistant suggests it,or a build system resolves it
automatically because the namematches.
(03:02):
Nothing in your app breaks.
The tests still pass.
The app works.
Except now the attacker has acopy of your credentials or a
token or access to a buildpipeline.
Yeah.
So notice what did not happenhere.
No one hacked your app, right?
(03:24):
No one broke your cryptography.
No one was sitting there bruteforcing a password so that you
could detect it with yourdetection tools.
This attack succeeds because thesystem trusted something it
should not have.
And because a developer didexactly what they were supposed
to do (03:42):
ship code.
That's our jobs, right?
So how do we fix this?
A very common bad approach isnot really dealing with the
supply chain security at all,just ignoring it.
Dependencies just keep pilingup.
You install whatever you want.
Vulnerabilities pile up too.
(04:04):
And usually no one's actuallypaying attention.
This is not really being managedwhatsoever.
Or your team buys a softwarecomposition analysis tool, an
SCA tool.
They run it once, they seehundreds or thousands of
findings, they super panic, andthen quietly they ignore the
tool and the findings because,oh my gosh, that is way too
(04:26):
much.
Both of these approaches failbecause attackers do not care
how noisy and long your reportis.
They only need one way in, oneexploitable path, and they are
in.
They don't care about the rest.
A better approach would berunning a software composition
analysis tool and trying to workthrough that long list.
(04:49):
This is definitely animprovement because at least you
can see the risk and you'relooking at it.
But it is not great becausewithout reachability features,
you're still underwater.
So you don't know what'sactually being used.
You don't know what's actuallyexploitable.
And this leaves developerscompletely drowned in findings
(05:12):
rather than actual seriousrisks.
And these findings mostly don'tmatter.
That's how a softwarecomposition analysis tool can
just become background noiseinstead of a useful security
control.
So the best approach iscombining SCA with reachability
(05:32):
features or runtime usageanalysis.
There's a lot of different namesdepending upon who is in charge
at the marketing team there.
And then acting on thedependencies that pose real,
genuine risk to yourorganization.
So think high severity plusreachability being the key thing
you're looking for.
(05:53):
So what do these features do?
So they tell you if thevulnerability exists and if the
code path with the vulnerabilityis actually executed, and if
this is something an attackercould realistically actually get
at.
(06:15):
So the problem doesn't quietlycome back and bite you later.
So when we do this, the securitystops creating a backlog and
instead starts to become anormal part of maintenance.
So the tool starts to supportyou instead of hindering you.
If you do just one thing afterthis episode, please do this.
I would like you to run asoftware composition analysis
(06:36):
tool with reachability turned onand then action the top results.
And if it doesn't havereachability, throw it out and
buy a new one.
We are not trying to fix everysingle low-risk thing we can
find.
We are trying to remove thestuff that can genuinely hurt
us, our customers, ourcolleagues, the citizens where
we live.
(06:57):
So step one, because obviouslyI'm going to give you some
steps, right?
Step one, run an SCA againstyour repo or on that whatever
app you're currently working on.
If your tool supports it, whichI hope it does, turn on
reachability, call graphanalysis, or runtime usage
tracking.
The wording or the name of thefeature changes from tool to
(07:20):
tool, but what you want has thesame outcome.
Show me what vulnerabilities arein code paths that are actually
getting executed.
That's what we want to know.
Step two, filter down thoseresults to high severity and
reachable from within my code.
So this is your real list that Iwant you to start working on.
(07:42):
That's the stuff that can beexploited, not just stuff that
exists somewhere in yourdependency graph.
Now I would love it if you alsolooked at mediums as well, but
I'm willing to just accept highvulnerabilities for today.
Step three, take action on thetop one.
So pick the simplest one to fixfirst and go in this order.
(08:07):
Remove it if you don't need it.
Two, upgrade the dependency to apatched version if possible.
And then three, if none of thoseare possible, replace that
dependency if it's no longersupported or if the amount of
effort to replace it or toupgrade it seems really
unrealistic.
Okay, now we're on to step four.
Step four, prevent future youfrom redoing this work by adding
(08:31):
at least one guardrail.
So here is a list of guardrails.
Pin versions and use lock filesto ensure that nothing changes
on you by surprise.
Pinning doesn't makedependencies safe, but it does
make changes deliberate.
And as you can imagine, ussecurity nerds do not like those
kinds of surprises.
(08:51):
Another guardrail you could dowould be being strict on which
registries you use and onlydownloading dependencies from
trusted registries.
Or three, you could do all ofthem if you wanted, but three,
the last choice, add an SCA toolto your pipeline and set your CI
to fail on high plus reachable.
So it's only noisy when itactually matters.
(09:14):
You don't need to boil the oceantoday.
Just run the SCA tool once andfix one finding and add one
guardrail, and you've done areally good job.
This is what I mean when I saysecurity should be practical.
You're not doing security forthe sake of it, you're doing
real work that keeps attackersout.
(09:35):
Reachability can be your secretweapon because it saves your
time.
It helps you focus on realproblems instead of drowning in
all these theoretical risks,often called findings.
Thanks for listening toDevSecStation.
If you enjoyed this episode,please subscribe, share it with
a friend, or leave a review.
(09:55):
It helps more people discoverthe show.
If you'd like to learn more, I'mTanya Jenka, also known as
SheHacksPurple.
And I teach secure codingtraining for software
developers.
You can find me online atshehackspurple.ca.
Thank you for being here.
If I told you a supply chain attack could start
with a typo, a copy-paste, or anAI suggestion, would that
surprise you?
Because that's how a lot of themactually start now.
Not with elite hackers usingzero days, but with a very
normal developer behavior.
Hi, I'm Tanya Jenka, also knownas SheHacksPurple.
(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 episodeat any time.
(00:45):
No homework required.
If you've ever installed adependency without thinking too
hard about it, trusted a toolbecause it looked super legit,
or copied code from a place thatfelt safe, this one's probably
for you.
When people hear supply chainattack, they often imagine
(01:08):
something really dramatic.
Nation-state hackers, zero daysstrung together.
There's this huge super breachthat starts deep inside our
production environment.
But most modern supply chainattacks actually don't start
there.
They start really, reallyquietly.
(01:30):
And they unfold a little bitover time.
We often don't see them until itis way too late.
A supply chain attack is notusually one single mistake.
It's often a series of small,very reasonable seeming steps
that add up to a super huge bigproblem later.
I'd like to walk through a veryrealistic example step by step
(01:53):
with you of how this couldhappen, because they are
happening every day to a lot ofus.
So step one, an attacker noticesa popular internal package, and
the name is mentioned in apublic repo, a blog post, or a
job posting.
The attacker takes note.
Step two, attacker publishes apackage with the same name, or a
(02:16):
very similar name.
Maybe there's a typo, maybe aslightly different scope,
something intended to confuse,maybe an underscore instead of a
dash.
Step three.
That package includes somethingvery small and sneaky.
Perhaps it is a post-installscript, a dependency that phones
(02:38):
home, we call this command andcontrol, a line of code that
collects environment variables,something like that.
Then we get to step four.
You, the unsuspecting softwaredeveloper, installs it.
Or an AI assistant suggests it,or a build system resolves it
automatically because the namematches.
(03:02):
Nothing in your app breaks.
The tests still pass.
The app works.
Except now the attacker has acopy of your credentials or a
token or access to a buildpipeline.
Yeah.
So notice what did not happenhere.
No one hacked your app, right?
(03:24):
No one broke your cryptography.
No one was sitting there bruteforcing a password so that you
could detect it with yourdetection tools.
This attack succeeds because thesystem trusted something it
should not have.
And because a developer didexactly what they were supposed
to do (03:42):
ship code.
That's our jobs, right?
So how do we fix this?
A very common bad approach isnot really dealing with the
supply chain security at all,just ignoring it.
Dependencies just keep pilingup.
You install whatever you want.
Vulnerabilities pile up too.
(04:04):
And usually no one's actuallypaying attention.
This is not really being managedwhatsoever.
Or your team buys a softwarecomposition analysis tool, an
SCA tool.
They run it once, they seehundreds or thousands of
findings, they super panic, andthen quietly they ignore the
tool and the findings because,oh my gosh, that is way too
(04:26):
much.
Both of these approaches failbecause attackers do not care
how noisy and long your reportis.
They only need one way in, oneexploitable path, and they are
in.
They don't care about the rest.
A better approach would berunning a software composition
analysis tool and trying to workthrough that long list.
(04:49):
This is definitely animprovement because at least you
can see the risk and you'relooking at it.
But it is not great becausewithout reachability features,
you're still underwater.
So you don't know what'sactually being used.
You don't know what's actuallyexploitable.
And this leaves developerscompletely drowned in findings
(05:12):
rather than actual seriousrisks.
And these findings mostly don'tmatter.
That's how a softwarecomposition analysis tool can
just become background noiseinstead of a useful security
control.
So the best approach iscombining SCA with reachability
(05:32):
features or runtime usageanalysis.
There's a lot of different namesdepending upon who is in charge
at the marketing team there.
And then acting on thedependencies that pose real,
genuine risk to yourorganization.
So think high severity plusreachability being the key thing
you're looking for.
(05:53):
So what do these features do?
So they tell you if thevulnerability exists and if the
code path with the vulnerabilityis actually executed, and if
this is something an attackercould realistically actually get
at.
(06:15):
So the problem doesn't quietlycome back and bite you later.
So when we do this, the securitystops creating a backlog and
instead starts to become anormal part of maintenance.
So the tool starts to supportyou instead of hindering you.
If you do just one thing afterthis episode, please do this.
I would like you to run asoftware composition analysis
(06:36):
tool with reachability turned onand then action the top results.
And if it doesn't havereachability, throw it out and
buy a new one.
We are not trying to fix everysingle low-risk thing we can
find.
We are trying to remove thestuff that can genuinely hurt
us, our customers, ourcolleagues, the citizens where
we live.
(06:57):
So step one, because obviouslyI'm going to give you some
steps, right?
Step one, run an SCA againstyour repo or on that whatever
app you're currently working on.
If your tool supports it, whichI hope it does, turn on
reachability, call graphanalysis, or runtime usage
tracking.
The wording or the name of thefeature changes from tool to
(07:20):
tool, but what you want has thesame outcome.
Show me what vulnerabilities arein code paths that are actually
getting executed.
That's what we want to know.
Step two, filter down thoseresults to high severity and
reachable from within my code.
So this is your real list that Iwant you to start working on.
(07:42):
That's the stuff that can beexploited, not just stuff that
exists somewhere in yourdependency graph.
Now I would love it if you alsolooked at mediums as well, but
I'm willing to just accept highvulnerabilities for today.
Step three, take action on thetop one.
So pick the simplest one to fixfirst and go in this order.
(08:07):
Remove it if you don't need it.
Two, upgrade the dependency to apatched version if possible.
And then three, if none of thoseare possible, replace that
dependency if it's no longersupported or if the amount of
effort to replace it or toupgrade it seems really
unrealistic.
Okay, now we're on to step four.
Step four, prevent future youfrom redoing this work by adding
(08:31):
at least one guardrail.
So here is a list of guardrails.
Pin versions and use lock filesto ensure that nothing changes
on you by surprise.
Pinning doesn't makedependencies safe, but it does
make changes deliberate.
And as you can imagine, ussecurity nerds do not like those
kinds of surprises.
(08:51):
Another guardrail you could dowould be being strict on which
registries you use and onlydownloading dependencies from
trusted registries.
Or three, you could do all ofthem if you wanted, but three,
the last choice, add an SCA toolto your pipeline and set your CI
to fail on high plus reachable.
So it's only noisy when itactually matters.
(09:14):
You don't need to boil the oceantoday.
Just run the SCA tool once andfix one finding and add one
guardrail, and you've done areally good job.
This is what I mean when I saysecurity should be practical.
You're not doing security forthe sake of it, you're doing
real work that keeps attackersout.
(09:35):
Reachability can be your secretweapon because it saves your
time.
It helps you focus on realproblems instead of drowning in
all these theoretical risks,often called findings.
Thanks for listening toDevSecStation.
If you enjoyed this episode,please subscribe, share it with
a friend, or leave a review.
(09:55):
It helps more people discoverthe show.
If you'd like to learn more, I'mTanya Jenka, also known as
SheHacksPurple.
And I teach secure codingtraining for software
developers.
You can find me online atshehackspurple.ca.
Thank you for being here.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
The Breakfast Club
The World's Most Dangerous Morning Show, The Breakfast Club, With DJ Envy, Jess Hilarious, And Charlamagne Tha God!