A state-sponsored supply chain attack recently hit Notepad++—a free Windows text editor used by millions of developers worldwide. The attack wasn’t through code vulnerabilities. It was an infrastructure-level compromise at the hosting provider, where malicious actors intercepted and redirected update traffic to compromised manifests.
Targeted users selectively received malicious updates containing “Chrysalis”—an espionage-grade backdoor capable of executing commands, reading, writing, and deleting files, maintaining persistence, and uninstalling with minimal forensic evidence.
This is a big deal. And it’s not going to be the last time we see something like this.
The Hidden Fragility of Modern Software
It’s amazing how much of the software we use every day runs on dependencies maintained by single individuals or tiny teams. That open source library your website relies on? It might be maintained by one person in their spare time. The package that handles your payment processing integrations? A small team of volunteers.
We’re going to see a lot more supply chain attacks—especially with the rise of “vibe coding” and AI-assisted development. When developers (or AI tools) rapidly pull in packages without careful vetting, the attack surface grows exponentially.
This is something anyone running digital services or online platforms needs to be aware of, particularly if you’re using tools to build your own apps, plugins, or integrations.
Understanding Supply Chain Attacks: A Simple Analogy
Imagine you’re sourcing ingredients from a market to make pizzas. You generally trust your suppliers. You might carefully vet them at the start, but then you simply accept what they send each week. Maybe they quietly change brands or tweak their supply a little—you keep buying and don’t ask too many questions.
But you don’t really check, do you?
So if someone swapped your flour for a lower grade, watered down your tomatoes, or your supply chain got compromised with something contaminated… you’d never know until it was too late.
That’s pretty much what can happen with software dependencies. You trust a package, install it, and then automatically accept every update. If that package—or the infrastructure delivering it—gets compromised, malicious code flows straight into your systems.
How to Protect Yourself
1. Don’t Let Updates Happen Automatically
Cut off the blind trust. Automatic updates are convenient, but they also mean you’re automatically accepting whatever gets pushed to you—good or bad.
The trade-off here is that you might miss more urgent security updates when critical issues are found. So this isn’t about never updating—it’s about being intentional about when and how you update.
2. Build Verification Into Your Workflow
This is something everyone should be building into their workflows now, especially with the rise of AI tools that can rapidly generate and integrate code.
For example, you can run hooks that trigger every time you push new code. These can automatically scan dependencies for known vulnerabilities, check for unexpected changes, or flag packages that have recently changed ownership.
You can do this with existing tools—you don’t necessarily need to buy something off the shelf. GitHub’s Dependabot, npm audit, and similar tools are free and effective starting points.
3. Use Services That Harden and Protect Your Packages
There are tools specifically designed to scan and validate new releases before they hit your systems. These services can:
- Generate Software Bills of Materials (SBOMs) so you know exactly what’s in your software
- Monitor for vulnerabilities in your dependency tree
- Alert you when packages change ownership or behaviour
- Provide private package mirrors that you control
4. Avoid External CDN References Unless Necessary
99.9% of the time, CDNs are totally fine. But all it takes is one to be compromised, and suddenly malicious code is being served to your users.
If it’s a simple piece of JavaScript, CSS, or a basic snippet, it’s probably better to pull it into your codebase rather than referencing a CDN link that’s vulnerable to supply chain attacks. You control what’s in your repository—you don’t control what’s on someone else’s server.
Check the licence first, of course, to ensure you’re allowed to include the code directly.
The Bottom Line
Blindly accepting and downloading packages is how a lot of developers operate—not just newcomers using AI coding tools, but experienced developers too. There’s real risk here.
The Notepad++ attack is a reminder that supply chain compromises aren’t theoretical. They’re happening now, they’re sophisticated, and they can affect tools we’ve trusted for years.
Take the time to audit your dependencies, build verification into your workflow, and think carefully about where your code—and your trust—comes from.
Author
