Building a detection-as-code pipeline with Sigma and CI/CD

Detection engineering has matured beyond writing one-off SIEM rules by hand. For many UK SMEs, the practical next step is to treat detections as code: version them, review them, test them, promote them through environments, and measure whether they still do what you expect. That is where a detection-as-code pipeline with Sigma and CI/CD becomes useful.

Sigma gives you a portable rule format for describing suspicious activity in a SIEM-agnostic way. CI/CD, or continuous integration and continuous delivery, adds the engineering discipline around it. Together, they help small security teams reduce drift, improve change control, and make detection work repeatable rather than dependent on individual analysts remembering how a rule was built last time.

This is not about automating everything and removing judgement. It is about creating a controlled workflow for detection content so that changes are visible, testable, and traceable. That matters when you are supporting a mixed estate of Microsoft 365, Windows endpoints, cloud services, and perhaps a smaller amount of on-premises infrastructure. It also fits neatly alongside broader logging and visibility work, such as the approach described in building SIEM detections using Sigma rules and the wider visibility patterns in unified threat detection across endpoint, identity, and network.

What detection-as-code means in practice

At a practical level, detection-as-code means storing detection logic in source control alongside the supporting artefacts needed to validate and deploy it. A Sigma rule is usually the human-readable source file. The pipeline then validates the rule, translates it into the target platform syntax, runs tests, and publishes the resulting detection only if it passes the required checks.

That gives you a few immediate benefits. First, every change has an author, a review trail, and a history. Second, you can compare versions and understand why a rule changed. Third, you can apply the same quality gates to every detection, rather than relying on ad hoc manual review. For a small team, that consistency is often more valuable than raw automation volume.

How Sigma fits into a detection-as-code workflow

Sigma is best thought of as a common representation layer. It is not the final query language for your SIEM, and it is not a substitute for understanding the telemetry source. A Sigma rule describes the event category, the fields of interest, the matching logic, and the context needed to interpret the alert. The same rule can then be translated into KQL for Microsoft Sentinel, SPL for Splunk, or another backend query language, subject to the limitations of the target platform.

That portability is useful, but it has boundaries. A rule that works cleanly against Windows Event Logs may need different field names or filtering logic once translated for a cloud audit source or an EDR telemetry feed. The source format helps standardise intent, but it does not remove the need to understand the underlying data model.

What CI/CD adds for versioning, review, and repeatability

CI/CD adds the operational controls that detection content often lacks. In a mature pipeline, a pull request triggers validation, linting, translation, and test execution. Approved changes are then promoted to a test environment and, after further checks, to production. That gives you repeatable releases and a clear separation between authoring and deployment.

For SMEs, the main value is not speed for its own sake. It is confidence that a rule change will not silently break production detections or flood analysts with low-value alerts. If you already use CI/CD for application code, the pattern will feel familiar. The difference is that the artefacts are detection rules, test fixtures, and deployment templates rather than application binaries.

When a detection-as-code approach is worth adopting

You do not need a large SOC to benefit from this model. It is often most useful where a small team is responsible for multiple log sources, where detection content changes frequently, or where the organisation wants better governance over security operations. If your analysts are spending time manually copying rules between environments, or if nobody can say which version of a detection is live, the case for detection-as-code is already strong.

Typical use cases for small security teams and SOCs

Common use cases include identity abuse detections, suspicious PowerShell activity, endpoint persistence, cloud admin changes, and high-risk authentication patterns. These are the sorts of detections that benefit from repeatable testing because they often depend on subtle field combinations and can be noisy if tuned badly. A pipeline also helps when you need to roll out the same logic across multiple tenants or business units with slight variations.

It is particularly helpful when detections are part of a broader control set. For example, if you are already hardening endpoints using endpoint hardening using CIS Benchmarks, you can align your detections to the telemetry those baselines generate. Likewise, if you are improving your logging estate, a detection pipeline gives you a structured way to consume the new data without turning each rule into a one-off project.

