Detections belong in version control
A rule edited in a console has no history, no review and no way back. The same rule in a repository answers who changed it, when, and what it looked like before.
Most detection content is written in a console. You open the rule, edit the query, save. It works, and it costs you every property that makes engineering survivable.
There is no history, so when coverage breaks you cannot see the edit that broke it. There is no review, so a change reaches production the moment one person saves it. There is no rollback, only reconstruction from memory. And there is no way to know what your detections looked like on the day of an incident, which is the question that comes up in the review afterwards.
Detection as code is not a tooling purchase. It is keeping rules in files, in a repository, changed through pull requests. The rest is optional.
What you get is not exciting until you need it. A rule stops matching and you
can git log the file. A change goes out and somebody else read it first. An
incident review asks whether the rule was live in March and the answer is a
commit hash rather than a guess.
The migration is unpleasant if you wait, because exporting a few hundred console-authored rules is nobody’s good week. It is nearly free if you start with the next rule you write.
CHECK YOURSELF
Coverage for a technique quietly stopped working three weeks ago. Which setup lets you find out why?
SHOW THE ANSWER
The rule's commit history, showing each change and its author
Why. A timestamp tells you something changed but not what or why. A volume graph tells you when it stopped but not the cause. Last night's backup already contains the broken version. Only a change history shows the edit that did it, who made it, and what the working version looked like.