Introducing the Content Management Center: version control for your detection content

Reviewed by ContraForce team ยท Updated 2026-09-04

It is 2am. A detection in tenant 12 has been paging the on-call every night over a service account behaving exactly as it always has. The analyst on shift opens the rule in the workspace, adds an exclusion, saves it, and the queue goes quiet. She was right to do it. She tells nobody, because there is nowhere to tell.

A week later, in a different tenant, the customer's own engineer edits the same detection in the Defender console because it was noisy for them too. His version is not her version. Neither is your version.

Six months on, nobody can say which version of that rule is running in each customer workspace. You sell a standardized service whose description promises every customer the same detection coverage. Underneath, the fleet has quietly gone bespoke, and the only record of how it happened is in someone's memory. That stops being a hygiene problem and becomes a commercial one, because consistency is what you are selling and you cannot demonstrate it.

Detection content is the last surface in managed security delivery that is still edited live, in production, inside a customer's tenant, by whoever had the console open. Code has pull requests. Infrastructure has change control. Your SOPs have Gamebooks with approval gates. Detection rules have a text box and a save button.

Today we are shipping the Content Management Center. Your detections get what the rest of your delivery already has: one definition, a version history, and a record of who changed what. Every workspace runs a version you can name, and the ones that have drifted from it show up as drifted.

It covers Microsoft Sentinel analytics rules and Microsoft Defender XDR custom detections, though Defender needs the customer's tenant consent before ContraForce can see them. It governs the content itself: what a rule says, which version is live, and who approved the last change. What happens after a rule fires does not change. Triage, investigation, and response stay with Security Delivery Agents and Gamebooks.

Start from what is already running

You do not have to author a library to begin. Import pulls the rules already live in a Sentinel or Defender workspace into a repository. It copies the rule. It does not take over the live one. Your existing detections come under version control without anyone touching a customer tenant.

From there the catalog fills the gaps. The marketplace is organized by data source, not by rule, which is the question a provider has: a new data source just connected, what should be monitored? It is not there to write your content. It is there so the baseline stops eating the hours that belong to the detections only your team would think to write.

After that, every change to a rule creates a version, and every deployment records where it landed. That second part is what turns "I think tenant 12 is current" into something you can answer.

What is actually running out there?

Coverage maps every rule against every workspace it was deployed to and tells you whether the two still match. It is an inventory of your detection estate that does not run on anyone's memory.

One caveat matters more than anything else on that screen. Coverage reads deployment history, not a live query. It shows what the repository recorded, so if someone edited a rule in the tenant this morning, coverage does not know yet. A workspace scan is what surfaces edits made outside the Content Management Center.

Coverage tells you what the repository recorded. A scan tells you what is there now. Scan first, then act.

Drifted and outdated are not the same problem

Outdated means the workspace is running an older version of the baseline, unchanged. Nobody did anything. It was not redeployed after the last merge. Deploy it and the state resolves, with nothing lost.

Drifted means someone changed the rule in place, on purpose, and deploying the baseline over it destroys that work. Often that work is the 2am exclusion that has kept a customer's queue clean for months. A bulk redeploy run to tidy up a coverage screen quietly reintroduces noise the team already solved.

So a drifted rule gets a decision instead of a button, and you make it after reading the diff:

None of the three is the wrong answer. What changes is that the decision gets made once, deliberately, by someone who read the diff, rather than by accident by whoever deployed last.

Forks are for the divergence you meant to have

Some divergence is not drift. A customer with a genuinely different environment or a contractual exception needs a permanently different rule, and re-adjudicating that on every scan is its own overhead. A fork is a permanent variant that stays linked to the base rule, with a diff between the two, so the exception moves out of the pile you keep re-deciding and into the variants you declared on purpose.

Review controls, once the fleet is big enough to need them

A two-person team can let edits commit straight to the baseline. A larger team with junior authors turns on protection instead, and edits stop landing directly: they collect, get bundled into a change request, and wait for approval. You decide whether review is required at all, how many approvals it takes, and who is allowed to give them.

Reviewers see the actual change, old value against new, including the query. They can approve it, ask for changes, or fix it themselves. Every one of those actions is recorded with a name and a timestamp, and the write into the tenant is made by ContraForce rather than by someone's personal Azure credentials, which is what makes "who approved this detection" a question with an answer.

Two things to hold onto. Protection is not retroactive: it governs the next change, not the last two years. And merging changes the repository, not your workspaces. Approving a change and releasing it into a customer tenant are different decisions and should not share a button.

The repository does not reach back into a workspace either. Deleting a rule here drops its history and leaves the deployed copy running, so retiring a detection across the fleet is a deployment, not a delete.

Measure it against your own baseline

We are not going to hand you a percentage. Measure three things against your own baseline: the lead time from a rule being authored to that rule running in production, the number of workspaces a new rule actually reaches, and how much analyst time goes to maintaining content rather than creating it.

Start with three workspaces you believe are identical

Do not model the whole fleet first. Create one repository, import the rules from two or three workspaces you believe are running identical content, then scan all of them. The drifted list that comes back is usually the argument for everything that follows.

Repository settings, change requests, and the marketplace pull flow are covered in the Content Management Center overview.

On ContraForce pricing the Content Management Center is an add-on on the Growth plan, and it is included from Scale upward: compare the plans.

To see it against your own workspaces rather than a demo dataset, start a ContraForce trial. No credit card. Connect one workspace, import its rules, and scan a second: create an account. The first drifted rule you find will tell you whether the rest of this post applies to you.

What is "Introducing the Content Management Center: version control for your detection content" about?

The Content Management Center gives every Sentinel analytics rule and Defender XDR custom detection one definition, one version history, and a record of which workspaces have drifted from it. Detection content stops being something edited live in a customer's tenant by whoever had the console open.