Developers Are Now Targets: How Supply Chain Attacks Actually Reach You

Developers are no longer just building software.
 They’re being targeted directly.

In this episode, Tanya Janca explains how supply chain attacks reach developers through everyday tools, packages, and workflows.

These attacks don’t feel like attacks at first. They look like normal development work until it’s too late.

You’ll learn:
 • How supply chain attacks reach individual developers
 • Why developer environments are now high-value targets
 • Where risk shows up in daily workflows
 • Simple ways to protect yourself without slowing down

If you work in JavaScript, DevSecOps, or application security, this shift matters.

👉 Start by reviewing what you install, what runs during install, and what your tools are actually doing behind the scenes.

#SupplyChainSecurity #DevSecOps #AppSec #SecureCoding #SoftwareSecurity #DeveloperSecurity

Episode Transcript

SPEAKER_00 (00:00):
If you're a software developer and you think security
attacks are only aboutproduction systems, I have some
bad news for you.
You are now part of the attackservice.
And no, that does not mean thatyou're doing a bad job.
Hi, I'm Tanya Jenka, also knownas SheHacks Purple.
Welcome to DevSecStation, apodcast for software developers

(00:24):
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.
No homework required.
If you write code, use an IDE,install dependencies, copy code

(00:49):
snippets from the internet orperhaps Stack Overflow, or use
AI coding assistance, thisepisode is for you.
For a long time, security teamsfocused on applications,
firewalls, servers, productionenvironments.
But attackers, they follow thevalue and the easiest way to get

(01:11):
the thing done.
And today the fastest way into acompany is often not through
prod.
It's through you, the softwaredeveloper.
Why?
Because software developers areessentially superheroes with
literal superpowers.
You have access to source code,access to secrets, access to

(01:33):
CIs, access to deploymentcredentials, and a lot more.
Let's walk through a veryrealistic attack example.
So you're building an awesomenew feature, right?
You need a library.
So you search for it, maybethrough your package manager,

(01:54):
maybe you use an AI assistant.
The package you find lookslegit.
The name is close to what youexpected.
The README looks fine, so youinstall it, right?
But what you might not see isthat this package was created
last week.
And it contains a really smallpost-install script.

(02:15):
And that script quietly grabsenvironment variables.
And suddenly your cloudcredentials are in the wrong
hands.
Nothing was technicallyexploited, so no alerts were
fired, but now the attacker isliterally inside your supply
chain.
You should notice what did nothappen here.

(02:38):
No one hacked your application,no one broke your authentication
logic, no one exploited a zeroday in your production app
directly.
They went through you.
Not because you're careless, butbecause this ecosystem that we
use makes it so, so easy to makemistakes.

(03:05):
A bad approach, which is prettycommon, is to assume security
starts after your code iswritten.
Developers focus on features andthe security team and all their
reviews, that happens later,right?
If they happen at all.

(03:40):
Yeah.
So this might help a bit, but itrelies on memory, attention to
detail, and all of us havingperfect judgment all the time.
Humans are not very good atthat, especially when we're all
facing deadlines.
So the best approach, the oneI'd like you to do, is assuming

(04:02):
developers are targets from thevery beginning and designing
workflows accordingly.
And that means addingguardrails.
It means creating securedefaults.
It means using tooling thatcatches problems early before
all the damage has been done.
If security is built into thedeveloper experience, developers

(04:26):
can do the right thing withouteven having to think about it.
We want to make it easy to dothe right thing.
So if you do just one thingafter this episode, do this.
Look at your own workflow andask yourself a question.
If someone wanted to get intoour environment, where could

(04:48):
they go through a developer?
This might be your dependencies,it might be your CI, it might be
secrets that are stored in localconfigs instead of a secret
management tool.
You don't have to fix everysingle thing, but I want to ask
you to try to identify one weakpoint, and then I want you to
fix that weak point.

(05:10):
And I realize this is anopen-ended thing, but try to
think of something and then fixit.
This is not about blamingsoftware developers.
Good developers make insecurechoices because they work in
insecure systems.
If we fix the system,improvements start to happen
automatically.

(05:31):
You are not the problem, it'sthe way the system is set up.
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 Jenka, also known as
SheHacksPurple.

(05:51):
And I teach secure codingtraining for software
developers.
You can find me online atshehackspurple.ca.
Thank you for being here.