Your Sentinel CI/CD Detections Are Now Defender XDR Detections

Microsoft Sentinel's new detections-as-code workflow hands detection engineers a CI/CD pipeline and quietly takes away the safety net that used to catch broken queries for them.

Key takeaways

• Microsoft Sentinel now manages Defender XDR custom detection rules as code: authored in Git, synced on commit and deployed through a Bicep extension.
• Rules managed in a repository miss Microsoft's automatic schema migrations, so a table rename such as AIAgentsInfo to AgentsInfo can silently break them.
• A PR pipeline that validates tables, columns and entity mappings, plus a named owner for schema drift, becomes the safety net.

Why detections as code gets harder on the XDR side

Authoring custom detection rules in GitHub, reviewing them through pull requests, deploying via the same CI/CD pipeline that ships them to Sentinel: that's the operating model most of us have worked under for years. It works well when you're writing rules for logs you control.

What's been challenging is the XDR side. When you move a detection rule out of the Defender portal and into your own repository, you also take on the job of keeping that rule updated when the schema changes, or when tables move from Preview to General Availability and get renamed entirely.

The change: detections as code for Defender XDR

Sentinel's July 2026 update lets teams manage custom detection rules the same way they already manage analytics rules, playbooks, parsers and workbooks in Sentinel: author them in a Git repository, sync them on commit, and deploy through a dedicated Bicep extension that declares Microsoft.Security/detectionRules resources. Query text, scheduling frequency, alert templates, severity, tactics, entity mappings; all of it as code.

It sits alongside other changes landing around the same time. Table Insights gives you an at-a-glance view of ingestion volume and connector health without writing a query, and the UEBA surface keeps expanding: in August, Sentinel added anomaly detection across FortiGate, Check Point and Zscaler firewall and VPN logs, plus AWS GuardDuty findings, mapped to techniques like Valid Accounts (T1078), Brute Force (T1110) and Account Discovery (T1087.004).

Put those together and it's an improvement on two fronts: more detection surface to cover, and engineering teams getting more direct control over how that surface is built and pushed.

The catch: repo-managed rules miss Defender XDR schema changes

Inside the Defender portal, Microsoft has always quietly kept your saved queries working when the underlying schema changes: table renames, deprecated columns, the kind of changes that happen in the background or are only revealed in a blog post you missed.

A recent example: the AIAgentsInfo table was migrated to AgentsInfo when it went from Preview to General Availability, and queries saved in the XDR portal that referenced the old name were updated automatically. That automatic migration does not extend to rules managed in a code repository. Your XDR platform cannot see into your Git repo to make changes there.

A detection rule sitting in your Git repo, deployed via CI/CD, keeps referencing whatever table name and schema it was written against until someone on your team notices it's gone quiet and fixes it. Worse, a stale repo-managed rule can persist alongside, or even override, a migrated version with no alert telling you it's happened. You've effectively taken over schema lifecycle management for every rule you moved, which makes monitoring rule health and validation more important than ever.

The checks that matter before you merge a detection change are no longer optional nice-to-haves. They're the actual safety net. Sanity checks worth automating into a PR pipeline:

1. No references to deprecated or transitioning tables (AIAgentsInfo to AgentsInfo, and so on).
2. Required result columns are present: Timestamp / TimeGenerated and device identifiers.
3. Entity mappings are complete, not just "good enough for the alert to fire".
4. No filtering on ingestion timestamp fields inside the query itself. The service already prefilters by ingestion time, and doing it again in-query adds cost without changing results.

Portal-managed vs repo-managed detection rules

Writing KQL detections like they're going to outlive you

If you're taking on this responsibility, it's worth treating the query logic itself with the same discipline you're applying to the pipeline around it. A detection engineering write-up on kqlquery.com doing the rounds this year put some numbers against choices most of us make on instinct:

• has searches on delimited terms rather than scanning substrings. In their testing it ran at 358ms against 863ms for contains with equivalent logic.
• The in~() operator went further still, coming in at 31ms of CPU against 171ms for contains and 78ms for has on the same dataset.

None of that will show up as a functional bug in testing, because the query still returns the right results. It shows up as cost, and as throttled detections at scale. It's not something to be overly concerned about when you have a small number of detections, but getting the discipline right early is easier than fixing the problem retrospectively further down the line.

