Detection as Code

What is detection as code?

Detection as code is the practice of managing detection rules as software artifacts — written in a portable format, kept in version control, reviewed through pull requests, tested automatically and deployed through a pipeline, rather than authored by hand in a SIEM console.

Key takeaways

• A rule is a software artifact. It has authorship, review, version history, tests and a rollback path, or it has none of those and the same problems untracked code has.
• Portability is the second benefit. An abstract rule format compiles to different SIEM query languages, which decouples detection content from the platform it runs on.
• Testing is what separates the practice from the slogan. Backtesting a rule against historical telemetry before deployment is the difference between a rule and a guess about a rule.
• Coverage is not a percentage. A rule that fires on a technique nobody uses against an organization and a rule that catches its actual risk both count as one rule.
• Telemetry is the precondition. A rule whose required logs are not being collected from the affected hosts detects nothing while appearing to be deployed.

Why it matters

Detection content built by hand in a console accumulates the way undocumented scripts do. Nobody knows who wrote a rule, why the threshold is what it is, what it was tested against, or whether disabling it will create a gap. Tuning becomes risky, so noisy rules stay, and false positive rates climb until analysts start closing alerts by reflex.

That is the failure mode worth naming, because it is quiet and it is common: the detection stack looks well populated and the signal-to-noise ratio has made most of it inert. Version control, review and automated testing are unglamorous fixes for exactly this.

What the pipeline contains

• A portable rule format. Rules written once in an abstract syntax — Sigma is the common choice — and compiled to the target platform's query language.
• Version control and review. Rules live in a repository. Changes go through pull requests, so a threshold change has an author, a reason and a reviewer.
• Automated testing. Unit tests against synthetic events for correctness, and backtesting against the organization's own recent telemetry for noise.
• Deployment automation. Rules ship to the SIEM through a pipeline, which makes rollback a revert rather than a reconstruction.
• Telemetry validation. Confirmation that the log sources a rule depends on are actually flowing from the hosts it is meant to cover.

A worked example of the pipeline

Consider a detection for exploitation of a JNDI lookup flaw of the Log4Shell type, where a crafted string causes a Java application to request a remote object from a host the attacker controls. The idea is simple to state: alert when a Java process opens an outbound LDAP or RMI connection to an address outside the organization's own ranges.

The rule is written in a portable format and opened as a pull request. Unit tests run it against a small set of synthetic events — one crafted to match, several crafted as near misses — which establishes that the logic does what its author believes. Backtesting then replays the rule across the last thirty days of real telemetry, and this is usually where the rule changes: a nightly batch integration turns out to make outbound directory calls of its own, producing several hundred historical hits. The author adds a narrow exclusion for that service account and records the reason in the pull request, so a reviewer sees both the logic and the justification for the carve-out.

Before deployment, a telemetry check confirms that process and network-connection events are actually arriving from the hosts running the affected application. The rule then ships with a version tag, and when the application is patched it is retired by reverting the commit rather than by someone remembering, months later, to delete it from a console.

What detection as code does not solve

It is a delivery and governance practice, not a source of detection ideas. The pipeline makes a rule reviewable, testable and reversible; it says nothing about whether the rule is worth having. The hard question — which detections are worth building for this organization, in this order — is upstream of the pipeline and is where detection engineering actually lives.

Nor does it fix a telemetry gap. Detection as code will happily deploy a rule against a log source that no host is sending, and the rule will sit there, green, detecting nothing.

Where detection ideas come from

Three sources dominate in practice, and they produce different kinds of rule. Framework coverage gaps — mapping existing rules to MITRE ATT&CK techniques and building for the gaps — is systematic but decoupled from actual exposure. Threat intelligence produces timely rules for campaigns that may or may not be aimed at this organization. Alert and investigation history produces rules reflecting what has already happened here.

A fourth source is less common and more direct: a specific vulnerability in the environment that cannot be fixed inside a risk-appropriate window. A rule built from that has an unambiguous reason to exist and a known expiry — the fix shipping.

How to evaluate a detection-as-code practice

The label is easy to claim and the substance varies widely. Five questions separate a functioning practice from a repository of YAML files.

• What happens to a bad rule. The measure of a pipeline is how quickly a noisy rule can be withdrawn, and whether the withdrawal is a single auditable action rather than an unrecorded console edit.
• What the tests actually test. Synthetic unit tests prove logic; backtesting against the organization's own telemetry proves noise. A practice with only the first ships correct rules that flood the queue on day one.
• How telemetry is verified. Coverage claims mean little without an automated check that the required log sources are arriving from the hosts in scope, run before deployment rather than after an incident.
• How rules are retired. Without an expiry field or a review cadence, a mature library carries detections for software that left the estate years earlier.
• Who reviews. Peer review by somebody who did not write the rule is the difference between version control and a backup of one engineer's console.

FAQ

Does detection as code require a specific SIEM? No — decoupling from the SIEM is one of the reasons to adopt it. Rules are written in a portable format and compiled to the target platform, so the content survives a platform migration.

How is a detection rule tested before deployment? Two ways, and both matter. Unit tests against synthetic events confirm the logic matches what it should. Backtesting against recent production telemetry shows how noisy it would have been, which is what prevents a correct rule from flooding the queue.

Is detection as code the same as detection engineering? No. Detection engineering is the discipline of deciding what to detect and building it well. Detection as code is how that content is managed, tested and shipped.

Sources

• SigmaHQ, Sigma Rule Specification, 2025.
• MITRE Corporation, ATT&CK for Enterprise knowledge base, 2025.
• MITRE Engenuity Center for Threat-Informed Defense, Summiting the Pyramid, 2023.
• Palantir, Alerting and Detection Strategy Framework, 2018.
• NIST, SP 800-92 Rev. 1 (draft), Cybersecurity Log Management Planning Guide, 2023.