You should not update your dependencies in 2026 | Mendral<br>The simpler times…

Rare historical photograph of a SysAdmin, an ancient species that would later evolve into modern DevOps, circa January 1999. The specimen, barely containing his excitement at the release of Linux 2.2 and the prospect of the upcoming LinuxWorld Expo, is performing the bi-yearly software patching ritual in production with his obligate mutualist (colloquially known as "the software vendor sales dude").

I started in tech in the late 90s after dropping out of college. My first metal server got compromised in two weeks. (Yes, phpMyAdmin . Yes, unpatched. Yes, still ashamed.)

Literally the first thing we deeply internalized in that era was to "very carefully review what you depend on, read all changelogs and patches, apply timely, always be up to date".

Pretty sure that sounds quaint, even alien, to most of the npm-dependabot-trigger-happy folks…

Nowadays, in the face of a sweeping, seemingly insurmountable onslaught of devastating supply chain incidents, some<br>package managers started recommending to not update dependencies before a certain number of days (just to make sure,<br>you know, that the idiots who go in front of you pay the price and spot the issues first…).

What has long been a staple of basic software security hygiene and vernacular wisdom is now considered harmful:<br>do not update too soon, or expose yourself to ongoing supply chain attacks.<br>Of course, not upgrading does expose you to active campaigns against (technically patched) upstream CVEs.

Damned if you do.<br>Damned if you don't.

The old operating model was indeed fine in a much smaller, simpler tech world, in a more controlled and siloed environment,<br>where you would depend on a handful of formally defined vendors that you could manually vet, and where complex supply<br>chain issues and larger-than-life dependencies list were… not even a sci-fi concept.

The massive shift towards open-source over the past two to three decades (in part sustained by a better security story:<br>"you benefit from much better community-driven scrutiny than with closed-source vendors!"… oh, sweet summer child…),<br>along with the exponential increase in the size of ecosystems, brought massive new issues to light, painfully revealed<br>through a chain of literally horrific "core dependencies" vulnerabilities (remember bind, openssl, or just log4j?)<br>that have basically broken the entire internet, repeatedly.

The first "realization", probably mid 2010s: open-source maintainers are not just free labor, they are also overworked,<br>under-equipped, wildly understaffed, and just as competent or incompetent as anyone else. Yet their work underpinned most<br>software out there (and still do).

Add to that the profound flaws and inadequacies of hopelessly naive package managers, and software distribution<br>as a category, the ineptitude of some of the new (very) popular stacks, and the increased pressure to race out<br>competitors in the corporate industry, altogether breeding a culture that kept just the appearance of the previous one<br>(the "always be fully patched" part), now devoid of substance, becoming essentially "just update everything, whatever it is, don't even look".

The notion of "supply chain vulnerability" became mainstream.<br>The wider industry response was for the most part throw-your-hands-up-in-the-air:<br>"We're on the latest version. Upstream will patch. What else do you want from us?"

The avant-garde would additionally engage with nicely packaged red-tape bureaucracy that did nothing to solve the root<br>causes of the actual problem but made us all feel better, spoon feeding the comforting illusion that we were in control<br>by creating additional work (for a nice little bundle of money of course): responsible disclosure programs and<br>grand proclamation security policies, embargoes, CVEs, and the god-holy CVSS (super useful, right? RIGHT?), compliance<br>processes, certifications…

Or in a more colorful language:<br>"maybe openSSL will have more issues, but we don't know how to fix it, let alone rewrite it, we have no idea what<br>exactly we use in it, and even if we would, we don't have time for that, and it would cost us more money than dealing<br>with the occasional global fallout, so, let's just keep leaching blindly whatever they ship, we will just be as<br>(in)secure as the rest of the world anyhow. Oh, hey, we are ISO certified."

Some form of "security in numbers (as long as I don't have to do anything)", as a twisted version of the original<br>open-source idealistic promise of mutually beneficial communities.

And before you claim you never were one of us : look me in the eye and swear you donate to your OSS upstreams,<br>and that you have never merge-bombed a Dependabot PR without reading the diff.

No you don't.<br>And yes you did.

From supply chain vulnerability to supply chain compromise: the end of trust

It should be obvious to the reader at this point, or to anyone who lived through the past ten years<br>(or anyone who has...