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

Reviewed by ContraForce Security Operations Team · Updated 2026-08-12

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, a versioned repository system that manages detection content before it reaches a customer environment. It covers Microsoft Sentinel analytics rules and Microsoft Defender XDR custom detections. A rule has one definition and a version history. Every workspace running it is running a known version, not a copy somebody edited in place.

It governs the content itself: what a rule says, which version of it is live, and who approved the last change. It does not change what happens after a rule fires. Triage, investigation, and response stay with Security Delivery Agents and Gamebooks.

One definition, one version history

A repository is a library of detection rules plus its deployment settings and change governance. Most teams keep one per detection stack, or one per group of customers that needs an identical rule set. You fill it three ways: import rules already running in a Sentinel or Defender workspace, pull templates from the ContraForce marketplace, or write them in the built-in editor, which captures severity, platform, query logic with a test function, MITRE ATT&CK and entity mappings, and tags.

The marketplace catalog is organized by data source rather than by rule, which is the question a provider actually 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.

Import is where most providers start, and it is deliberately non-invasive. Importing copies the rule into the repository. It does not take over the live rule. You can build an accurate baseline out of what is already running without touching a customer tenant.

Every baseline change then creates a new version. Each rule keeps a History tab with every version, its change type, author, timestamp and message, and those messages document origin automatically: imports reference their source, merges reference the change request. On deployment, ContraForce validates the rule against the target workspace, deploys it, and records provenance in the target. That last step is what makes drift detection a fact rather than a guess.

What is actually running out there?

That is what the Workspaces tab answers. Coverage maps every rule against every workspace the repository deploys to and sorts them into four states: In sync, Outdated, Drifted, and Not deployed.

One caveat matters more than anything else on that screen. Coverage reads deployment history, not a live query. It shows what this repository recorded as live in the workspace. If someone edited a rule in the tenant this morning, coverage does not know yet. To see current reality you run a workspace scan, which is how edits made outside the Content Management Center surface.

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 the workspace copy diverged from the baseline. Someone changed it 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 three paths, each chosen after reading the diff:

• Accept drift. You acknowledge the divergence, ContraForce stops flagging it, and the workspace keeps its own version.
• Adopt as baseline. The workspace change is promoted to the new standard, and the rest of the fleet can be brought up to it.
• Deploy baseline. The workspace change is overwritten, because the standard was right and the local edit was not.

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. The rhythm is the same every time: scan, deploy the outdated rules because they carry no judgment, then work the drifted list one diff at a time.

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 customer-specific 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. Edits then stop committing directly. They collect as work in progress, get bundled into a change request, and require approval. Per repository you set whether change requests are required, how many approvals are needed, whether authors may approve their own, and who may approve at all.

Reviewers see field-level diffs of old versus new values plus the underlying query, and can approve, request changes, or edit an item directly rather than reject the request. The Audit tab holds a read-only record of imports, edits, deployments, rollbacks, and change request processing, each with an actor and timestamp.

Two things to hold onto. Protection is not retroactive, so it governs the next change rather than the last two years of them. 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.

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.

Limits worth knowing before you start

• Nothing here reaches back into a workspace. Removing a workspace stops future deployments and stops it being scanned for drift. Deleting a rule or a whole repository clears the version history from ContraForce and leaves the deployed copies running.
• A rule pulled from the marketplace does not stay linked to its template, so later template updates do not propagate.
• Platform choice follows the data, not preference. A rule querying tables only present in Defender advanced hunting must be a Defender custom detection, and one querying Log Analytics tables must be a Sentinel analytics rule.
• Microsoft Defender XDR requires tenant consent before ContraForce can reach custom detections, and adding rules or changing a repository needs the Author or Manage content permission.

The full guide covers repository settings, change request states, and the marketplace pull flow: Content Management Center overview.

Where to start

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 first honest inventory a provider has had of its own detection estate, and it is usually the argument for everything that follows.

One thing worth confirming on the way in, because your change board will ask: rule writes are performed by the ContraForce application, not by an engineer's personal Azure credentials, and every action lands in the Audit tab with an actor and a timestamp.

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?

Detection rules are the last thing in managed security delivery still edited live inside a customer's tenant. 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.