Detection as Code

Press enter or click to view image in full size

In April 2025 I gave a talk at the AWS Stockholm meetup titled “Detection as Code”. I covered the core principles of detection and response, highlighted the Sigma detection format, and closed with a quick demo that sparked a lively Q&A. During my time on Grafana Lab’s Detection & Response team, we built Sigma Rule Deployment (SRD), a GitHub Actions suite that automates detection-as-code end to end. This article isn’t a step-by-step guide. In this article I try to frame detection & response, explain what Sigma is, and introduce SRD. I’ll be working on another blog post as a step by step tutorial on how to use the SRD project.

A Bit of Detection & Response

Observability has matured fast, thanks in no small part to OpenTelemetry, which standardizes how we capture the core signals: log, metrics, and traces (plus useful context like baggage). In practice, security is an observability problem: if you can reliably see what’s happening, you can separate signal from noise and move from detection to response with confidence. That aligns well with the incident-response lifecycle framing in NIST’s guidance. Put simply, better signals mean better detections, which enable faster, cleaner response.

Detection

In security, logs are the primary raw material for detection and investigation. Treating them deliberately pays off during incident response.

1. Identify & prioritize sources: inventory the systems and services that matter (cloud service providers, identity, endpoints, network, apps) and rank them by risk and investigative value. This is the essence of CIS Control 8 on audit-log management.
2. Integrate and standardize: logs arrive in many shapes. Normalize them so downstream tooling “speaks one language”. OpenTelemetry’s Logs Data Model gives you a stable schema that existing formats can map to cleanly or you can just use JSON.
3. Ingest: your pipeline depends on the target data store. For example, with Grafana Loki, prefer built-in parsers (JSON or logfmt) for reliability and performance.
4. Label, normalize, preprocess: attach meaningful labels (service, environment, tenant, etc.), extract fields, and enforce consistent casing/types to make queries cheap and fast. Follow Loki’s label best practices to avoid high-cardinality pitfalls and look into structured metadata.
5. Store, retrieve, back up: decide storage locations, such as object storage or disk, retention, and index strategy, and back up both data and indexes and try restoring them from time to time. For integrity and chain-of-custody, use controls like write-once storage (object-lock), hashing, and access monitoring.
6. Access & integrity controls: treat logs as evidence: protect audit information and audit tools from unauthorized access, modification, and deletion. Enforce least-privilege read/admin access, make tampering detectable, and make critical stores immutable during retention.
7. Review detection coverage regularly: assume gaps. Periodically reassess which data sources you collect, the fields you parse, and how detections map to them to continuously improve across the detect, respond and recover chain.

Response

Incident response is hard, and yes, often the most stressful part of security. The way to reduce pain is to practice (tabletops and drills) and to balance signal-to-noise so responders aren’t burnt out before the real thing. Your runbooks show their value here.

1. Detection (prepare the runway): once raw logs are flowing, build actionable alerts and monitor them. This is where Sigma and the SRD project turn patterns into tested, deployable rules.
2. Triage (separate signal from noise): triage quickly to validate indicators, suppress false positives, and raise the strong signals of compromise. Treat this as a lightweight gate before deeper analysis. And note that skipping it creates thrash later.
3. Analysis (form and test hypotheses): initial hypotheses from triage are often wrong. Confirm with timelines, correlations, and additional telemetry. Document what you know/assume/need-to-know to keep the team aligned.
4. Containment (stop the bleeding): isolate impacted assets, rotate secrets, disable malicious access paths, and apply compensating controls. Choose short-term vs. long-term containment tactics based on business impact and attacker behavior.
5. Eradication & RCA (remove the cause): eliminate artifacts (malware, persistence, misconfigurations), then work with engineering on root cause with patches, config fixes and guardrails. Security leads forensics and product/infra teams drive permanent remediation.
6. Recovery (return to steady state): restore systems deliberately, monitor closely, and verify that the original indicators do not recur. Define clear “back to green” checks before closing.
7. Post-mortem (blameless learning): within days, run a blameless post-mortem: capture a factual timeline, contributing factors, impact, and actionable follow-ups with owners and due dates. The goal is learning and system improvement, not blame.
8. Communication (from start to finish): coordinate with execs, legal, PR, and customer-facing teams. Keep customers informed with accurate, timely updates. Pre-approved templates and contact lists cut response time and reduce risk.

If you prefer the mnemonic: PICERL, Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned, maps neatly onto NIST’s updated structure. Use whichever framing your team already knows, but anchor it in your playbooks.

How Sigma Comes into Play

Sigma is a vendor-neutral detection format: you write rules once in YAML, and convert them to your backend’s query language with Sigma CLI (which uses pySigma internally) and its plugins. That portability lets you keep detections in Git, review them like code, and reuse them across stacks.

Concretely, Sigma gives you at least three building blocks that matter for an automated pipeline:

• Rules describe the pattern you want to detect over normalized fields (for example, MFA removal from an Okta account). They’re backend-agnostic until conversion.
• Pipelines adapt rules to your data model (field renames, value transforms, casing and placeholders, to name a few), so one rule can target multiple environments cleanly.
• Backends perform the actual conversion (for example, to Loki, Splunk and the like). For Loki, the official pySigma backend can emit plain LogQL queries or ruler YAML for alert generation.

Why this matters for Grafana/Loki alerting, you might say: alert rules evaluate metric queries only. Sigma rules (and especially Sigma Correlations) can be converted into LogQL expressions that aggregate over logs (for example, count_over_time) and thus produce metrics suitable for alerts. This turns noisy per-event matches into actionable, rate-limited signals.

In the SRD project, as detailed below, the CI does a few things on each PR: validate the declarative config, validate the Sigma rule, convert the rule using sigma-cli, integrate the resulting queries into Grafana alert-rule payloads, and deploy the integrated alerts to Grafana Managed Alerting on merge to the default branch. This GitOps loop keeps detections trustworthy, reviewable, and fast to iterate.

Finally, if you’re new to the ecosystem and want a quick feel before wiring CI, try Sigma CLI and community guides, as they show the end-to-end flow of parsing a rule and converting it for your SIEM or log store, like Loki.

Sigma Rule Deployment

SRD is a suite of GitHub Actions that turns Sigma rules in your repo into Grafana-managed alert rules, end-to-end: validate, convert, integrate and deploy. Underneath, it uses sigma-cli (with your chosen backend, like Loki) to produce queries, builds Grafana-compatible rule payloads, and provisions them to your Grafana instance automatically. You get a clean GitOps loop for detections: reviewable PRs, reproducible builds, clear diffs on rules, and automated deployments, while aligning with Grafana’s recommended Grafana-managed alerting model.

This suite contains the following actions, which together form the bigger puzzle:

• Config Validator: checks your SRD config against a JSON schema.
• Sigma Rule Converter: wraps and runs sigma-cli, installs backends dynamically, outputs converted queries + metadata.
• Grafana Query Integrator: maps converted queries into Grafana alert-rule configs.
• Sigma Rule Deployer: pushes incremental or full alert rule sets to Grafana.

To learn more on how to use the project, read the usage section of the README to create your own detection-as-code pipeline.

Conclusion

Treat detections like code: keep them in Git, validate in CI, and ship them automatically. Sigma gives you the portable rule language; sigma-cli turns those rules into LogQL and Grafana Loki converts logs to metrics you can actually alert on, thus closing the loop from signal to response. If you want to start today, grab the repo, wire the Actions, and convert one noisy “log search” into a clean, metric-based alert.