cat ./posts/supply-chain-fear.md
Supply chain attacks - they just keep coming
This is one of those threat classes that should be rare and dramatic, but somehow keeps turning up in places we treat as routine.
A routine dependency bump. Then suddenly the thing we assumed was safe is doing the damage.
The bit that gets me is that they are happening often enough to stop feeling exceptional.
Level setting
The basic idea is simple: if you can compromise something people already trust, you do not need to compromise every victim directly. You compromise the middle of a trusted path and let everybody else do the distribution for you.
That sounds neat in a very unpleasant way.
A few recent(ish) examples
xz
The xz backdoor attempt was the one that made a lot of people stop and stare.
It was buried in a widely used compression library and got a lot further than anyone wanted it to. Andres Freund's disclosure is still a reminder of how ugly this gets when a core dependency goes bad.
This one sticks with me - the impressive complexity of an attack that came so close to infecting Fedora 40. It makes me wonder what we might be missing?
Polyfill.io
When we want to use cool new browser tech, but we don't want to alienate users on old browsers (enterprise anyone?), we use polyfills. Polyfill.io used to be a common CDN for this - until they started serving malicious code in users' browsers. A trusted JavaScript dependency turned into a delivery path for malicious code, triggered by a change in site ownership.
If you were pulling it in, you probably didn't think you were inheriting someone else's compromise. That is the sort of thing we have to think about now.
Arch Linux's Arch User Repository (AUR)
In recent times there has been a flurry of npm/pypi supply chain attacks, but this is the most recent & scary at the time of writing. The dust is still settling, but it looks like ~400 AUR packages were claimed by a malicious maintainer, and started serving an infostealer and rootkit via a pre-install stage npm package installation.
I suppose this one hits close to home for me because I frequently update my system, have only recently switched from Arch, and I am pretty sure I used some of the affected packages. So that would have been me pwned.
Why this feels worse now
Part of it is just volume. CVEs keep coming. Dependencies keep changing. Everyone is under pressure to update fast, because leaving old code alone is its own kind of risk.
And now the updates themselves can be poisoned.
Of course, this is amplified by the cyber capabilities of models like Mythos. As these models become publicly available (or less powerful ones get abliterated), we will certainly continue to see risk increase.
Finally, trust is being delegated through more layers than most people realise: maintainers, registries, CDNs, build scripts, lockfiles, mirrors, and CI systems. Any of those layers can become a distribution mechanism.
What helps, a bit
There is no magic shield, but a few things buy you time:
- Use date-gated installs.
uv'sexclude-neweris handy when you want to avoid freshly published packages, and in my opinion all package managers should adopt this. - Pin hard and review the lockfile. Boring, yes. Useful, also yes.
- Prefer reproducible builds and signed artifacts when you can.
- Watch the install step. That is where a lot of the bad stuff hides.
Conclusion
Sometimes attackers only need one maintainer account. Worse, sometimes they can spend years becoming the trusted path themselves. Either way, then all that is left is to let it flow down the dependency tree.
I do not think that means we are doomed. I do think it means the old default assumption, that a package update is probably fine, is getting harder to justify - we are trying to secure an open source landscape built on trust while threat actors are weaponising exactly that.
I am starting to think about how to minimise impact when I get pwned. Implicitly I am shifting from "if" to "when" - maybe pessimistic, but it feels like the more realistic posture now.