Supply Chain Is More Than Just Dependencies

Most developers think software supply chain security starts and ends with dependencies. But modern supply chain attacks don't stop there. Attackers look for paths into your software, and those paths often run through developers, CI/CD systems, build tools, deployment pipelines, and other trusted parts of the software delivery process.

This episode is sponsored by Maze.

In this episode of DevSec Station, Tanya Janca explains why the software supply chain is much bigger than libraries and packages, how modern attacks move through trusted systems, and what developers can do to better understand and protect the paths their software travels before it reaches production.

You'll learn:
• why dependencies are only one part of the supply chain
• how attackers move through trusted developer tooling and processes
• what "influence" means in a software supply chain context
• why supply chain attacks often appear normal until it's too late
• how to identify and protect the paths that affect your software

Tanya walks through a realistic supply chain attack scenario where no application vulnerability is exploited directly. Instead, an attacker compromises a trusted part of the software delivery process and uses it to influence what gets built and deployed.

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

Follow Tanya:

• https://shehackspurple.ca
• https://newsletter.shehackspurple.ca
• https://youtube.com/@shehackspurple
• https://linkedin.com/in/tanya-janca
• 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

(00:00):
When most people hear softwaresupply chain, they think about
open source dependencies.
Libraries, packages, Ruby gems,NuGet packages.
But if that's all you'resecuring, you're missing quite a
bit of attack surface.
Because the modern softwaresupply chain, it isn't just code

(00:21):
anymore.
It's people, it's tools, andit's all the paths in between
them.
Hi, I'm Tanya Jenka, also knownas SheHacksPurple.
Welcome to DevSecStation, apodcast for software developers
who want to build more securesoftware.
In each episode, I'll share ashort practical lesson about

(00:43):
secure coding, softwaresecurity, and how to build safer
systems without slowingdevelopment down.
You can jump in at any episode,at any time.
No homework required.
This episode is sponsored byMAES.
One of the biggest problems insecurity right now is that every
vulnerability or cloud scannersays everything is critical.

(01:07):
And honestly, no one has timefor that.
MAZES uses AI agents toinvestigate vulnerabilities in
context, so you can focus on theissues that are actually
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

(01:29):
of scaling that security teamsreally need right now.
Learn more about maze atmazehq.com slash devsec.
If you write code, shipsoftware, use CI pipelines, or
rely on tools that you didn'tpersonally build, this episode
is for you.

(01:50):
For years we've talked aboutsupply chain security as if it's
just about dependencies.
And to be clear, dependenciesmatter a lot.
They're very important.
But modern attacks don't stopthere because attackers don't
think in categories like a lotof us do.
They think in paths to exploit.

(02:12):
They don't have to follow ruleslike we do.
Any person, tool, or service orprocess that can influence your
code or your build or yourdeployment is part of your
software supply chain.
And that includes things wedon't always label as security
problems.
So let's walk through arealistic scenario together.

(02:33):
No one exploits your app, no onebreaks your cryptography, no one
hacks production directly.
Instead, an attacker compromisesa developer account or a CI
token or a browser plugin, abuild script, a GitHub action
that you didn't write, but it'spart of your CI.

(02:57):
And from there, they don't needto be loud or big or make huge
changes.
They might just need to changeone 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 isflowing downstream.

(03:19):
It's been signed, packaged, anddeployed by systems that you and
your team trust.
This is why so many supply chainincidents feel very confusing
and frustrating after the fact.
Nothing looked hacked orbreached or broken.
Everything behaved normally.
So how do we avoid this?

(03:41):
A bad approach is treatingsupply chain security as only a
dependency problem.
Teams scan libraries, patchCVEs, and feel like they've
solved the problem, they canwash their hands of it, but this
is not enough becausedependencies are only one slice
of this system.
You can have perfectly patchedlibraries and still ship

(04:01):
compromised software.
A better approach would besecuring some parts of the
supply chain.
So dependencies for sure, andthen maybe also the CI.
Perhaps we look at accesscontrol.
This would help, but it would beinconsistent.
And unfortunately, attackers arevery good at finding that one

(04:21):
unguarded path that you didn'tthink about, the one thing you
missed is their specialty.
The best approach is thinking interms of influence and paths.
And when I say influence, I meananything that can change your
software or how it is builtwithout going through your
normal code review steps.

(04:42):
So ask yourself, what can changemy code?
What can change my build?
What can change what getsdeployed?
And then put guardrails on allof those paths.
When you protect how softwaremoves, not just how it's made,
supply chain attacks get much,much harder for attackers to

(05:04):
pull off.
If you do just one thing afterthis episode, please do this.
Map one supply chain path andthen lock it down.
Pick an application and thenanswer this question.
From a developer writing thecode to the same code running in
production, what touches it?

(05:26):
This might include your sourcecontrol, your CI pipelines,
build scripts, packageregistries, artifact
repositories, deployment tools,cloud credentials, whatever.
Validate that every one of thosesystems cannot be influenced
without your team knowing aboutit and approving that change.

(05:49):
If you find one or more are notsecure, add a guardrail.
Even if you find several issuesbut just fix one, you are way
ahead.
You don't need to secureliterally everything today.
That's okay, but please, pleasefix one.
Supply chain attacks succeed notbecause teams are careless, but
because modern software systemsare incredibly complex and fast.

(06:14):
When we stop thinking in silosand start thinking in paths and
flows, security becomes clearerand more manageable.
This is not about walking downevery single thing or making
your job super difficult andpainful.
It's about ensuring your systemsare truly safe.
Thanks for listening toDevSecStation.

(06:36):
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 Jenka, also known as
SheHacksPurple.
And I teach secure codingtraining for software
developers.
You can find me online atshehackspurple.ca.

(06:57):
Thank you for being here.