Sabitlenmiş Tweet
The uncomfortable part of the npm supply-chain problem is not that packages can be poisoned.
We knew that.
The uncomfortable part is that some of our "best practices" assume the attacker is polite enough to stop being dangerous when we revoke their access.
The answer may surprise you...
And the answer is bad.
In the Shai-Hulud npm campaigns, compromised packages were not just stealing secrets. They were using those secrets to keep moving.
- GitHub tokens.
- npm tokens.
- Cloud credentials.
- CI/CD secrets.
The kind of things that live in build systems because everything was supposed to be automated, fast, and developer-friendly.
Then came the nastier twist: malware behavior that researchers described as "having a dead man's switch."
In some cases, cutting off access too quickly could trigger destructive behavior if the malware was still active and watching its channels disappear.
Which makes the normal incident response reflex weird, fast.
"Revoke the token" is still correct.
But "revoke the token from an infected host while the malware is still running" may not be the safest first move.
That sequence matters.
A poisoned package is not just a bad dependency.
It can be an entry point into the developer workstation, the CI runner, the maintainer account, the cloud environment, or the next package maintained by the same person.
That turns dependency hygiene into an executive risk conversation.
Not because every CEO needs to know what package-lock.json does.
Please no.
Some of us are still recovering from explaining DNS.
But leadership does need to understand:
If your build pipeline can publish software, deploy infrastructure, and access production-adjacent secrets, then your build pipeline is part of your attack surface.
Not a developer convenience.
An attack surface.
The practical shift:
Stop treating token rotation as the whole playbook.
It is one step in a controlled response.
A better order looks more like:
1. Isolate the suspected host or runner.
2. Stop automatic installs, builds, and publishes.
3. Preserve enough evidence to understand what ran.
4. Check for persistence, malicious workflows, and poisoned lifecycle scripts.
5. Rotate credentials from a clean environment.
6. Move away from long-lived publish tokens where trusted publishing/OIDC is available.
7. Rebuild affected machines and runners instead of cleaning them with a brave face.
The brave face is where the incident report gets... "spicy."
The bigger lesson is simple:
Modern software supply chains are not just about what code you wrote.
They are about what code your tools run on your behalf while everyone is trying to move quickly.
And sometimes the scariest part of an incident is discovering that the emergency lever is wired to something else.
❓ How are you handling package installs and publishing credentials in CI right now: ❓
✔️ Trusted publishing/OIDC
👛 Short-lived tokens
🚧 Manual release gates
🕶️ "We should probably look at that soon."
GIF
English
