Matrix method

The matrix is a grid of 14 platforms against 33 capabilities in six groups, built only from what each platform's public pages say. Every cell carries a status, a note naming the feature as the page calls it, the URL of the page and the read date. Read date for every cell: 2026-11-03. Next full refresh: 2027-02-03, then every quarter.

The 33 capabilities

The brief for the matrix listed 30 capabilities and the itemised list held 33. All 33 are kept. The first five groups hold 30 of them, and each platform's score over those 30 is stored in the dataset as maturity_core_30.

• Languages (10): Sigma native, Sigma conversion, YARA-L, SPL, KQL, EQL or ES|QL, Python, Visual builder, YARA, Lucene or KQL-like.
• Source control and CI (6): Git sync, PR deploy, CLI, Rule API, CI examples, Env promotion.
• Testing (5): Unit tests, Replay, Synthetic events, Backtest reports, Test coverage.
• Coverage analytics (4): ATT&CK map, Gap view, Data sources, Log source health.
• Rule health (5): Noisy rules, Broken rules, Field drift, Rule cost, Lifecycle.
• Library (3): Library count, Community, Cadence.

Language rows are specific to each platform. A platform is not weaker for lacking another vendor's language; the rows show what each tool lets you write.

Status definitions

• Documented: a vendor documentation page, API reference, official repository page or official reference page states the feature and what it does.
• Partial: the feature is named but incomplete, exists only in a different form, or the only evidence is a product page, press release or vendor blog. Marketing-only evidence is never scored as documented.
• Not documented: no page read for that platform names the feature. This does not say the feature does not exist. It says a reader following public pages would not find it.

How the score is computed

Documented counts 1, partial 0.5, not documented 0. The matrix score is the sum over 33 capabilities. Every capability has equal weight, so the score is a count of public evidence and not a quality grade. The weighted rubric is a separate measure with its own weights.

How the pages were read

Pages were fetched and read as text. Where a docs site publishes llms.txt or a Markdown version of its pages (Panther and Hunters do), the Markdown was read. Raw repository files were read for repository documentation (Elastic detection-rules, Splunk contentctl and security_content, Google SecOps detection-rules, Panther panther-analysis and panther_analysis_tool, SigmaHQ). Page locations came from site navigation, sitemaps and docs indexes. A cell that points at a platform's default page means the page was checked and did not name the feature.

Where the docs could not be read

• SOC Prime: docs.socprime.com did not resolve, so cells rest on product pages and top out at partial. Its own pages disagree on translation languages and rule counts.
• Anvilogic: docs.anvilogic.com redirects to a login page, so cells rest on product pages.
• CardinalOps: cardinalops.com redirects to cribl.io. A press release, a blog post and a solution brief were read; no product documentation was found.
• SnapAttack: snapattack.com redirects to the Splunk Enterprise Security product page, and no SnapAttack documentation was found. It scores zero for lack of readable evidence, which is a finding about discoverability and not about the product.
• Detecteam: only the home and solutions pages carried body text.
• Mate Security: the platform page, the home page and one blog post. No documentation portal, API reference or detection engineering page was found.
• Google Security Operations: the Terraform registry page for chronicle_rule is not static HTML, so Terraform support was not confirmed and is not credited.

Platforms considered and not scored

• crowdstrike-next-gen-siem: Public pages read (crowdstrike.com Next-Gen SIEM product page) carry no detection-as-code documentation; product docs sit behind the Falcon console login. Not scored. crowdstrike.com read 2026-11-03
• exabeam: exabeam.com product pages read mention MITRE ATT&CK reporting only; no detection-as-code documentation was found on public pages. Not scored. exabeam.com read 2026-11-03

Ownership notes

Cribl announced its acquisition of CardinalOps on 2026-07-14. Cisco completed its acquisition of SnapAttack on 2025-02-05. Panther agreed to be acquired by Databricks on 2026-06-16. Those three facts came from other research and were not re-verified for the matrix, except that cardinalops.com redirects to cribl.io and snapattack.com redirects to a Splunk page, both seen on 2026-11-03. Splunk's contentctl README says future investment is shifting to Detection Studio.

What the matrix does not measure

• Whether a feature works well, scales or is priced in a way a team can afford.
• Features documented only behind a login, in a sales deck or in a support portal.
• Depth within a status. A documented unit-test framework and a documented one-line CLI check both score 1.
• Language breadth as quality.
• Agentic or AI-driven rule creation and tuning, except where a page describes a capability named in the list.
• The accuracy of any vendor figure. Library sizes, noise reduction percentages and broken-rule rates are vendor claims and carry the page they came from.
• Pricing, packaging and licence tier. Some features need a paid tier.
• Sigma and pySigma are open-source projects, not platforms. They are scored on the same grid so readers can see what the conversion layer provides and what it leaves to others.

Corrections and refresh

Any vendor or reader can send a correction with the URL of a public page that names the feature. The cell is re-read, updated if the page supports it, and the change is logged on the corrections page. A correction that moves a cell up needs a public page. Corrections are applied within ten working days and the read date on the changed cell is updated. The full grid is re-read every quarter, and sooner when a release note changes the picture.