Your ATT&CK coverage matrix is lying to you
Most coverage matrices measure the wrong thing. Here is what we changed to make ours mean something, including the part where it got worse.
Mohamed Nofal
Founder&CEO · 11 August 2026 · 4 min read
Every security vendor shows you an ATT&CK Navigator screenshot. Most of them are green. Ours used to be green too, and it was telling you almost nothing.
Three ways a coverage matrix lies
It counts techniques you cannot possibly see
The Enterprise matrix spans Windows, macOS, Linux, cloud, containers, network devices and mobile. A Linux runtime sensor cannot observe registry modification. It cannot observe LSASS memory access. It cannot observe anything on a domain controller.
If those techniques are in the denominator, coverage is being diluted by things that are not failures. If — worse — they are in the numerator because a mapping table says a rule "relates to" them, the number is fiction.
What we changed. The matrix is scoped to techniques a Linux, Kubernetes and cloud runtime sensor can observe. Everything else is absent, not grey. The denominator shrank from 600-odd to 78, and the honest percentage dropped by a lot.
It counts rules, not signal
A technique with one rule mapped to it is "covered". A technique with one rule that has never fired, was written against a field the sensor stopped populating, and is disabled in three of your four policies is also "covered".
What we changed. A cell reports the number of enabled rules, and the coverage matrix reads probe state as well as rule state. If a rule depends on OCSF class 1005 and the module_load probe has failed to attach on 40% of the fleet, that technique is not covered on those hosts, and the matrix says so per-segment rather than globally.
That change made our own matrix worse, on a Tuesday, in a way that generated a productive argument.
It has no idea what is actually happening
A green matrix with no activity data is a statement about your content library, not about your environment. It cannot distinguish "we can see this and it is not happening" from "we can see this and we are not looking hard enough".
What we changed. Two modes on the same grid. Coverage heats by enabled rules; activity heats by findings raised in the window. Reading them together is where the value is:
| Coverage | Activity | Reading |
|---|---|---|
| Strong | Quiet | Working as intended. The steady state. |
| Strong | Hot | Something is happening. Go look. |
| None | Hot | Findings from adjacent rules only. Urgent content gap. |
| None | Quiet | Blind spot. Not urgent, but unknown — and unknown is not the same as safe. |
The third row is the one that pays for the whole feature. It means your detections are catching something adjacent to a technique you have no direct coverage for, which is a specific, fundable piece of work rather than a vague sense that the programme could be better.
Sub-techniques, and the temptation to round up
T1059 Command and Scripting Interpreter has nine sub-techniques. A Linux sensor sees two of them well: .004 Unix Shell and .006 Python.
The tempting move is to map your shell rule to the parent T1059 and colour the whole thing green. We did that for about six months.
Now we map to the specific sub-technique, and the parent inherits partial coverage — visibly partial, at a lower heat level. A cell for T1059 that is 60% saturated because two of its nine children are covered is a more useful thing to look at than a cell that is fully green because one of them is.
What the number is for
The number is not a score. It is a way of finding the specific gaps worth funding this quarter.
Our own matrix, at the time of writing, is 68%. The 32% breaks down into three groups:
- Techniques we can observe but have not written content for. This is the backlog, and it is the honest answer to "what would you do with more detection engineering time".
- Techniques we can observe only partially — enough to detect the loud version, not the careful one. These are flagged as minimal rather than covered, because "we would catch a script kiddie" is different from "we would catch an operator".
- Techniques where our current answer is a correlation rather than a direct detection, which means they are sensitive to the sampling policy on the host.
That is a more useful sentence than "68%". It is also a more useful sentence than a screenshot of a green wall, which is why our marketing pages show the matrix with its gaps in it.
If a vendor's matrix has no gaps, ask what is in the denominator.