Common limits and trade-offs to plan for

The main trade-off is operational overhead. You will need repository management, test data, release discipline, and someone who owns the content lifecycle. Sigma also cannot fully abstract platform differences, so translation failures and field mismatches need to be expected and handled. In practice, the pipeline reduces manual work over time, but only if you invest in the foundations.

There is also a risk of overengineering. If you have only a handful of mature detections and limited telemetry, a lightweight workflow may be enough. The goal is not to build a software factory for its own sake. It is to make detection content reliable enough that analysts trust it and managers can see how it changes.

Designing the pipeline from source control to production

A workable pipeline usually starts with a Git repository and ends with a deployment mechanism into the SIEM or detection platform. The stages in between should be explicit. A simple pattern is: author, validate, translate, test, approve, deploy, and monitor. Each stage should fail closed if the required checks do not pass.

Repository structure for rules, tests, and deployment assets

Keep the repository structured so that rules, test data, and deployment artefacts are separated. A common layout is a rules/ directory for Sigma files, a tests/ directory for sample events and expected outcomes, and a deploy/ directory for platform-specific templates or pipeline scripts. If you support multiple backends, keep translation outputs in a build artefact location rather than committing generated queries back into source control.

Include metadata with each rule, such as owner, severity, intended data source, and a short rationale. That makes review easier and helps with operational handover. It also supports later reporting on coverage and ownership, which matters when the team changes or the content set grows.

Branching, pull requests, and approval gates

Use pull requests for all changes, even if the team is small. The review does not need to be bureaucratic, but it should be deliberate. A good review checks the logic, the data source assumptions, the expected alert volume, and whether the rule duplicates an existing detection. For higher-risk rules, require a second reviewer with platform knowledge.

Approval gates should be tied to the pipeline, not to informal chat messages. If a rule fails linting or translation, it should not be deployable. If a rule changes a high-volume detection, it should require explicit sign-off from the detection owner or SOC lead. That separation of duties is useful even in small teams because it reduces the chance of accidental production noise.

Promotion between development, test, and production environments

Promote detections through environments in the same way you would promote application changes. Development is where the rule is authored and first validated. Test is where you run it against representative data and observe alert volume. Production is where it operates against live telemetry.

Where possible, use a replay or simulation dataset in test that includes both benign and suspicious events. If you have a purple-team or validation process, feed those results into the test stage before production release. That approach aligns well with the operational discipline discussed in measuring detection quality and false positives.

Writing Sigma rules that are maintainable

Good Sigma rules are readable, specific, and easy to maintain. The best rule is not the most clever one. It is the one another engineer can understand six months later without reverse-engineering the intent from a translated query.

Rule fields, metadata, and naming conventions

Use consistent naming conventions that describe the behaviour, not the platform. For example, a title such as suspicious PowerShell encoded command execution is more useful than a vendor-specific query label. Populate the description with the detection intent, the likely attacker behaviour, and the main telemetry source. If the rule is intended to detect a known technique or abuse pattern, say so plainly.

Metadata should include references to the log source, severity, status, and owner. If your pipeline supports it, store a review date and a last-tested date. That makes stale content easier to identify. Avoid overloading the rule with too many conditions just to reduce noise. If a rule becomes too broad or too narrow, split it into separate detections with clearer intent.

Using tags and MITRE ATT&CK mappings consistently

MITRE ATT&CK mappings are useful when they are applied consistently and with context. Tag the technique or sub-technique that the rule is intended to detect, but do not treat the mapping as a substitute for actual validation. A rule can map to a technique and still be weak if the telemetry is poor or the logic is too generic.

Use the mapping to support prioritisation and coverage analysis. For example, if you have good endpoint telemetry but weak identity coverage, that should be visible in the backlog. Consistent tagging also helps when you want to compare detections across business units or align them to a broader control framework.

Keeping rules portable across SIEM platforms

