Every detection vendor ships a MITRE ATT&CK heatmap, and every one of them is mostly green. Broad coverage, techniques lit up across the board, a reassuring wall of color in the sales deck and the board slide. It's the universal flex. We cover the matrix.

Then you parse the actual rules – the real YAML in the public repo, not the marketing layer on top of it – and the green collapses into three tactics.

Everyone covers execution and persistence. Almost nobody covers discovery, lateral movement, or collection. The heatmap wasn't measuring coverage. It was counting rules, and counting them in a way designed to look complete.

What a green cell actually means

A green cell in a Navigator layer means one thing: at least one rule somewhere references that technique tag.

That's it. Not "we detect this reliably." Not "this fires on real attacks and stays quiet otherwise." Not "this survives an attacker who knows the rule exists." One rule that names the technique in its metadata turns the cell green, and forty rules turn it the same shade. Unless the layer is scored by rule count – and most published heatmaps aren't – one and forty are indistinguishable.

I've written before that an untested detection isn't a detection, it's a query that runs on a schedule. The heatmap is the same lie one level up. A green matrix isn't coverage. It's a wall of queries that run, rendered in a color that means "present," dressed up as a color that means "protected."

The vendor knows the difference. The buyer staring at the green doesn't.

You can measure the real shape yourself

Here's the part the heatmap marketing depends on you not doing: the rules are public, and you can count them.

SigmaHQ, Elastic's detection-rules, Splunk ESCU, Panther, Sublime – all on GitHub, all tagged with attack.TXXXX technique IDs and tactic tags in the rule metadata. The method is boring on purpose. Walk the rule directories. Pull the ATT&CK tags out of each rule. Aggregate by technique, roll the technique counts up to tactic, and emit a Navigator layer scored by count instead of binary presence.

That's exactly what my spl-coverage-map tool does against my own rules. The same parser points at anyone's repo. There's no vendor cooperation required and no proprietary access involved – the coverage data has been sitting in the open the whole time. Nobody runs the count because the heatmap already told them what they wanted to hear.

One honesty constraint up front: this measures what's written, not what works. A high rule count for a tactic is still just a count – it doesn't mean those rules fire correctly. But the distribution across tactics is real signal even when any single number is soft. The shape is the finding.

The shape is lopsided, every time

Run it and the same picture shows up no matter whose corpus you point it at.

Coverage piles up on Execution, Persistence, Privilege Escalation, and Defense Evasion. These are the tactics where a single log event maps cleanly to a single rule. A process creation event. A registry run key. A new service install. One event, one rule, one green cell. Easy to write, easy to count, easy to demo.

It thins out fast on Discovery, Lateral Movement, Collection, Exfiltration, and Impact. These are the tactics that need correlation across multiple events, a baseline to deviate from, or behavioral context that a single point-event rule can't express.

My own numbers are no exception. Running this on my rules: roughly 37 techniques across 12 tactics, with discovery and lateral movement as confirmed gaps. That's not a brag and it's not a confession – it's the same lopsided shape everyone else has, and I'm not exempt from it. The point isn't that my coverage is good or bad. It's that the distribution is identical to the corpus at large, because the cause is structural.

The gaps aren't laziness. The easy tactics are easy precisely because their data model is one-event-one-rule. The hard tactics are gaps because they require session reconstruction, time-series baselining, and network context that point-event rules simply cannot encode. You don't fill those cells by trying harder. The rule format itself can't hold the detection.

The gaps are exactly where attackers live

Now line the shape up against where an intrusion actually spends its time.

Attacker dwell concentrates in the middle of the kill chain – discovery and lateral movement, the post-compromise stretch after initial access and before the objective. That's the hallway. It's where a breach turns from one box into your environment.

It's also the part of the matrix the corpus covers worst. The industry is heavily instrumented at the front door and at the smash-and-grab, and nearly blind in the hallway where the actual intrusion plays out. The green is densest exactly where attackers spend the least time, and thinnest where they spend the most.

This is the part I want to land, because it's where most "ATT&CK coverage is overrated" takes stop short. The discovery and lateral-movement gap isn't really a rule-writing gap. It's a telemetry gap.

Lateral movement and internal discovery are loud on the wire. East-west flows, SMB and RPC patterns, internal port scans, anomalous service-to-service connections – they're visible at the network layer in ways they are almost never visible in endpoint logs. The corpus is thin on these tactics partly because the corpus is written against endpoint and cloud-audit telemetry, and those tactics don't show up cleanly there. The blind spot isn't in the rules. It's in the data the rules were written against.

So the reframe is this: a coverage gap is a telemetry blind spot wearing a costume. You do not close your lateral-movement gap by writing more Sysmon rules. You close it by instrumenting the layer that lateral movement actually traverses, and then writing detections against telemetry that can see it.

What to do with the count

Run it on your own stack before you trust anyone's heatmap, mine included. The parser is public. Point it at your rules and score by count and tactic, not by binary technique presence – the distribution is what tells you anything.

Then read your thinnest tactics as a telemetry question first and a rule-writing question second. A bare lateral-movement column almost never means you forgot to write the rules. It means you have no east-west visibility to write them against. The fix lives in your network taps and your flow data, not your rule backlog.

And treat every published vendor heatmap as a claim to verify, not a result to trust. When a green matrix lands in front of you, the only question worth asking is which telemetry the green is built on. If it's all endpoint and cloud audit, that wall of color is blind in the hallway no matter how green it looks.

The actual lesson

The detection industry isn't hiding its blind spots. They're sitting in plain sight in every public rule repo, the same lopsided shape every time – dense at the front of the kill chain, thin through the middle where attackers actually live. The heatmap stays green because it counts rules and nobody asks it to count harder, and because "present" photographs the same as "protected" when you pick the right color.

Run the count yourself. Read the gaps as telemetry, not effort. What the heatmap won't tell you is the only thing worth knowing: not how many techniques you've named, but whether you can see the part of the attack that matters.