Seems like one way to do this is update your lock file and submit a PR today, but don’t merge it until N days have passed. Seems easy to automate too.
“cooldown” is exactly what it sounds like: a window of time between when a dependency is published and when it’s considered suitable for use. The dependency is public during this window, meaning that “supply chain security” vendors can work their magic while the rest of us wait any problems out.
Pinned (major.minor.patch) versions and ignore-scripts should be the default. It’s insane that the default is to execute untrusted code from the Internet.
It reminds me of back when IE would let me download a bat file and execute it
/Getoffmylawn
I mean, modern package managers generally now come with lock files, which effectively auto-pin your dependencies, until you trigger a dependency update.
And while it isn’t bullet-proof, it does result in you effectively having a dependency cooldown most of the time. You’re only vulnerable, if you trigger the dependency update while the compromised dependency release is public.
Obviously, this can be bad enough, but it does also mean that an ecosystem with lock files is far less attractive to target with a supply-chain attack, since far fewer hosts will get compromised on average.
Color me curmudgeon, but automated dependency updates should never be a consideration.
Also, one thing I do like that Github does is that it can be configured to send you a report of dependency changes (in yarn, for example).
pnpm has minimumReleaseAge https://pnpm.io/settings#minimumreleaseage
Been using renovate a while, 42 added this as a default!
minimumReleaseAge: 3 dayswill now be set by default for npm inconfig:best-practices