Portability depends on disciplined use of fields and operators. Prefer common concepts such as process name, parent process, command line, user, host, and source IP where possible. Be cautious with platform-specific shortcuts that make a rule hard to translate. If a detection relies on a field that only exists in one backend, document that dependency clearly.

In practice, some rules will remain platform-specific. That is acceptable. The aim is not perfect abstraction. It is to keep the source of truth in one place and make the platform differences explicit rather than hidden in manual edits.

Validating rules before they reach production

Validation is where detection-as-code becomes more than version control. Without tests, you have a repository of intentions rather than a reliable engineering process. At minimum, validate syntax, schema, and translation. Better still, test the rule against known event samples and expected outcomes.

Static checks, schema validation, and linting

Static checks should catch malformed YAML, missing required fields, unsupported operators, and inconsistent metadata. Sigma tooling can perform schema validation and translation checks as part of the pipeline. Add linting rules for naming conventions, required tags, and owner fields so that content quality is enforced automatically.

If you use a build runner such as GitHub Actions, GitLab CI, or Azure DevOps, make the validation job fast enough that developers actually use it. Slow pipelines tend to be bypassed. For detection content, quick feedback is especially important because analysts often iterate on rules in small steps.

Unit-style tests with sample events and expected matches

Unit-style tests are one of the most valuable additions you can make. Store sample benign and malicious events in a controlled test set, then assert whether the rule should match each one. This does not need to be elaborate. A small set of representative cases is enough to catch obvious regressions when a field name changes or a filter is tightened.

For example, if a rule is intended to detect suspicious command-line usage, include at least one benign administrative example, one obvious malicious pattern, and one borderline case. That helps you understand whether the rule is too broad, too narrow, or dependent on a field that is not always present.

Testing for false positives and obvious blind spots

False positives are not just an analyst annoyance. They affect trust and can lead to alert fatigue. Before production, estimate how often the rule will fire on normal activity. If the alert volume is high, consider whether the logic should be refined, whether the source data is too noisy, or whether the rule should be converted into a hunt rather than an alert.

Also look for blind spots. A rule may only work when a specific logging feature is enabled, or only on one operating system version, or only for one subset of users. Document those assumptions in the rule metadata and in the deployment notes so that operations teams know what the detection does not cover.

Converting Sigma into platform-specific detections

Translation is where many pipelines become fragile. Sigma can express the detection intent, but the target platform decides how that intent is executed. The translated query may need field remapping, syntax adjustments, or additional filters to account for backend quirks.

Translation targets for Microsoft Sentinel, Splunk, Elastic, and similar platforms

Most teams will end up translating to one or more of KQL, SPL, or Elasticsearch query syntax. The pipeline should generate these outputs automatically and store them as build artefacts. That gives you traceability and makes it easier to compare how the same rule behaves across platforms.

Where a platform has native detection features, such as scheduled analytics rules or correlation logic, keep the Sigma source as the canonical version and generate the platform-specific implementation from it where possible. If the backend requires manual adaptation, record that exception in the repository so the next maintainer knows why the output differs.

Handling query differences and platform-specific fields

Field differences are the most common source of translation problems. A Sigma rule may refer to a generic field name that maps cleanly in one backend but not another. The pipeline should fail or warn when a field cannot be translated reliably. Silent translation is dangerous because it can produce a query that looks valid but does not actually match the intended events.

For complex rules, it is often better to maintain a small set of platform-specific overrides than to force one generic rule to fit every backend. That keeps the source manageable while acknowledging the reality of different telemetry schemas.

Managing exceptions without weakening the rule

Exceptions should be narrow and documented. If you need to exclude a service account, a management subnet, or a known benign process path, record why the exception exists and when it should be reviewed. Avoid broad exclusions that remove the very behaviour you are trying to detect.

A useful pattern is to keep suppression logic outside the Sigma source where possible, especially if the suppression is environment-specific. That preserves the portability of the rule while allowing local operational tuning in the SIEM or deployment layer.

