Sigma Rule Lifecycle: Hypothesis to Production

A Sigma rule has a lifecycle, and skipping its stages is why rule libraries fill with noise and dead logic. A rule starts as a hypothesis, becomes an experimental draft, gets validated, graduates to test in production while you tune its false positives, and only then reaches stable. Eventually most rules are deprecated. The status field is not decoration — it tells every analyst how much to trust an alert. This guide walks the full lifecycle with the versioning and CI that hold it together.

This is the single-rule companion to the program-level detection engineering workflow and the quality criteria in writing Sigma rules that actually fire. Here the focus is one rule’s journey, start to retirement.

What is the Sigma rule lifecycle?

The Sigma rule lifecycle is the set of stages a detection passes through from idea to retirement, tracked by the rule’s status field. It exists because a rule’s trustworthiness changes over time: a brand-new rule is a guess, a battle-tested one is a control, and the team needs to know which is which when an alert fires at 3 a.m. The status answers that.

It is the same maturity model the detection engineering workflow produces at scale, viewed one rule at a time — and it is what keeps a library honest as it grows.

What are the Sigma rule status stages?

The progression mirrors confidence. Promoting a rule is an explicit, evidence-backed decision — not a default — and demoting or deprecating one is just as deliberate.

How a Sigma rule moves from hypothesis to production

Walk one rule through the lifecycle:

1. Hypothesis — “an attacker abuses a database service to spawn a shell” (the behavior behind SQL injection detection).
2. Draft (experimental) — write the logic, name the false positives, commit to Git via a pull request.
3. Validate — generate the behavior in a lab, confirm it fires on the true positive and is quiet on a benign baseline (CI-gated).
4. Trial (test) — deploy to production in a low-priority queue; watch real false positives accumulate.
5. Tune — add scoped filter blocks for the specific benign sources you observe.
6. Promote (stable) — once false positives are understood and low, promote and let it drive paging/automation.

By the time it is stable, the rule carries its tuning with it:

title: Database Process Spawned a Command Shell
id: 2d8a4c11-darkpwn-illustrative
status: stable
logsource:
  category: process_creation
detection:
  selection:
    ParentImage|endswith: ['\sqlservr.exe','\postgres.exe','\mysqld.exe']
    Image|endswith: ['\cmd.exe','\powershell.exe','\bash','\sh']
  filter_backup:
    CommandLine|contains: '\\backup-jobs\\'   # known benign DBA automation
  condition: selection and not filter_backup
falsepositives:
  - Documented DBA backup automation (excluded via filter_backup)
level: high

How to version and gate the lifecycle in CI

The lifecycle only stays honest under version control:

1. Every status change is a pull request — promotion to stable is a reviewed, evidence-backed merge, not an edit in the SIEM console.
2. CI re-runs the rule’s tests on every change against true-positive and benign samples; a promotion that breaks a test is blocked.
3. Tag rule versions so you can roll back a tuning change that backfires.
4. Track the status distribution of your library — a healthy library trends toward stable, not a pile of permanent experimental.

When and how to deprecate a rule

Deprecate when the logsource is gone, the technique is no longer relevant, a better rule supersedes it, or false positives are unfixable. Set status: deprecated rather than deleting — the history and coverage record matter for audits and for understanding why a detection existed.

Common Sigma lifecycle mistakes

• Everything stuck at experimental. Rules never get validated and promoted, so nobody trusts the library.
• Mixing maturities in one alert stream. experimental noise drowns stable signal.
• Tuning by broadening. Silences the attack along with the noise.
• Deleting instead of deprecating. Loses history and coverage context.

Sigma rule lifecycle checklist

1. Start every rule from a written hypothesis; draft it as experimental.
2. Validate against true-positive and benign telemetry before any production trial.
3. Promote to test and deploy to a low-priority queue; observe real false positives.
4. Tune with scoped filter blocks for specific benign sources — never broaden.
5. Promote to stable only when false positives are low and understood.
6. Manage status changes via Git pull requests with a CI test gate.
7. Route alerts by status; let only stable rules drive paging/automation.
8. Deprecate (don’t delete) rules that are superseded or no longer relevant.

What does each stage actually gate on?

A lifecycle only works if each transition has a condition somebody can check. Stated vaguely (“promote when it looks good”), rules either sit in draft forever or get promoted on enthusiasm. Concretely:

