Comment by zelphirkalt
2 days ago
This is why one should pin all direct and transitive dependencies with their checksums and not upgrade everyday willy-nilly. There is no need to specify the specific version numbers of transitive dependencies, if one keeps a lock file that pins those exact versions and checksums of transitive dependencies, and one doesn't upgrade willy-nilly all the time. Make upgrading dependencies a conscious choice, and perhaps have a policy of at most upgrading every X days.
I don't think it's accurate to envision that the average team using the npm ecosystem is upgrading their dependencies daily. Rather, the problem is that modifying your direct deps (e.g. adding a package, upgrading a package) requires modifying transitive deps.
So yeah, ~everyone is using a lockfile with checksums. But even if I think really hard about installing XYZ@1.2.3 package, and check that the lockfile diff is reasonable, I'm not manually auditing the whole supply chain (I'd get fired for getting nothing done). And a single dependency change that I choose to make can affect a substantial number of transitive deps.
My idea is, that they do _not_ upgrade their dependencies daily, because that is what is causing the issue. People don't pin all their versions and checksums properly, and the next time they run `npm install` they get a new version of some library. I don't even want to see any "@^1.2" or whatever the syntax was. Also they should be running `npm ci`.
I have seen this multiple times with people from various backgrounds and in frontend as well as backend. People still think like "Lets auto upgrade patch releases, so that we always get the bugfixes." or "Lets upgrade quickly, so that we deal with changes right away, before accumulating the work.". But they don't think properly about security and reproducibility.