Automating deployment safely in CI/CD

Safe automation is about control, not just convenience. The pipeline should make it easy to release a detection, but hard to release an untested or unauthorised one. That means using service accounts with limited permissions, storing secrets securely, and separating build from deployment.

Typical pipeline stages and quality gates

A practical pipeline might include these stages: commit, lint, schema validation, translation, unit tests, package artefact, approval, deploy to test, smoke test, approval, deploy to production. Not every team needs every stage on day one, but the sequence should be clear. If a stage is skipped, it should be a conscious decision rather than an accident.

Quality gates can include required approvals, minimum test coverage for the rule set, and checks that the translated query compiles in the target platform. If you have a staging tenant or test workspace, use it. Production should not be the first place a new detection sees real data.

Secrets handling, access control, and change separation

Do not store SIEM credentials, API tokens, or deployment keys in the repository. Use the secret store provided by your CI/CD platform or a dedicated secrets manager. Limit deployment credentials to the minimum required scope, ideally to the specific workspace or rule set being managed.

Where possible, separate the person who writes the rule from the person or role that approves production deployment. In a small team, that may be a peer review rather than a formal segregation of duties, but the principle still matters. It reduces the chance of accidental or unreviewed changes reaching live monitoring.

Rollback and release traceability

Every deployment should be traceable back to a commit, a reviewer, and a pipeline run. If a rule causes noise or misses expected events, you need to be able to roll back quickly. Keep previous versions available and make rollback part of the release process, not an emergency improvisation.

Release notes for detection content do not need to be long, but they should explain what changed, why it changed, and what operational impact is expected. That helps analysts understand whether a spike in alerts is a bug, a tuning change, or a genuine shift in activity.

Operationalising detections after deployment

Deployment is not the end of the job. A detection that looks good in test can behave differently in production because of data volume, user behaviour, or missing telemetry. The pipeline should therefore include feedback loops from the SOC or analyst function back into the repository.

Alert tuning, suppression, and exception review

Use suppression carefully and review it regularly. Suppression is useful when a known benign pattern is unavoidable, but it should not become a blanket way to hide noisy detections. If a suppression is added, record the reason, the scope, and the review date.

Where a rule is persistently noisy, decide whether to tune the logic, change the data source, or downgrade the rule to a hunt. Not every interesting pattern deserves a high-priority alert. The right operational outcome is a detection set that analysts can actually use.

Tracking precision, recall, and alert volume

For most SMEs, precision and alert volume are the most practical metrics. Precision tells you how many alerts are genuinely useful. Alert volume tells you whether the team can sustain the workload. Recall is harder to measure in production, but you can approximate it through simulation, purple-team validation, or retrospective analysis after incidents.

Track these metrics over time. A detection that becomes noisier after a platform change or identity migration should be visible in the metrics before it becomes a problem for the team.

Feeding analyst feedback back into the repository

Analyst feedback should become repository changes, not just chat history. If an analyst identifies a false positive pattern, update the rule, the test data, and the documentation. If a rule repeatedly produces low-value alerts, capture that decision in the backlog so it can be reworked or retired.

This is where detection-as-code supports continuous improvement. The repository becomes the record of what the team has learned about the environment, not just a collection of queries.

Measuring detection coverage and maturity

Coverage matters because a well-tuned rule set can still leave large blind spots. A mature detection programme maps rules to ATT&CK techniques, priority assets, and telemetry sources so that gaps are visible. That does not mean every technique must be covered equally. It means you know where your strongest and weakest areas are.

Mapping rules to ATT&CK techniques and priority assets

Use ATT&CK mappings to answer practical questions such as which techniques are covered for domain controllers, which detections exist for privileged cloud accounts, and which rules depend on endpoint telemetry that may not be present on all devices. This helps prioritise work based on business-critical assets rather than on whichever alert happened to be written last.

