Contents (5 sections)
There is one question we always ask during an audit, and it rarely takes less than ten minutes to answer: how many container images are running in your environment, exactly? Not “roughly”, not “the ones in the production docker-compose”. The number. In most fleets, nobody knows, because nobody has ever needed to know, until the day someone has to answer “are we exposed to this vulnerability?”
We asked ourselves that question a few days ago. The answer took us an evening, and it was worth it.
The previous setup: accurate, and yet wrong #
Each host analysed its own images locally and reported its results. On paper, it is common sense: the analysis happens where the images live, the load is spread out, no data moves around. Each machine gave an accurate verdict about itself.
The problem was not the accuracy of each measurement, but what we did with it. Twenty-five local analyses produce twenty-five figures. They never produce the figure for the fleet. There was no way to answer “which version of this database is still running somewhere?” without querying twenty-five machines one by one, and without being sure we had not forgotten any.
Centralising again, and counting properly #
We replaced the local analyses with a single analysis, run against the real inventory of the container fleet. The difference in coverage is the first lesson: 111 unique images, where the previous setup examined only 25 local databases. It is not that 86 images were vulnerable and ignored; it is that 86 images were not being looked at by anyone, and the vast majority of them were perfectly fine. But we did not know that.
The second lesson concerns prioritisation. Not all vulnerabilities are equal, and sorting by theoretical severity is a poor guide: a “critical” flaw in a component no attacker exploits in real life gets ahead of a “medium” flaw that is actively being used. The right filter exists: the KEV catalogue from the US CISA, which only lists vulnerabilities whose exploitation has been observed in the wild.
Our scanner had stopped exposing this information in a recent version. So we went and fetched it directly from the official catalogue and cross-referenced it with the results ourselves. It takes three lines of processing, and it turns a list of hundreds of entries into a handful of things to do this week.
446, then zero #
Once the inventory was accurate and the sorting useful, the fixing work became manageable. The fleet counter went from 446 vulnerabilities to 0 in one evening.
That figure needs an honest qualification, or it means nothing. It does not mean we fixed 446 code defects one by one. It means that 446 findings concerned outdated base images, and that once the inventory was known, rebuilding them all cleared most of it in one go. The hard part was not the fixing. It was knowing what to fix.
You cannot patch what you have not inventoried. And you do not build an inventory by asking each machine to describe itself.
The sensor and its output #
That leaves the question of output: to whom, and at what threshold? This is the part we most often see rushed, and the one that decides whether the setup is any use.
A sensor whose output has not been thought through produces noise, and weekly noise that people end up ignoring is worse than silence: it gives the feeling of being monitored without actually being so. So we connect the output after checking that the signal is clean, with a simple rule: the summary only goes to team channels if there is really something to report. A healthy fleet produces no messages at all. That is deliberate, and it is why people still read the messages when there are some.
What changes for you #
If you entrust us with your hosting or your server and application management, this project has three concrete consequences, and they can be checked:
- We can answer “am I exposed to this vulnerability?” in a minute, because the inventory exists and is up to date, not because someone remembers what runs where.
- Prioritisation is based on real-world exploitation, through the KEV catalogue, not on a theoretical score. You do not pay for engineering time on vulnerabilities nobody exploits.
- The figure is a measurement, not a promise. “We patch regularly” commits nobody to anything. “446 then 0, on a given date, across 111 images” can be checked.
And if you manage your own fleet, the question to ask yourself tonight is not “am I up to date?”. It is: do I know what I have? As long as the answer is no, every other figure is an opinion.