Hypothesis → Experimental. The gate is that the rule compiles against your real schema and returns something when run over historical data. A rule that returns nothing over ninety days of logs is either perfectly tuned or looking at a field that does not exist — and the second is far more common. Confirm which before proceeding.

Experimental → Test. The gate is documented false positives. Run it against a benign baseline and write down what fired and why. If you cannot name the expected false positives, you do not understand the rule well enough to tune it later, and the person who inherits it certainly will not.

Test → Stable. The gate is validated true positives. The rule fired on real attack telemetry — from an authorised lab, an atomic test, or a past incident. Coverage you have not validated is a story you are telling yourself.

Stable → Deprecated. The gate is a stated reason: the technique is no longer relevant, the log source is gone, or a better rule supersedes it. Deprecation without a reason is deletion with extra steps, and it destroys the institutional memory of why the rule existed.

The stage that gets skipped is Test, because validating against real attack telemetry is the only step that requires effort you cannot fake. Skipping it is how a library reaches high coverage on paper and fires on nothing during an incident.

How do you keep the library from growing forever?

Detection libraries accrete. Every incident adds rules, nothing removes them, and after two years the volume is unmanageable while confidence is low. Three practices keep it bounded.

Cap by attention, not by count. The real constraint is how many rules a team can meaningfully own — tune, review, and respond to. That number is small. A library beyond it is not more coverage; it is the same coverage with more unmaintained surface.

Retire on a schedule, not on discovery. Rules that have not fired in a defined window get reviewed, not automatically deleted — a rule for a rare technique legitimately never fires. The review asks whether the technique is still plausible here and whether the log source is still arriving. Both answers are cheap to obtain and both change over time.

Merge aggressively. Libraries accumulate several near-identical rules written by different people for the same behaviour at different times. Consolidating them reduces alert volume and maintenance without reducing detection, and it is the least glamorous, highest-return cleanup available.

The metric that reveals the real state is not rule count. It is the proportion of rules that have fired at least once, and the proportion of those firings that were actioned. A library of two hundred rules where thirty have ever fired and five were actioned is a library of five rules plus a great deal of noise and maintenance — and knowing that is what makes pruning an easy decision rather than a contentious one.

Why does the lifecycle need to live in version control?

Treating detections as code is repeated often enough to be a slogan; the specific benefits are worth naming because they are what justify the overhead.

Review before production. A rule that reaches the SIEM without a second pair of eyes is a rule whose false-positive burden nobody agreed to carry. Pull requests are how that becomes a shared decision rather than one person’s judgement at 5pm.

Attribution and history. When a rule misfires eight months later, the useful questions are who wrote it, against what hypothesis, and what changed since. Version control answers all three; a SIEM console answers none of them.

Rollback. Tuning that turns out to be wrong is revertible in seconds rather than reconstructed from memory.

Testability in CI. The compile check, the schema check, and the regression run against stored telemetry all become automatic gates rather than remembered steps. This is the piece that keeps the lifecycle honest as the team grows, because it does not depend on discipline.

Portability. Rules expressed in a backend-neutral format and converted at deploy time survive a SIEM migration. Rules authored directly in a vendor console do not, and that migration happens more often than anyone plans for.

The failure mode to avoid is the half-measure: rules in Git that are also edited directly in the console. The repository becomes fiction, and the drift is invisible until someone tries to redeploy from source and breaks production detection. Pick one source of truth and enforce it in the deployment path — if the console can be edited, that is where the rules actually live, whatever the repository contains.

How does this work for a one-person security function?

The lifecycle above reads like it needs a team. It does not, but the compressed version has to drop the right things — and most solo operators drop the wrong ones.

Keep: the hypothesis field, the false-positive note, and validation against real attack telemetry. These are what make a rule trustworthy, and they are the parts you will not reconstruct from memory in six months. Keep the version control too — for one person it is less about review than about history and rollback.

Compress: the stage names. Two states — testing and live — carry the same information as four when one person owns everything. What matters is that a rule cannot reach live without having fired on something real.

Drop: the review workflow and the ownership field. There is one owner and review is self-review, so the ceremony adds nothing.

