Comment by flyingjoe
1 day ago
A few month ago, everyone was advising to use cool-downs in your package upgrades. Now we're constantly overriding those because security incidents will be exploited immediately. Guess that's just how it's gonna be from now on.
That's why it's important to practice your processes for both shipping quickly and overriding cooldowns. There's a baseline of things which are not easy to exploit where you want to patch on a regular cadence and the risk posed by a supply chain attack is greater than the risk of an attacker having enough of a footprint inside your systems to escalate. The fact that sometimes you have a specific situation like this where that's not true doesn't mean that 9 times out of 10 the cooldown was the better risk-reduction strategy.
It used to be a flex to say you deploy daily but it’s going to become a necessity just to keep up with the vulns
CI/CD — Continuous Incidents, Continuous Defense.
Yeah, obviously? Deploy fixes to security issues which apply to you as soon as possible, deploy random feature additions and non-critical bug fixes after some cooldown.
As always, the easiest way to manage this is to have as few dependencies as possible. If you have a lockfile with thousands of entries, you won't be able to go through them and decide which upgrades are legitimate urgent security updates and which can wait. If you have 10? You'll manage.