Comment by electroly
2 months ago
That's only a problem for you, the developer, though, and is merely an annoyance about time spent. And it's all stuff you had to do anyway to update--you're just doing it all at once instead of spread out over time. A supply chain malware attack is a problem for every one of your users--who will all leave you once the dust is settled--and you end up in headline news at the top of HN's front page. These problems are not comparable. One is a rough day. The other is the end of your project.
The time upgrading is not linear, it’s exponential. If it hurts, do it more often! https://martinfowler.com/bliki/FrequencyReducesDifficulty.ht...
A log4j level vulnerability happens again. Do you need 10 minutes to update? 1 hour? 1 day? 1 week? Multiple months? The more you are drifting behind on updates, the worse it gets, which also affects every one of your users, your business, and might be the end of your project.
> A log4j level vulnerability happens again. [...] The more you are drifting behind on updates, the worse it gets
That one is a funny example in this context. If you were drifting far behind on updates, so far that you were still on the obsolete log4j 1.x, you were immune to that vulnerability (log4shell). That obsolete log4j version had other known vulnerabilities, but most of them on rarely used optional components, and none of them affected basic uses of it to log to the console or disk. And even better, there were so many people using that obsolete log4j version, that a binary compatible fork quickly appeared (reload4j) which just removes the vulnerable components (and fixes everything that wasn't removed); it takes 10 minutes to update to it, or at worst 1 hour if you have to tweak your dependencies to exclude the log4j artifact.
(And then it happened again, this time with Spring (spring4shell): if you were far behind on updates, so far that you were still on the very old but still somewhat supported Java 8, you were immune to that vulnerability.)