Told the estate is fully patched, how do you separate hosts that received a fix from hosts running it?

## The two numbers Every estate has two patch percentages for any given fix: - **Received**: hosts where the fixed package, image or firmware file is present. This is what package databases, deployment systems and most quoted numbers describe. - **Running**: hosts where the fixed code is what the processor is actually executing. These are never equal, and the gap is not noise. It is concentrated in exactly the hosts you least want it in: always-on virtualisation hosts, appliances in a change freeze, machines that are only ever suspended and resumed rather than restarted. Received will sit in the high nineties because distribution is easy and automated. Running trails it by whatever share of the estate has not restarted the relevant unit since the fix landed. ## The one comparison The separating question is the same on every platform: **did the unit that must load this code start after the fix landed on this host?** Instantiated per surface: | Fix surface | The comparison | The unit that must restart | | --- | --- | --- | | Kernel | Running kernel build identity, or boot time after the fixed kernel install | Boot | | Userspace shared library | Start time of every process mapping it, against library install time | Each process | | A single service's binary | Service start time against install time | That service | | Device or platform firmware | Running version against staged version | Power cycle | | Management controller | Its own running firmware version | Its own restart, off the host cadence | Notice that four of the five rows are answerable from host state you can read without touching the flaw itself, and none of them is the installed package version. ## What to accept as proof Be explicit, because this is the part interviewers are listening for: 1. **Per-host facts, not an aggregate.** A percentage hides its denominator and hides which hosts are in the tail. The tail is the answer. 2. **The denominator is the whole managed population**, including hosts that are never restarted and appliances excluded from the usual sweep. If the always-on hosts are outside the count, the number is measuring the hosts that were never the problem. 3. **Running-code identity, not installed-code identity.** Boot time, process start time, running firmware version. 4. **A named exception list.** Hosts that cannot be brought into the running population get named individually with an owner, not averaged away. And say what you will not accept: a green tick from a distribution job, a closed change record, or the sentence "the version is current", all three of which are true of a host that is still executing the vulnerable code. ## Why the un-restarted host is the interesting one The reason to insist on the second number is not tidiness. Consider one identity's worth of access already present on a management segment, used by an operator with time and no revenue clock. That operator does not need a new flaw; the estate is generating stale hosts on its own, and the fixed-but-never-restarted population is a standing supply of them that no one counts as unpatched. Meanwhile an ordinary administrator postponing a power cycle on a hypervisor for a perfectly sound business reason produces the identical host state. From the version number alone the two are indistinguishable - which is the argument for measuring the state rather than the intent. ## The reviewer's script When handed "we are fully patched, so we are fine", the useful reply is one question and one request. The question: "is that installed or running?" The request: "give me boot time and the running kernel build for every host, and the list of hosts whose uptime predates the fix." If the second list is empty on an estate with virtualisation hosts in it, the list is wrong, not the estate.