Every security team has a slide with an ATT&CK Navigator heatmap on it. Green squares everywhere. Leadership loves it. It gets screenshotted into a QBR deck, nobody asks a single follow-up question, and the org walks away believing it has “80% technique coverage.” Nobody in that meeting has verified that a single one of those green squares corresponds to a rule that is actually deployed, actually firing, and actually not silently broken since March. That’s not coverage. That’s cosplay with a legend.
We got tired of watching this exact scene repeat at every mature-ish SOC we’ve talked to, so Coverage Map in HEFAISTOS is built to refuse to play along. It answers exactly one honest question: what is operationally covered right now, not what someone typed into a spreadsheet in Q2, not what a Navigator layer said before it went stale, not what a workbench author intended when they tagged a technique and then never shipped the rule.
The three cursed ways teams currently “measure” coverage
- Hand-maintained spreadsheets. Updated once, quietly abandoned, technically still “the source of truth” per the wiki page nobody reads.
- Stale ATT&CK Navigator layers. Beautiful, colorful, and about as trustworthy as a resume.
- PowerPoint optimism. The slide says covered. The SIEM says the rule was disabled eight months ago because it was noisy. Guess which one gets presented to the board.
Coverage Map exists to replace all three with something tied to reality: live coverage based on deployed detections, running against the current ATT&CK framework version, generated from what’s actually running in production — not what’s sitting in a draft workbench looking aspirational.
The rule we actually enforce: deployed, not designed
This sounds obvious until you watch how most platforms — and most humans — cheat it. The standard failure mode is tagging a workbench with a dozen ATT&CK techniques during the design phase, feeling very thorough, and then never shipping half of what was promised. The technique tags survive. The actual detection logic doesn’t make it to production, or gets disabled two weeks later because someone’s on-call rotation got tired of the false positives. Six months later, the coverage map — if it’s naively built off design-time metadata instead of deployment state — still says “covered,” because nobody wired the map to check whether the thing is actually alive.
HEFAISTOS’s Coverage Map is deliberately downstream of deployment state, not design state. A workbench doesn’t earn a green square for existing. It doesn’t earn one for being reviewed. It earns one for being deployed. That’s the whole philosophical spine of the feature, and it’s the one place we refuse to grade on effort.
The confession: we almost let the downstream pages blur together
Here’s the part where we admit we nearly documented this wrong internally. During the platform rebuild we caught ourselves drafting language that treated Coverage Map, L1 Portal, and MGMT Cave as basically the same “downstream operations blob” — three surfaces that all sort of do post-deployment things, so why bother being precise about the boundaries?
That would have been a genuinely bad habit to ship into documentation, because it feeds two specific lies that are worth killing outright:
- “MGMT Cave is where detections get operationalized.” It isn’t. MGMT Cave is management reporting — aggregate stats, monthly trends, distribution lists, the stuff that goes in front of people who ask “how’s the program doing” and want a number, not a query. It has nothing to do with turning a detection into something a responder can use.
- “Deployed means responders automatically have a good operational artifact.” Also false, and arguably the more dangerous lie. Deployment is necessary, not sufficient. A workbench can be deployed and still have an empty response playbook, no documented false positives, and zero blind-spot notes — which means the moment it fires in production, whoever’s on call gets a technically-covered ATT&CK square and absolutely nothing useful to act on.
L1 Portal is the actual responder-facing projection layer — read-only playbook snapshots generated specifically from deployed workbenches, scoped to low-level support people who need operational guidance without opening the full engineering cathedral. Coverage Map is adjacent to that, but it answers a different question entirely: not “what should the responder know,” but “what does our deployed program actually cover.” MGMT Cave is a third, separate lane again — reporting, not handoff, not projection, not operationalization.
Three surfaces, three audiences, three questions. Mushing them into one “post-deployment stuff” paragraph would have made the documentation exactly as useless as the spreadsheets we’re trying to put out of business. We caught it. We’re not proud it almost happened, but we’d rather tell you than pretend the rebuild was one smooth continuous act of perfect clarity.
Coverage that can tell you the truth about gaps too
The other underrated thing about grounding coverage in deployment state: it makes gap analysis honest instead of decorative. A grey square on a coverage map that’s wired to deployment state means something specific — nobody has a live, running detection for that technique, full stop. That’s actionable. A grey square on a Navigator layer someone updated by hand three sprints ago just means someone forgot to color it in, which is a completely different and far less useful piece of information.
If your coverage map can be gamed by tagging intent instead of shipping detections, it’s not a measurement tool. It’s a mood board. Coverage Map is deliberately built to resist becoming one, and Capability Abstraction feeding cleaner, behavior-grounded technique mappings upstream only makes the resulting map more trustworthy — garbage tagging in still means garbage coverage out, we don’t get to skip that law.
Stop coloring in Navigator layers by hand and calling it a program review. Ship the detection, let it earn the square.
Good riddance, vanity coverage.