Detection engineering

Detection engineering is the work of designing, writing, testing, deploying and maintaining the rules that raise alerts, and of measuring whether they still work. It sits between threat research and the SOC queue. The output is a set of rules with known coverage, known noise and a record of change.

What Detection engineering means here

The cycle runs from a threat idea to a rule, a test, a deploy and a review of how the rule behaves in production. Tools support different slices. Some stress authoring and conversion, some stress testing, some stress health and coverage reporting.

Detection as code is one way to run the cycle, not a synonym for it. A team can do detection engineering in a console. The code workflow adds review and history on top.

Example of Detection engineering in Splunk Enterprise Security documentation

Splunk's contentctl user guide lists the cycle as generate, validate, build, test and deploy, with the commands init, new, validate, build and test covering the first stages. raw.githubusercontent.com read 2026-11-03

Terms related to Detection engineering

• Detection as code: Detection as code means detection rules live in a version-controlled repository, change through reviewed pull requests, and reach the SIEM through a pipeline instead of console edits.
• Detection rule: A detection rule is a stored query or logic that runs over security data and raises an alert when it matches.
• Tuning: Tuning is adjusting a rule so it keeps its true positives and drops its false ones: tighter conditions, exclusions or thresholds.

The matrix scores platforms on whether they document these ideas: see the matrix and the full glossary.