If you already maintain a detection quality process, align it to the same taxonomy so that coverage and performance can be reviewed together. That makes it easier to justify investment in new telemetry or additional detections.

Identifying coverage gaps across identity, endpoint, and cloud telemetry

Many SMEs discover that their strongest visibility is on endpoints, while identity and cloud control-plane events are less complete. That is a common gap because identity attacks often generate fewer obvious signals than endpoint malware. A detection-as-code backlog should therefore include coverage by telemetry domain, not just by rule count.

Where gaps exist, decide whether the answer is more logging, better parsing, or a new rule. Sometimes the right fix is to improve the source data before writing another detection.

Using coverage metrics to guide backlog prioritisation

Coverage metrics are useful only if they influence prioritisation. A simple backlog can rank detections by business criticality, technique prevalence, and current telemetry quality. That helps you focus on the detections that reduce the most risk for the least operational effort.

For UK SMEs, this usually means prioritising identity abuse, privileged access, endpoint persistence, and cloud admin activity before chasing lower-value edge cases. The exact order depends on your environment, but the principle is the same: build detections where they will materially improve response.

A practical starter pattern for UK SMEs

If you are starting from scratch, keep the first version small. Use one repository, one build pipeline, one test environment, and a limited set of high-value rules. The aim is to prove the workflow, not to cover every possible attack path on day one.

Minimum viable toolchain and team roles

A minimum viable stack might include Git for source control, Sigma for rule authoring, a CI runner such as GitHub Actions or Azure DevOps, a translation tool, and a test workspace in your SIEM. The team can be small: one person writes and maintains rules, one person reviews changes, and one person owns deployment or platform administration. In a very small team, those roles may overlap, but the responsibilities should still be explicit.

What to automate first and what to keep manual

Automate syntax checks, translation, packaging, and deployment to test first. Keep production approval manual until the team is comfortable with the workflow. It is also sensible to keep exception handling and major tuning decisions manual at the start. That preserves human judgement where context matters most.

Once the process is stable, you can automate more of the release path, but only if the quality gates remain strong. Automation should reduce repetitive work, not reduce scrutiny.

How to scale the pipeline without overengineering it

Scale by adding rules, not by adding unnecessary complexity. If the repository grows, introduce rule ownership, review SLAs, and a simple retirement process for stale detections. If you support multiple platforms, add translation targets one at a time and document the differences clearly.

That incremental approach is usually the right fit for SMEs. It keeps the pipeline understandable and avoids building a system that only one engineer can operate.

Common mistakes to avoid

The first mistake is treating Sigma as a one-size-fits-all detection layer. It is a useful abstraction, but it does not remove the need to understand telemetry quality, backend limitations, or environment-specific tuning. The second mistake is skipping test data. Without representative events, you are deploying assumptions rather than detections. The third mistake is allowing rule sprawl without ownership, review, or retirement. Old rules can become as much of a problem as missing ones.

Another common issue is focusing on quantity over quality. A large rule library is not valuable if analysts ignore most of it. A smaller, well-tested set of detections that maps to your real risks is usually a better investment.

If you want to strengthen the surrounding control environment as well, it is worth pairing detection engineering with endpoint hardening, logging design, and response planning. Those controls reinforce each other rather than operating in isolation.

For teams that want help turning this into a practical operating model, a consultant can help define the workflow, review the control points, and align the pipeline to your existing security operations and governance needs. If that would be useful, you can speak to a consultant.

Frequently asked questions

Do you need a SIEM to use detection-as-code?

You need some platform that can evaluate detection logic against telemetry, but the exact backend can vary. Sigma is the portable source format, while the SIEM or detection platform is where the translated rule runs.

How do you stop Sigma rules from becoming noisy or hard to maintain?

Use consistent metadata, keep rules focused on one behaviour, test them against representative data, and review alert volume after deployment. If a rule stays noisy, tune it, split it, or retire it rather than letting it drift.