There is a particular rhythm to a big disclosure week, and we are deep in one. A serious flaw lands, the advisory goes up, the security press picks it apart, and within a day there is a logo, a name, and a wave of articles all explaining the same three paragraphs in slightly different words. By the time it reaches the group chat it has acquired a kind of folklore: it does everything, it is in everything, you are already owned. The truth is usually narrower and more annoying than that, and the narrow annoying version is the one that actually decides whether your weekend is ruined.
I am being deliberately vague about the specifics, partly because by the time you read this the details will have shifted, and partly because the thing I want to talk about does not depend on which flaw it is. The pattern repeats. So rather than add to the pile of explainers, I want to write down how I actually work through one of these when it lands on a Tuesday and the question from upstairs is the same as it always is: "are we affected?"
The patch is the easy part
The instinct, and it is not a bad one, is to grab the fix. Bump the version, roll it out, close the ticket. Patching is the part everyone understands and the part the advisory tells you to do in bold at the top.
But "apply the patch" assumes two things you have not yet established. The first is that you know everywhere the affected thing runs. The second is that the affected thing is actually reachable in a way that matters. Both of those are inventory problems, and inventory is where most organisations quietly fall down, because it is unglamorous and nobody gets promoted for keeping an accurate one.
I have lost count of the times the answer to "are we affected" turned out to be "yes, but not where we looked first." The production fleet is patched within the hour because production is watched. The thing that bites you is the forgotten box: the build agent someone stood up two years ago, the appliance with a vendored copy of the library baked in that you cannot update without the vendor, the container base image three layers down that nobody has rebuilt since spring. The disclosure did not create that exposure. It just switched the lights on in a room you had stopped going into.
Reachability, not presence
Here is the distinction that saves you from a panicked all-nighter, and the one that the headline coverage almost never makes. Having the vulnerable code somewhere is not the same as being exploitable.
A flaw in a parser only matters if untrusted input reaches that parser. A flaw in a network service only matters if something untrusted can talk to that port. Half the work of triage is drawing the line from "where does the bad input come from" to "where does the bad code live" and asking whether that line actually connects. Sometimes it does and you stop everything. Often it does not, and what looked like a five-alarm fire is a library buried behind three layers of authentication that never sees a hostile byte. That does not mean you skip the patch. It means you can patch it on Thursday in business hours rather than at two in the morning, and that difference is the whole game.
So my running order, every time, looks roughly like this:
- Find every place the affected component runs, including the copies you did not install on purpose: base images, vendored dependencies, appliances.
- For each one, work out whether untrusted input can reach the vulnerable path.
- Sort by reachability, not by where the patch is easiest.
- Patch the reachable ones now, schedule the rest, and write down the ones you cannot patch so they are a decision rather than an oversight.
The uncomfortable mirror
What these weeks really expose is not the flaw. It is the state of your own house. A disclosure is a surprise inspection you did not schedule. If you can answer "where does this run" in twenty minutes, you have a good inventory and you will be fine. If answering it takes two days of grepping deploy scripts and asking people who left the company, the disclosure is not your problem. It is the symptom, and your problem is that you did not know what you were running.
The reassuring thing, and I do mean reassuring, is that the fix for that is boring and entirely within your control. Keep an inventory. Rebuild your base images on a schedule instead of when something forces you. Know which of your dependencies are vendored and therefore will not update themselves. Have a written list of the things you cannot patch and why, so that when the next logo arrives you are reading from a map instead of drawing one.
None of that is exciting. None of it makes a good headline. But the people who got through this week without a sleepless night were not cleverer or faster. They had simply done the dull work in advance, so that when the alarm went off they were checking a list rather than discovering, live and in public, what they actually owned. I would rather be in that camp, and most weeks I am only half there, which is why I am writing this down where I will have to read it again.