With great power comes great responsibility.
As developers, we drive the innovation engine. We solve hard, meaningful problems with technology. We work with elevated privileges and deep access — not by accident, but because it's required to do our jobs well.
That's the power part.
But with that power comes risk. And one of the most invisible, yet growing risks in modern software development is the shadow download and the rise of malicious open source packages designed to exploit it.
What is a shadow download?
A shadow download happens when a developer or build tool pulls a package directly from a public open source registry, bypassing the organization's secure internal repository or proxy.
This used to be the standard. For years, open source development followed a simple model: install what you need, straight from the internet. Package managers like npm, pip, and Maven were built for speed and convenience — and this "direct from the source" model was the norm.
Eventually, internal binary repositories emerged as a better way. They introduced:
-
Performance – faster, more reliable builds
-
Visibility – insight into what's being used
-
Control – governance over what enters the environment
Modern development teams adopted this model to improve security and reduce risk. But even with repositories in place, shadow downloads still happen, often silently:
-
Developers may not realize the repo exists so they continue to go directly to the public registry for local builds.
-
Misconfigurations or CI/CD complexity can bypass it.
-
Some tools default to fetching from public sources unless explicitly blocked.
And when that happens, malicious components can slip in before any security controls have a chance to intervene.
The rise of malicious open source
This isn't just about vulnerable packages — it's about malicious ones. That's a different threat class entirely.
-
Vulnerabilities are usually accidental.
-
Malicious components are intentional, designed to exploit trust in open source and developer tooling.
These threats are particularly insidious because they target where developers work:
-
Local machines with stored credentials
-
CI/CD pipelines tied to production
-
Tools that touch internal systems and infrastructure
And attackers have gotten smarter. They know how traditional tools work and how to sidestep them. They create packages that execute on install, before scanners ever run. Worse, they're now using AI to automate and scale these attacks.
Real-world examples
These aren't theoretical risks. Here are just a few real-world incidents:
-
pygrata-utils: A fake Python utility that exfiltrated AWS credentials, SSH keys, and .gitconfig contents on install.
-
Typosquatted npm packages: Lookalikes like lodashs and reacts delivered remote access shells to attacker-controlled hosts.
-
Malicious Hugging Face models: PyTorch models embedded with pickled malware that executed upon loading.
These packages didn't sneak in through obscure channels. They came in through developer tooling — the front door.
When the perimeter breaks
If you've been through a breach, you know what it feels like.
The roadmap pauses. Team meetings turn into incident reviews. You dig through logs, wondering: Was it me? Even if it wasn't, the weight often lands on the developer. And the cleanup is slow, painful, and public.
The most frustrating part? The roadmap rarely shifts. You're still expected to deliver, just now with more process, more guardrails, and less freedom.
From perimeter to estate: Rethinking developer protection
We don't need to panic. But we do need to evolve, and that means rethinking where and how protection happens.
Binary repositories are a critical control point, but they're just one part of the story. Modern attacks don't respect boundaries. They flow from edge to endpoint, and into the dev environment itself.
A new generation of tools is emerging that embraces this reality. They bring protection not just to the repository, but to the edge (where developers connect), and to the endpoint (where malicious packages often execute). This layered approach is known as defense in depth, and it's exactly what the current threat landscape demands.
Security can't be bolted on after the fact. It needs to be built in — into the infrastructure that developers already use. Because if protection doesn't live where developers live, it's already too late.
Whether you're in development, DevOps, or security, it's time to demand more from the systems that support your software. Better defaults. Smarter infrastructure. Real protection across the whole estate.
The bottom line
Attackers don't always break in — more and more, they're invited in through a shadow download.
Developers are the new perimeter. And while we didn't ask for that responsibility, it's ours all the same.
The good news? We're not powerless. We can ask better questions. We can build for resilience. And we can lead the shift toward infrastructure that protects developers by default — not as an afterthought.
Because what we don't know can hurt us. But what we do know, and act on, makes all the difference.
Written by Mitchell Johnson
Mitchell has more than 25 years of experience as a developer, architect, team-builder and leader across a variety of high-growth roles in technology, data, product, and mergers and acquisitions, including stints at eVestment a Nasdaq Company, Equifax, Grant Thornton and Delta Air Lines. Mitchell ...
