Ramblings of an aging IT geek
← Ramblings of an aging IT geek
news

Another Week, Another Disclosure, and the Same Tired Scramble

A widely-discussed vulnerability this week, and why the patching scramble matters less than the question of how we got exposed.

A news ticker on a screen

This week my feeds have been wall to wall with the same disclosure, the sort that arrives with a logo and a name and a countdown of vendors rushing out advisories. I'm being deliberately vague on the specifics because by the time you read this the version numbers will have shifted and the real story won't be the bug at all. The pattern is what's worth talking about, and the pattern is depressingly familiar.

A widely-used component turns out to have a flaw. It's serious, it's remotely reachable, and it's in something that everyone depends on without quite remembering they do. The advisory lands, the proof-of-concept follows within a day or two, and a few thousand teams discover simultaneously that they don't have a clean answer to "where do we run this, and which version".

That last question is the whole game, and it's the one most of us still can't answer quickly.

A city skyline at dusk

I spent Wednesday morning doing what everyone else was doing. Grepping lockfiles, querying the asset inventory, cross-referencing it against the container images we actually ship, and discovering, as always, that the inventory and reality had drifted. The patch itself was the easy part. The hard part was building confidence that we'd found every place the affected thing lived, including the box someone stood up two years ago for a migration and never decommissioned.

Here's the thing I keep coming back to, and it's not a popular opinion in the heat of a response. The speed of your patching matters far less than the quality of your inventory. A team that can say with certainty "we run this in exactly these four places, and three of them aren't internet-facing" is in a vastly better position than a team frantically patching everything because they're not sure. Panic patching is just inventory debt coming due, all at once, at the worst possible moment.

I'm not going to pretend I've solved this. Our inventory is better than it was and worse than it should be, and every one of these events exposes a new gap. But the lesson I take from each one is never "patch faster". It's "know what you have". The disclosure this week will be forgotten in a fortnight. The boxes you didn't know about will still be there for the next one.

So once the immediate fire is out, the useful work isn't writing a postmortem about the CVE. It's the unglamorous job of making sure that next time, the answer to "where does this run" takes minutes and not a whole stressful morning. That's the bit nobody puts a logo on, and it's the only bit that actually compounds.