There's also a case for treating readability as a control, not a preference:

• Consistent variable naming across your rule set. Pick TimeFrame and use it everywhere, not TimeSearch in one rule and t in another.
• let statements at the top of a query, so thresholds and lookback windows are visible without reading the whole thing. Use project-reorder in place of a restrictive project, so analysts investigating an alert still have the raw context around it rather than just the five columns someone decided mattered at write time.
• A comment on every allowlist exclusion explaining what it excludes, why, and who added it. Six months from now, someone is going to want to know why 15 exclusions exist, and the person who wrote them may not be there to answer that question.

None of this is over the top. It's the same general discipline you'd expect in any code review process, and the benefits keep paying off further down the line.

What detections as code actually needs from a SOC team

None of this works without someone owning it. A detections-as-code migration that's just "we moved the YAML", without a corresponding PR checklist, a test against a sample dataset, and a named owner for schema drift, is a migration that trades a visible problem (rules living in the portal, hard to review) for an invisible one (rules quietly rotting in a repo nobody's watching).

The invisible problems are worse precisely because they're silent. A broken analytics rule in the portal at least shows up as "no alerts" somewhere someone might notice. A broken rule in a repo just sits there with a green tick, because the deployment succeeded, telling you nothing about what it's actually doing now that it's running against your log data.

Closing thoughts on Sentinel detections as code

Detections-as-code is worth doing, and worth doing with an established, well-understood discipline driving it forward. Version control, peer review and CI/CD are better than a rule sitting unreviewed in a portal.

If you're mid-migration, or about to start one, the useful next step isn't writing more rules. It's writing the checklist that catches the rule that quietly stops working, and deciding now who's accountable for noticing when it does.

Frequently Asked Questions

Can Microsoft Sentinel manage Defender XDR custom detection rules as code?

Yes. Since the July 2026 update, Sentinel repositories can sync Defender XDR custom detection rules from Git on commit and deploy them through a Bicep extension that declares Microsoft.Security/detectionRules resources, covering query text, frequency, alert templates, severity, tactics and entity mappings.

Does Microsoft update repo-managed detection rules when a table is renamed?

No. Microsoft automatically migrates queries saved in the Defender portal, as it did when AIAgentsInfo became AgentsInfo at General Availability, but that migration does not reach rules stored in your own repository. Your team has to update them.

What should a detections-as-code PR pipeline check?

At minimum: no references to deprecated or renamed tables, required result columns such as Timestamp or TimeGenerated and device identifiers, complete entity mappings, and no in-query filtering on ingestion timestamps, which the service already prefilters.

Which KQL operator is fastest for detection rules?

In published testing on kqlquery.com, in~() used 31ms of CPU against 78ms for has and 171ms for contains on the same dataset. Prefer has or in~() over contains wherever the logic allows.

Who should own schema drift for repo-managed detections?

A named detection engineer or SOC lead, not the pipeline. The deployment succeeding only proves the rule was accepted, not that it still matches your data. Many teams pair that owner with a 24/7 SOC or regular threat hunting so a rule that goes quiet is noticed quickly.

Related reading

• Managed SIEM for Microsoft Sentinel: Microsoft Sentinel operated within our managed SOC, with 24/7 UK analysts.
• MDR vs SOC vs SIEM: which operating model fits your detection programme.
• What is a managed SOC?
• Understanding managed detection and response
• How Precursor's SOC detected Microsoft Direct Send phishing: a real SOC detection, with the KQL hunting query for Defender Advanced Hunting.

References

1. What's new in Microsoft Sentinel, Microsoft Learn, updated September 2026
2. What's new in Microsoft Sentinel: July 2026, Microsoft Tech Community
3. Custom Detection Rules as Code in Sentinel Repositories: What Your Pipeline Owns Now, Microsoft Tech Community
4. DxBP Part 2: Detection Engineering Best Practices: Performance, Readability & Maintenance, kqlquery.com
5. KQL Sources: 2026 Update, kqlquery.com
6. Detections Digest #20260831, RuleCheck.io
7. Microsoft Sentinel Adds Detections-As-Code, Table Insights, and New Data Connectors, Petri