Due to many ecosystem attack incidents, package managers (and packagers, and managers) are apparently falling in love with cooldowns these days (npm, pnpm, yarn and so on). As a result, their upstream registry is time-gated for some 7 days or 24 hours.
Sounds sweet as honey. Except that it is not going to work. I'll say it's not honey, but a honeypot that traps.
Some are waiting for the community to "vet" the package before installing it. However, people don't know what's the appropriate cooldown time (e.g. 7 days for yarn, 3 days for pnpm). Also, a spoiler: people have no idea who would vet, either.
The implicit assumption is that someone out there (in the community) will:
But the reality isn't that generous. If everyone sets a cooldown, there will be no early adopter. Everyone is waiting for everyone else to be the canary, and the canary does not exist.
So they are waiting for Godot, and… Godot is not coming.
Some others use a pipeline or some CI/CD (yes, not necessarily human) that pulls the latest package through some dependabot PR.
When there is malicious code, one of the two results will happen (depending on whether the CI is exploitable/valuable):
And the PR gets merged and devs hit npm install without a second thought. Since nobody and nothing looks at the still-untrusted code (reading package-lock.json does not count!), people and machines are unaware of the issue before installing, and malicious code is only found when the impact starts to show. Needless to say it would be too late.
In a word, waiting without taking action doesn't work. But what to do instead? I would suggest "Do Your Own Research":
Stop cooling down or laying flat. Instead, start active scanning, so it's no longer a movie in the security theater.
Source: Hacker News — This article was automatically imported from the source. Read full article at original source →
