Your Kubernetes estate emits no telemetry for a technique your Windows fleet detects - how should that coverage cell read?

## Three colours are not enough states The usual heatmap offers covered, partial and not covered. That vocabulary has an assumption baked into it: that every cell is a detection problem, and the difference between cells is how much detection work has been done. For a large part of a modern estate that assumption is false, and the falsehood is flattering. A cell needs at least four states: - **Covered**, at a stated assertion level. - **Not detected, but observable** - the log source is collected, nothing is watching it. Detection engineering owns this; it costs days. - **No visibility** - the estate emits nothing that would ever show the behaviour. A platform, endpoint or infrastructure team owns this; it costs a deployment, an ingest bill, sometimes a performance budget and a change window. - **Not applicable** - the behaviour cannot occur on this platform at all. Only the first two are SOC work items. Collapsing the third into the second sends the gap to a team that cannot fix it, and it will sit unfixed while looking like a backlog item. ### Why Kubernetes is the sharp case The Kubernetes API server audit log is a record of *requests made to the API*: who called it, what resource, what verb, what the outcome was. It will show a `create` on a pod, and it will show an `exec` subresource request against a running pod. What it will never show is a process started *inside* a container - that is below the API entirely. Container runtime and in-container execution telemetry comes from a different mechanism: a node-level sensor, kernel-level instrumentation, or runtime security tooling deployed to the cluster. So an execution technique that is green on the Windows endpoints, where a process-creation record with the command line exists, is not merely un-ruled on the container platform. It is unobservable there until somebody deploys something new. No amount of query writing changes that, and a red cell implies otherwise. ### The state that flatters, and how it gets chosen The most common quiet dishonesty in this artefact is marking an un-instrumented platform *not applicable*. It reads as rigour - we scoped it out - and it removes the cell from the denominator, so the coverage percentage goes up rather than down. But not-applicable is a claim about the behaviour (it cannot happen here) and no-visibility is a claim about the sensors (it can happen and we would not know). One is a fact about the platform; the other is a fact about your budget. Getting them the wrong way round is how an estate ends up reporting ninety per cent coverage of an environment it cannot see into at all. ### What you owe a cell once you mark it no-visibility A state with no obligations attached becomes a permanent parking space. The minimum is: - **The missing source, named.** Not "container visibility" but the specific mechanism that would produce the record. - **An owner outside the SOC.** The team that can actually deploy or enable it. - **A cost and a lead time.** Ingest volume, licence, change window, performance impact. This is what turns the cell into a decision somebody can make. - **A date.** Either the date it will be fixed by, or the date the decision not to fix it gets reviewed. - **The compensating position, if any.** What you would still see: an outbound connection at the network layer, a control-plane action the workload took afterwards, an identity artefact. Usually something remains, and saying what it is turns a blank cell into a partial one at a different layer. At that point the gap has stopped being a colour and become an owned item, which is the only form in which it ever gets closed. ### One number over three platforms The same discipline kills the single estate-wide percentage. A technique that is validated on managed Windows endpoints, un-ruled on the Linux fleet and unobservable on the container platform is three different facts, and the coverage figure that averages them describes no environment that exists. Report per platform, or report the worst, and be explicit about which you did. If a reader wants one number, the number they need is the one for the environment their data actually lives in. ### What this changes about how you work the gap Separating the states also changes the sequencing. Detection gaps can be worked continuously by the team that owns the rules. Visibility gaps have to be argued for, budgeted, scheduled and rolled out, and they block every detection that would sit on top of them - so a visibility gap on a platform carrying real workloads outranks a dozen missing rules on a platform you can already see, even though the heatmap draws them the same size.