1. Engineering-driven Detection-as-Code (The “True” Model)
This is what mature SOCs with dedicated detection engineers aim for.
The workflow looks like real software delivery.
How it works
Engineers write detections in a standardized language like Sigma.
Rules live in Git with version control and peer review.
A CI/CD pipeline enforces quality gates before anything hits production.
Quality gates that actually matter
Format and documentation validation
Ensures correct syntax, required metadata, and consistent documentation.Translation
Sigma is converted to the SIEM’s native language with pySigma or a custom translator.Historical false positive checks
A pipeline job runs the rule against historical data via API to measure noise early.Adversary emulation tests
Automated triggers for frameworks like Atomic Red Team confirm the rule fires on real TTP simulation.Automated deployment
If it passes, the rule ships to production through the SIEM API.
This approach treats detections like code that must be tested, reviewed, measured, and shipped with confidence.
Why this model wins
It minimizes alert fatigue, raises detection quality, and creates an evidence-backed path to coverage growth that leadership can trust.
Why does this model lose
The primary cons of this model are that it requires the security team to have deep technical expertise, in being able to write up detections in Sigma and validate them through a CI/CD pipeline. The reality is that most security teams do not have these software engineering skill sets.
Example
You write a Sigma rule for suspicious Entra ID privilege escalation. It gets committed, reviewed, tested against historical data, validated via atomic simulation, tuned, then deployed automatically.
2. Lightweight Detection-as-Code (The “Practical” Model)
Most organizations do not have a dedicated detection engineering team with deep technical expertise in software engineering principles. That’s fine.
You can still adopt the core principles with a leaner workflow. The goal is not automation for its own sake. The goal is discipline and creating a standardized process for detection engineering.
Before pushing a new rule, analysts should
Run test queries against historical data to confirm precision and estimate noise.
Simulate or replay known attack data to validate effectiveness.
Document the detection logic
What it covers, why it exists, what changed, and how responders should act.Store everything in a shared repository
Git if possible. A structured knowledge base at a minimum.
Even a manual process grounded in these steps will outperform a chaotic “build and ship” culture.
The Real Point
Detection-as-code is not just CI/CD.
It’s a mindset that says:
a detection is a product.
It should be:
versioned
testable
measurable
explainable
maintainable
When you adopt this standard, your SOC stops accumulating brittle, noisy rules and starts building a resilient detection stack that evolves cleanly with the threat landscape and the business.
What This Means for Leaders
If you want fewer false positives, faster detection maturity, and better auditability, this is your path.
You do not need a perfect pipeline on day one.
You need a standard of engineering quality that scales.
Action Steps You Can Use This Week
Pick a standard language
Start with Sigma for portability.Centralize detections
Use Git if you can. If not, create a single source of truth and enforce documentation.Add two quality gates immediately, these can be manual or automated
Historical testing and basic simulation validation.Measure outcomes
Track false positive rate, detection coverage by ATT&CK technique, and time-to-production.