MITRE ATT&CK coverage projection

MitreCoverage is the engine that turns 'we ingest 27 connectors' into 'we cover Initial Access + Persistence + Defense Evasion + Discovery + Lateral Movement + Exfiltration; we DON'T cover Reconnaissance or Impact yet.' The operator sees a heatmap, not a connector list, which is what their CISO actually asks them about.

Other AI security products either don't ship MITRE mapping (Wazuh leaves it to you), ship a static slide deck (Sentinel), or charge a premium-tier upsell for it (Panther). CyberCLI ships the coverage engine in every tier and updates the map on every connector enrollment — the operator's CISO conversation is live, not annual.

The mapping is also the input to the v1.x 'coverage gap' recommender — a feature that looks at your current coverage matrix + the threats fitting your industry profile and suggests the next connector to enroll. That recommender doesn't fire in v1 yet; the data it needs is what this engine computes today.

Each connector manifest carries a `mitre_techniques` field — the canonical T-numbers the connector can produce signals for. MitreCoverage walks the enrolled connectors, builds a (tactic, technique) → connector mapping, and exposes a per-tactic coverage score (0 = uncovered, 0.5 = partial, 1 = fully covered by ≥1 connector).

The dashboard's `/architecture#mitre` heatmap reads the coverage object and renders the 14 tactic columns × technique rows with cell tints. A coverage object is also dumped to `coverage.json` on each enrollment change so an external dashboard or compliance tool can read the same data.

Updates are event-driven, not polled. When one of the per-connector enrollment verbs (`cybercli setup install-wazuh`, install-unifi, install-syslog, add-file-source, add-syslog-source) enrolls or removes a connector, the engine recomputes the coverage map + writes an audit row + emits a `mitre_coverage_changed` event the dashboard subscribes to. The heatmap updates without a refresh.

There is no ML in this engine. The mapping is data-driven from the connector manifests; the scoring is rule-based; the output is deterministic for any given enrollment state. That's deliberate — a coverage claim is an honesty contract with the operator's CISO and can't be a black box.

Beta — the mapping logic is stable but the per-connector manifest's `mitre_techniques` field is still being filled in for the breadth catalog. ~70% of the 27 connectors have full mappings as of 2026-06-07; the remaining 30% are tagged but incomplete.

Shipped 2026-06-07 (engine half): `recommend_gaps(installed_ids, top_n=5)` returns sorted recommendations of un-installed connectors ranked by how many uncovered MITRE tactics each would newly hit. Stable ordering (gain desc, name asc). The dashboard /architecture#mitre surface that calls this and renders the recommendation under the heatmap is the v1.x follow-on.

Known limit: coverage is one-directional today (which techniques are covered by which connectors). The inverse view (which connectors give the broadest coverage if I could only pick 5) is a v1.x backlog item.