PAGES
← all tools
◆ Detection Engineering

Detection Rules

dev-v3.0.0 open-source

Detection Rules is Elastic's framework for defining and managing security detection logic to identify threats and anomalies in system and network data.

Summary

Detection Rules is an open-source repository, maintained by Elastic, of detection logic and the Python tooling used to build, test, and package it for Elastic Security's Detection Engine. It runs as a command-line and CI-driven workflow rather than a hosted service: rules are authored as files, validated with the included Python module, and shipped through a detections-as-code pipeline into Kibana. This fits detection engineers and SOCSOCA security operations center, the team or function that monitors threats, investigates alerts and coordinates incident response. Its work can be internal, outsourced or shared. teams running Elastic Security who want version-controlled, testable rules rather than ones edited by hand in a UI, and it maps coverage to MITRE ATT&CKMITRE ATT&CKA publicly maintained knowledge base of adversary tactics and techniques observed in real attacks, maintained by MITRE. Cyber tools use it as a common taxonomy to classify, map, and communicate threat behavior. out of the box. The rule set spans cloud platforms (AWS, Azure, GCP/GKEGKEGoogle Kubernetes Engine, Google's managed Kubernetes service, which lets cyber tools run containerized workloads without managing the underlying cluster infrastructure.), Linux and Windows endpoints, and network and application layers, so it functions as a shared library rather than a point tool. First committed in 2020, it has 125 contributors, thousands of commits in the past year, and a release 32 days ago, indicating active maintenance.

Detection Rules is Elastic's framework for defining and managing security detection logic to identify threats and anomalies in system and network data.

How Detection Rules helps

Which techniques in the ATT&CK matrix have no rule covering them yet in my Elastic deployment?

maps every rule in the set to its ATT&CK technique out of the box, so gaps in the navigator view show where no shipped rule exists

Are the detection rules I wrote actually valid before they reach production?

the included Python module validates rule files for schema and logic errors as part of the build, catching problems before packaging into Kibana

Did a change to a rule file get reviewed and tested the same way every time?

rules are authored as version-controlled files and run through unit tests and a CI-driven pipeline, so every change leaves a diff and a test result rather than a silent UI edit

Which cloud services and platforms does my current rule coverage actually reach?

the rule set is organized by platform (AWS, Azure/Entra ID, GCP/GKE, Linux, Windows, network, application layers), so coverage can be checked folder by folder against what the environment runs

Will upgrading my Elastic Stack change how existing rules map to ATT&CK?

rules carry a threat mapping framework and version that switch automatically on stack 9.5 and above, while older stacks keep the prior mapping unless explicitly configured

Can I still author rules the way I used to after a schema change to related integrations?

version constraints in emitted rule output changed from caret to greater-or-equal, so packages and stack schema maps need to be checked against the stack version before upgrading

all 10 features, with the evidence for each →

Languages

Not documented

Features

10 capabilities · 2 backed by code, an API document or a real run

Built from Detection Rules's releases, docs, README and our own runs. “Seen” marks the month we first spotted a release the vendor didn't date. Group names and tags are our labels.

Compare with peers →

What Detection Rules offers you

  • Command-line interface3
  • Offline mode1
All capabilities 10 capabilities
Detection rule library shipped Ships a curated, versioned library of detection rules covering Linux, Windows, macOS, cloud platforms, network protocols, and SaaS services. 223 releases · first seen Nov 2024

release 223 total

  • Adds new detection rule: Potential ClickFix Command via Windows Run Dialog. dev-v3.0.0 · Sep 2026 · source · release history
  • Adds new detection rule: Entra ID device-bound PRT cookie replay from unusual IP. dev-v3.0.0 · Sep 2026 · source · release history
  • Adds new detection rule: Azure WireServer Abuse Related Detections. dev-v3.0.0 · Sep 2026 · source · release history
  • Adds SSH brute force detection rules for the macOS Security Events integration. dev-v3.0.0 · Sep 2026 · source · release history
  • Adds new detection rule: Linux Firewall Rule Creation or Modification. dev-v3.0.0 · Sep 2026 · source · release history
  • Adds new detection rule: Potential Fileless Execution via O_TMPFILE. dev-v3.0.0 · Sep 2026 · source · release history
