4 ms·
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 de
by ef2k 5mo 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.
- fragmede 5mo agoBut 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.
- kronks 5mo ago[dead]
- bfivyvysj 5mo agoWhy would you patch a security vuln in a later version? Should be patched in all versions.. that's what semver is for.
- jpleger 5mo agoAh yes the incredibly common practice of... checks notes backporting security packages in node packages.
- kijin 5mo agoSemver doesn't help if you just declare all older versions EOL. What you're looking for are Debian stable packages. :p
- raincole 5mo agoWho 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.
- pavon 5mo agoA patch updates is a newer version, and they are just as likely to be compromised by supply chain attacks as minor or major updates.
- dsl 5mo agoNot exactly. Security patches aren't like bugs or features where you can just roll a new version. Often patches need to be backported to older versions allowing software and libraries to be "upgraded" in place with no other change introduced. Say you had software that controlled the careful mix of chemicals introduced into a municipal water supply. You just don't move from version 1.4 to 3.2, you fix 1.4 in place.
- thfuran 5mo agoNo, you create version 1.4.19, which fixes a bug in 1.4.18.
- hsbauauvhabzb 5mo agoAt 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.
- TranquilMarmot 5mo agoEven 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-your-dependencies/dependabot-quickstart-guide https://docs.github.com/en/code-security/tutorials/secure-yo...
- jbverschoor 5mo agoThis is one reason why we have lock files / version pinning