Coverage claims in the security industry are notoriously unreliable. Vendors quote numbers without defining the denominator, conflate detection with prevention, or count a single telemetry source as covering an entire tactic. We're opening our methodology entirely — including the gaps.
How we define coverage
We use the current MITRE ATT&CK matrix as our baseline. A technique is 'covered' if and only if: (1) we have at least one detection rule mapped to it, (2) that rule has fired at least once in production validation in the last 90 days, and (3) the alert is enriched with enough context for an analyst to triage without additional investigation.
Techniques where we only have telemetry (visibility) but no alert logic do not count toward coverage. Neither do rules that exist in our library but have never been validated against real-world activity.
Where the gaps are
Our current gaps are concentrated in two areas: (1) Techniques requiring physical access to endpoints — these are out of scope for a cloud-delivered platform by design. (2) Recently-added sub-techniques for which we are still building detection rules.
- Hardware-additions techniques — require physical access, out of scope
- Recently-added ATT&CK sub-techniques — detection rules in development
- On-premises SAML token forgery — limited telemetry available from on-prem deployments
Our testing methodology
Every quarter our red team runs adversary-emulation tests against dedicated detection-validation infrastructure. Results feed directly into our coverage dashboard, which maps each test outcome to the relevant technique and updates our published numbers. We commit to updating this dashboard within 30 days of each ATT&CK version release.
# Example: validating an LSASS memory dump technique # (replace with the adversary-emulation framework you actually use) emulate-technique T1003.001 --tests 1,2,3 \ --timeout 60 \ --output ./results/T1003.001.json # ShieldOps validates that the alert fires within SLA shieldops coverage-check \ --technique T1003.001 \ --expected-alert "credential_access.lsass_dump" \ --sla-seconds 30
Why this matters for your security programme
Coverage metrics help you answer one question for your board: if an attacker uses technique X, do we detect it? The answer should never be 'we think so'. Build a validation programme, define coverage rigorously, and publish the gaps. Transparency on gaps is more valuable than inflated claims — it tells your team exactly where to invest next.