The genuinely important adaptation is the pruning schedule, and it matters more for a solo operator than for a team. A team absorbs a noisy rule across a rotation; one person absorbs all of it, and alert fatigue arrives faster and hits harder. A quarterly pass asking “has this fired, and did I act on it” is the difference between a library that helps and one that gets muted wholesale.

The realistic target is not comprehensive coverage. It is a small number of rules covering techniques that are plausible here, on log sources you actually collect, that you would want to be woken for. Twenty rules meeting that bar beat two hundred that do not — and twenty is achievable solo, which two hundred never was.

What breaks when the log source changes?

The most common way a mature detection library degrades is not a bad rule. It is a silent change beneath a good one.

Field names get renamed in an agent update. A log source moves to a different pipeline and arrives with a different shape. A vendor changes their event format. In every case the rule still compiles and still runs — it simply matches nothing, forever, with no error anywhere.

Three defences, and the first is worth more than the other two combined:

Alert on log-source silence. If events of a given type stop arriving, that is an incident regardless of what any rule says. This one control catches the majority of silent-decay cases and it is independent of your rule content entirely.

Track per-rule fire counts over time. A rule that went from regular hits to zero is broken until proven otherwise. This will not catch rules that were always rare, which is why it is second rather than first.

Re-run validation on a schedule. The atomic test that proved the rule worked at authoring time is the same test that proves it still works. Quarterly is enough, and it catches the rare rules that fire counts cannot.

Underneath all three is the idea worth carrying out of this post: a detection is a claim about the world, and claims expire. Ownership, a review date, and a last-fired timestamp turn that expiry from something you discover during an incident into something visible on a dashboard.

Who owns a rule, and what happens when they leave?

The lifecycle described above is a process, and processes decay without an owner. A detection library assembled over two years by people who have since moved teams is a common and genuinely difficult situation: nobody can say why a rule exists, so nobody is willing to delete it, so it accumulates alongside everything else.

Three pieces of metadata prevent that, and they cost nothing at authoring time:

• An owner — a team, not a person, so it survives departures.
• The hypothesis the rule was written to test, in one sentence. This is the field that makes a future reviewer able to judge whether it is still relevant. Without it, the rule is a query with no stated purpose and the only safe action is to leave it alone forever.
• A review date. Not a promise, a scheduling artefact — it puts the rule on someone’s list before it becomes archaeology.

The hypothesis field is the one that matters most and is skipped most. A rule that says “detects encoded PowerShell” tells you what it matches. A rule that says “we believe an attacker in this environment would use encoded PowerShell for staging because our EDR does not inspect script content” tells you what to re-evaluate when the EDR changes — and that re-evaluation is the entire point of a lifecycle.

How do you decide what to build next?

Coverage frameworks encourage breadth, and breadth is the wrong optimisation for a small team. A library spread thinly across every technique detects nothing reliably.

Prioritise on three axes instead of on coverage percentage:

What is actually reachable in your environment. A technique that requires a prerequisite you do not have is not worth a rule. Coverage counted against the full matrix flatters you; coverage counted against techniques that could actually work here is the honest number.

What your existing telemetry can already see. A rule that requires a log source you do not collect is not a detection, it is a purchase request. Sequence the telemetry first, then the rules that depend on it.

What an incident would cost. Techniques appearing late in a kill chain — credential access, lateral movement, exfiltration — are worth more per rule than early reconnaissance, because they are closer to the damage and further from the noise.

The output is a much shorter list than a coverage map produces, and every rule on it fires on something you can see, that can actually happen, and that you would want to know about at 3 a.m. That is a better library than one with twice the rules and half the confidence.

One organisational note that decides whether any of this survives contact with a busy quarter: the review has to be somebody’s named job, on a recurring calendar entry. A lifecycle that depends on remembering will be observed for two cycles and then quietly abandoned, and the library reverts to accretion — which is the state this whole process exists to prevent. Thirty minutes a quarter is enough; the failure is never the duration, it is that nobody owns the slot. Put it beside the on-call handover, which already recurs and already has an owner, and it survives the quarters when nobody has spare attention for process.

The takeaway

The Sigma rule lifecycle turns a guess into a trusted control through explicit stages — experimental, test, stable, deprecated — each backed by validation, tuning by exclusion, and version control. Honor the status as a trust contract with your analysts. Continue with the detection engineering workflow and writing Sigma rules that actually fire, or browse the full Detection Engineering pillar.