Comment by ef2k
18 hours ago
The issue was a compromised build pipeline that shipped a poisoned package.
But PSA: If something is critical to the business and you’re using npm, pin your dependencies. I’ve had this debate with other devs throughout the years and they usually point to the lockfile as assurance, but version ranges with a ^ mean that when the lockfile gets updated, you can pull in newer versions you didn’t explicitly choose.
If what you're building can put your company out of business it's worth the hassle.
This is one reason why we have lock files / version pinning
But it goes the other way too. If there's a security vulnerability that was fixed in a later version, you want the system to automatically pick that up and apply it for you in an ideal scenario.
Even with ^ you won't get an updated version until somebody runs an install and updates the lockfile.
We have things like dependebot for this.
https://docs.github.com/en/code-security/tutorials/secure-yo...
At this point, the risk of a compromised package outweighs the risk of an upstream vuln that actually matters. Npm audit is full of junk like client side redos vulns, you could probably ignore 90%+ of the reports and still be secure against the majority of of-concern attack classes.
Why would you patch a security vuln in a later version? Should be patched in all versions.. that's what semver is for.
A patch updates is a newer version, and they are just as likely to be compromised by supply chain attacks as minor or major updates.
2 replies →
Who is 'you' here? All of the npm package maintainers?
Yes, if they all just backport security patches we'll be fine. No, people are not going to just.
Ah yes the incredibly common practice of... checks notes backporting security packages in node packages.
Semver doesn't help if you just declare all older versions EOL.
What you're looking for are Debian stable packages. :p
[dead]