KQL rule authoring support shipped Provides a library for writing and composing KQL-based detection rules, including support for nested query expressions. 13 releases · 3 other sources · first seen Apr 2025

Also counts toward: Command-line interface

release 13 total

  • Adds Add free text support to KQL to allow free text queries in KQL syntax dev-v2.2.0 · Sep 2026 · source · release history
  • Adds free text support to KQL for detection rule queries. dev-v2.2.0 · Sep 2026 · source · release history
  • Adds new rule: Potential Evasion via Boot Time Removal Tool. dev-v2.2.0 · Sep 2026 · source · release history
  • Adds nested KQL query support in lib/kql for more expressive rule authoring. dev-v2.1.0 · Aug 2026 · source · release history
  • Add nested KQL query support in lib/kql dev-v2.1.0 · Aug 2026 · source · release history
  • ESQL LLM-Based Alert Triage Rules introduced dev-v1.6.0 · Mar 2026 · source · release history

docs

  • Repository for developing, testing, validating, and managing Elastic Security detection rules with Python-based tooling and Detections-as-Code support.

example

  • Generate rule outputs using local system dates instead of UTC, useful for environments where local time context is required. detection-rules analyze --local-dates rules/*.yml dev-v1.1.0 · Apr 2025 · source
  • Export detection rules that match a specific KQL query string, such as filtering by rule name pattern. detection-rules export --kql-export 'rule.name: "Suspicious PowerShell*"' dev-v1.1.0 · Apr 2025 · source
MITRE ATT&CK threat mapping shipped suggested Maps detection rules to MITRE ATT&CK technique and tactic identifiers, with version-controlled mappings that can be applied automatically or configured explicitly per stack version. 6 releases · 2 other sources · first seen Feb 2025

Suggested capability: Log enrichment. This is our guess, not confirmed.

release

  • Adds DR_THREAT_MAPPING_FRAMEWORK and DR_THREAT_MAPPING_VERSION environment variables to select MITRE ATT&CK v19 mappings on older stacks dev-v2.0.0 · Jul 2026 · source · release history
  • MITRE ATT&CK v19 mappings are automatically applied on stack >= 9.5; to use v19 on stacks <= 9.4 you must explicitly set DR_THREAT_MAPPING_FRAMEWORK="MITRE ATT&CK" and DR_THREAT_MAPPING_VERSION=1, or add threat_mapping_framework: "MITRE ATT&CK" and threat_mapping_version: "19" to your _config.yaml. dev-v2.0.0 · Jul 2026 · source · release history
  • Adds threat_mapping_framework and threat_mapping_version configuration keys in _config.yaml for MITRE v19 selection dev-v2.0.0 · Jul 2026 · source · release history
  • Adds MITRE ATT&CK v19 threat mapping support, automatically applied on Elastic Stack >= 9.5 with dynamic tag assignment. dev-v2.0.0 · Jul 2026 · source · release history
  • Deprecates Cloud Defend rules dev-v1.0.0 · Mar 2025 · source · release history
  • Adds deprecation warnings for Experimental ML commands dev-v0.3.0 · Feb 2025 · source · release history

example

  • Use MITRE ATT&CK v19 mappings with Elastic stack version 9.4 export DR_THREAT_MAPPING_FRAMEWORK="MITRE ATT&CK" DR_THREAT_MAPPING_VERSION=1 elastic-agent restart dev-v2.0.0 · Jul 2026 · source
  • Specify MITRE v19 mappings in the configuration file threat_mapping_framework: "MITRE ATT&CK" threat_mapping_version: "19" dev-v2.0.0 · Jul 2026 · source
Offline ES|QL rule validation shipped Validates ES|QL rule syntax, schema, and types locally at load time using a dedicated package instead of requiring a remote Elasticsearch cluster connection. 7 releases · first seen Sep 2026

Also counts toward: Offline mode

release 7 total

  • Removes the --esql-remote-validation flag; queries no longer need to be posted to an Elasticsearch cluster for validation. dev-v3.0.0 · Sep 2026 · source · release history
  • Adds offline ES|QL validation via the detection-rules-esql-py package for detecting errors in rules at load time rather than against a remote cluster dev-v3.0.0 · Sep 2026 · source · release history
  • The --esql-remote-validation flag is removed; attempting to use it will cause a CLI error dev-v3.0.0 · Sep 2026 · source · release history
  • Removes the --esql-remote-validation CLI argument and all remote ES|QL validation infrastructure dev-v3.0.0 · Sep 2026 · source · release history
  • The --esql-remote-validation flag is removed; any workflow or script that passed it will now fail. ES|QL rules are validated offline at load time against local schemas and min_stack_version, and queries that previously loaded only because remote validation was skipped can now fail local syntax, schema, or type… dev-v3.0.0 · Sep 2026 · source · release history
  • Replaces remote ES|QL validation with offline validation via detection-rules-esql-py 0.1.0, checking rules at load time against min_stack_version and local schemas; DR_BYPASS_ESQL_KEEP_VALIDATION and DR_BYPASS_ESQL_METADATA_VALIDATION still skip only the KEEP and FROM metadata… dev-v3.0.0 · Sep 2026 · source · release history
CLI version pinning verified Allows specifying a tagged target version for CLI operations via a version flag. 3 releases · 1 other source · first seen Nov 2022

Also counts toward: Command-line interface

release

command line

  • --endgame-version — Tagged version from TBD. e.g., 1.9.0 v8.6.0 · Nov 2022 · command-line history
Related integrations version constraint management shipped Controls the version constraint syntax emitted for related integrations in rule output, allowing operators to align rule packages with their target stack version. 4 releases · first seen Jul 2026

release

  • Changes the related integrations field format from ^ to >= version specifiers dev-v2.0.0 · Jul 2026 · source · release history
  • Emitted related integrations now use >= instead of ^ for version constraints, which is expected to not function on Elastic stacks older than 9.5 — ensure your stack schema map and/or packages.yml match your stack version before upgrading. dev-v2.0.0 · Jul 2026 · source · release history
  • The emitted related integrations now use >= instead of ^ which is expected to not function on older stacks. dev-v2.0.0 · Jul 2026 · source · release history
  • Related integrations version constraints updated from ^ (caret/compatible) to >= (greater-or-equal) in emitted rule output. dev-v2.0.0 · Jul 2026 · source · release history
CLI branch management verified Provides CLI commands for working with branches during rule development and management workflows. 1 release · 2 other sources · first seen Sep 2022

Also counts toward: Command-line interface

release

  • Adds the DR_CLI_MAX_WIDTH environment variable to control CLI output width dev-v1.0.0 · Mar 2025 · source · release history

command line

example

  • Show all available CLI commands python -m detection_rules --help
Automated PR review workflow shipped Integrates with pull request review automation to classify and validate rules, including tag taxonomy checks for submitted rule changes. 2 releases · first seen Aug 2026

release

  • Adds XDR/SIEM taxonomy tags (phase 1) to rule metadata as part of the new tagging system dev-v3.0.0 · Sep 2026 · source · release history
  • Adds XDR rule tag taxonomy to Copilot PR review workflow, improving automated rule classification. dev-v2.1.0 · Aug 2026 · source · release history
ES|QL sub-query support shipped Enables the use of nested ES|QL sub-queries within rule definitions to construct more complex logical detection structures. 2 releases · first seen Sep 2026

release

  • Supports ES|QL sub queries within rule definitions, enabling more complex logical structures in detection rules dev-v3.0.0 · Sep 2026 · source · release history
  • Supports ES|QL sub queries in rule validation. dev-v3.0.0 · Sep 2026 · source · release history
Automated investigation guide generation shipped Generates investigation guides to assist in threat analysis and response. 1 release · first seen Feb 2025

release

  • Adds investigation guide generation capability via [FR] Generate investigation guides dev-v0.3.0 · Feb 2025 · source · release history

Lines in monospace are the tool's own words: help text parsed from its source, or an endpoint from its API document. Under release, a line is our summary of a dated release. Under docs, it is quoted from the tool's own documentation or website. Each links back to the source it came from.

Score card

  1. Shipping velocity releases a month, last 12 months
  2. Documentation quality release-notes rubric, 0–100
  3. Breaking-change discipline how rarely a release breaks users, and notice given
  4. Maintenance risk quiet time against its own cadence, maintainers
  5. Innovation & surface new capabilities, API and MCP surface
  6. Community health
  7. Contributor trend distinct committers, this year against last
  8. Maintainer concentration bus factor now against a year ago
  9. Issue backlog trend issues closed per issue opened, 12 months
  10. Responsiveness median time to a maintainer’s first reply

Nine scores for Detection Rules, each built from the releases, notes and API history this site tracks — and, on Researcher and Business, where it stands among every measured tool in its category and how that has moved.

Score cards are part of every paid plan.

See plans →

Each score is 0–100 on a published rubric, derived from data this site already shows. A dimension we cannot measure says so — it is never scored 0 and never enters a rank.

How this is scored
  • Shipping velocity — releases a month over the last 12 months, on a log scale where 16 a month scores 100. Needs 3 releases in the window.
  • Documentation quality — the release-notes rubric published on the analytics page, unchanged.
  • Breaking-change discipline — the share of releases carrying a breaking change (none scores 100, half or more scores 0). Only projects that label breaking changes are measured: a clean record cannot be told from an unlabelled one.
  • Maintenance risk — quiet time measured against the tool's own release cadence (quiet longer than 90 days and three typical gaps scores 0), plus the number of active maintainers and whether contributors are growing, where known. Higher is lower risk.
  • Innovation & surface — new capabilities in the feature ledger this year, API and MCP operations added, and the share of commits that are features: the mean of whichever we hold.
  • Community health (open-source tools only) — each is a direction, not a size: contributors this year against last, the bus factor now against a year ago, and issues closed per issue opened, where steady scores 50, doubled 100 and halved 0; plus the median time to a maintainer's first reply (an hour scores about 100, a month or more 0). A commercial card has no repository and carries none of the four.
  • Documented delivery (commercial tools) — when a vendor's documented new capabilities have slowed against its own baseline, that counts against the overall standing as heavily as two low dimensions. Steady delivery, or too little history to judge, leaves the standing alone; it is never a sixth score.
  • Open-source tools are scored on repository signals; commercial tools on their published changelog. Ranks compare tools within one category and one profile and need at least five measured peers; the overall standing needs three ranked dimensions. Best-in-breed or consolidator is a shape, not a quality, and is never scored.

Release-note detail over time

See how much detail Detection Rules puts in its release notes, quarter by quarter, and compare it with tracked tools in the same category. This history uses up to ten retained, reviewed notes per tool; sparse or blank older quarters may reflect that limit.

Checking release-note history…

Explore the full chart →

Releases

Show

14 entries

  1. September 20262
  2. August 20261
  3. July 20261
  4. March 20262
  5. September 20251
  6. July 20251
  7. May 20251
  8. April 20251
  9. March 20251
  10. February 20252
  11. November 20241
    Show

    14 entries

    Project health

    Issue, contributor and maintainer activity in elastic/detection-rules, 2023-10 – 2026-09, as of 2026-09-25. Twelve-month figures first; the trend lines run the whole window.

    1. Contributors 35 +13 vs prior 12 months
    2. Maintainers 7 +3 joined · −2 left, last 12 months
    3. Bus factor 4 committers behind half the commits
    4. Community-filed 100% of issues opened, last 12 months
    5. Median time to close 15 days first maintainer reply 9.1 days
    6. Open backlog 140 of 2,098 issues ever filed
    1. Issues opened / month 8 · 0 communitymaintainers
    2. Open backlog 140
    3. Contributors / month 11
    4. Commits / month 76
    5. Stars 2,701
    Issue themes, last 12 months
    • bugs 11%
    • features 8%
    • docs 0%
    • other 81%

    Counts from the project's public repository and git history; no individuals are identified. Maintainers are the committers covering 80% of the last year's commits. how we measure this

    Threat coverage

    Content for the last year of exploited CVEs and attack reports.

    Detection Rules has content for 515 of the 982 threats tracked in the last year, 64 of them exact.

    exact64names the CVE
    related451names the technique or product
    tracked982threats in the last year

    See the threats, and how similar tools compare threat by threat, with Researcher and Business.

    See plans → Already subscribed? Sign in →

    Add the badge to your README

    Maintain this project? The badge links readers straight to this page, so they can follow every release here.

    Tracked by Cyber Toolchain Choose a badge style and copy the code →
    browse all tools → score card for your toolchain →