The maturity matrix

Platforms: 14. Capabilities: 33. Read date 2026-11-03. Scoring: documented 1, partial 0.5, not documented 0.

documentedpartialnot documented

Filter by group

Each group has its own page with the note, source and read date behind every documented or partial cell.

• Languages (10 capabilities)
• Source control and CI (6 capabilities)
• Testing (5 capabilities)
• Coverage analytics (4 capabilities)
• Rule health (5 capabilities)
• Library (3 capabilities)

Text table: documented and partial counts by group

Per platform and group: documented / partial. The last column is the matrix score of 33.

The 33 capabilities

Languages (10)

Sigma native

Sigma native. Rules written in Sigma YAML are stored and run by the platform without a conversion step. Proof needed: A docs page stating that Sigma rules are authored, imported or executed natively. 2 of 14 documented.

Sigma conversion

Sigma via conversion. Sigma rules can be converted to the platform's query language by a documented tool or backend. Proof needed: A docs or repo page naming a converter, backend or translation feature that outputs this platform's language. 2 of 14 documented.

YARA-L

YARA-L. Detections can be written in YARA-L 2.0. Proof needed: A docs page describing YARA-L rule authoring on the platform. 1 of 14 documented.

SPL

SPL. Detections can be written as Splunk SPL searches. Proof needed: A docs page describing SPL-based detections or correlation searches. 2 of 14 documented.

KQL

KQL (Kusto). Detections can be written in Kusto Query Language. Proof needed: A docs page describing KQL-based analytics rules or detection rules. 2 of 14 documented.

EQL or ES|QL

EQL or ES|QL. Detections can be written in Elastic EQL or ES|QL. Proof needed: A docs page describing EQL or ES|QL rule types. 2 of 14 documented.

Python

Python detections. Detection logic can be written as Python functions or scripts that the platform runs. Proof needed: A docs page describing Python detection authoring. 1 of 14 documented.

Visual builder

Vendor visual builder. A no-code or form-based builder produces the detection logic without hand-writing a query. Proof needed: A docs page naming a builder, detection wizard or no-code editor that generates logic. 1 of 14 documented.

YARA

YARA. File or memory signatures can be authored as YARA rules inside the detection workflow. Proof needed: A docs page describing YARA rule support as detections. 0 of 14 documented.

Lucene or KQL-like

Lucene or KQL-like query. Detections can use Lucene syntax, Kibana KQL, or a platform pipe or filter query language similar to KQL. Proof needed: A docs page naming the query syntax used for detection rules. 2 of 14 documented.

Source control and CI (6)

Git sync

Git repository sync documented. Detection content can be kept in a git repository that stays in sync with the platform. Proof needed: A docs or official repo page describing repository connection, sync or a repo layout used as source of truth. 5 of 14 documented.

PR deploy

Pull-request based deployment. A merged or opened pull request triggers validation or deployment of detections. Proof needed: A docs page or shipped workflow where pull request events run tests or deploy rules. 2 of 14 documented.

CLI

CLI for validate and deploy. A command-line tool validates rule files and pushes them to the platform. Proof needed: A docs page listing CLI commands for validation and upload or deploy. 4 of 14 documented.

Rule API

API for rule CRUD. Rules can be created, read, updated and deleted through a documented API. Proof needed: An API reference or docs page listing rule create, update, get and delete operations. 5 of 14 documented.

CI examples

Pre-built CI examples. The vendor publishes ready CI pipeline definitions (GitHub Actions, GitLab CI or similar) for detection content. Proof needed: A docs page or repo containing workflow YAML for detection content. 3 of 14 documented.

Env promotion

Environment promotion. Detections move between dev, staging and prod environments through a documented flow. Proof needed: A docs page describing multiple environments or staged promotion of rules. 0 of 14 documented.

Testing (5)

Unit tests

Unit tests with sample events. Each detection can carry test events and expected outcomes that run automatically. Proof needed: A docs page describing test cases or unit tests with sample or recorded events. 3 of 14 documented.

Replay

Replay against historical data. A rule can be run over past data to preview results before or after enabling it. Proof needed: A docs page describing historical test runs, retrohunts or data replay. 6 of 14 documented.

Synthetic events

Synthetic event generation. The platform or its tooling generates attack-like events to exercise detections. Proof needed: A docs or product page describing event simulation or attack data generation. 1 of 14 documented.

Backtest reports

Backtest reports. A test run produces a saved report (hit counts, false positives, volume) that can be reviewed. Proof needed: A docs page describing a persisted result or report from testing a rule. 0 of 14 documented.

Test coverage

Test coverage reporting. The platform reports which detections have tests or have been validated. Proof needed: A docs page describing validation or test coverage status across the rule set. 0 of 14 documented.

Coverage analytics (4)

ATT&CK map

ATT&CK mapping per rule. Each rule carries MITRE ATT&CK tactic and technique tags. Proof needed: A docs page stating rules are mapped or tagged to ATT&CK. 8 of 14 documented.

Gap view

Gap view against ATT&CK. A view shows which ATT&CK techniques have no active detection. Proof needed: A docs page describing a coverage matrix or gap report. 5 of 14 documented.

Data sources

Data source coverage view. A view shows which data sources feed detections or which are missing for coverage. Proof needed: A docs page describing data source or log source coverage against detections. 0 of 14 documented.

Log source health

Log source health tied to rules. Log source health problems are linked to the rules that depend on them. Proof needed: A docs page connecting ingestion or source health to detection rules. 1 of 14 documented.

Rule health (5)

Noisy rules

Noisy rule detection. The platform identifies rules that produce excess or low-value alerts. Proof needed: A docs page describing noisy or high-volume rule identification or tuning guidance. 0 of 14 documented.

Broken rules

Broken or silent rule detection. The platform flags rules that fail, error, or stop producing results. Proof needed: A docs page describing rule errors, failed runs or silent rule detection. 4 of 14 documented.

Field drift

Schema or field drift alerts. The platform alerts when fields a rule relies on change or disappear. Proof needed: A docs page describing field drift, mapping change or schema change alerts tied to rules. 0 of 14 documented.

Rule cost

Rule performance or cost telemetry. The platform reports runtime, resource use or cost per rule. Proof needed: A docs page describing per-rule execution time, latency or resource metrics. 2 of 14 documented.

Lifecycle

Deprecation and lifecycle states. Rules carry states such as active, test, deprecated, with documented handling. Proof needed: A docs page describing rule status values or deprecation handling. 4 of 14 documented.

Library (3)

Library count

Vendor-maintained library with published count. The vendor maintains a rule library and states how many rules it holds. Proof needed: A vendor page stating a count of library rules. 3 of 14 documented.

Community

Community library. A public library accepts or contains community-contributed rules. Proof needed: A repo or docs page with a contribution guide or community rule folder. 4 of 14 documented.

Cadence

Update cadence published. The vendor states how often library content is updated. Proof needed: A docs or product page stating a release cadence or recent version history. 0 of 14 documented.

Method and download

How the cells were read, what the statuses mean and what the matrix does not measure are on the matrix method page. The data is on the dataset page.