Skip to main content
A repository is a library of detection rules plus the settings that decide where it deploys and how it changes. Most organizations need very few: one per detection stack, or one per group of customers who should run the same content.

​
Create a repository

Requires the Manage content permission (Content Admin or Owner).
1

Open the Content Management Center

Navigate to Content Management Center and stay on the Repositories tab.
2

Select New repository

Give it a Name and an optional Description. That is all the dialog asks for, and both are editable later.
3

Add rules

A new repository is empty. Import, pull from the marketplace, or author rules.
4

Configure it

Covered workspaces and baseline protection are set after creation, from the repository’s tabs. Populate the repository first, then turn protection on before other people start editing.
Content Management Center Repositories tab listing repositories with name, description and created date
New repository dialog asking for a name and description

​
Inside a repository

A repository showing the Rules, Workspaces, Work in progress, Change requests, Settings and Audit tabs, with Import rules and Add rule actions
The Rules tab carries the repository’s content, with search and filters for severity, type and platform, plus Import rules and Add rule.

​
Covered workspaces

A repository only deploys to workspaces you have added to it. This is deliberate: it stops a rule intended for one customer reaching every workspace you manage. Set this under Settings, or from the Workspaces tab. Only workspaces your organization manages are eligible.
Removing a workspace from a repository does not remove rules already deployed there. It stops future deployments and stops the workspace being scanned for drift. Remove the deployed rules first if you want them gone.

​
Baseline protection

The repository’s rule set is its baseline. Baseline protection is what turns a repository from a shared folder into a reviewed one, and it is configured under Settings. With Require change requests off, an edit changes the baseline immediately. With it on, additions, edits, removals, imports and marketplace pulls are all staged for review instead: each becomes a work-in-progress item, which must be added to a change request and approved before it changes the baseline.

​
Protection settings

Repository Settings showing repository details and the Baseline protection panel with required approvals, author approval and the approver list
Turning protection on does not retroactively review anything. Rules already in the baseline stay exactly as they are. It changes what happens to the next change.
Required approvals and Repository approvers are set independently, and nothing stops you requiring more approvals than you have approvers. A repository configured that way accepts change requests it can never merge. Check the two together.
While protection is on, a single change request is capped at a fixed number of items. If you are migrating a large rule set, do it before you turn protection on, or split it across several change requests.

​
Sentinel settings

A repository can carry a default target workspace for Microsoft Sentinel. When a deployment does not name a workspace explicitly, this is where it goes. Set it under Settings if most of the repository’s content is destined for one workspace. Leave it unset to be asked every time.

​
Audit

The Audit tab records every action against the repository: rules created, imported, edited, deployed and rolled back; change requests opened, approved and merged; settings changed. Each entry names the actor and the time. This is a read-only record and cannot be edited or cleared.

​
Deleting a repository

Requires the Manage permission.
Deleting a repository removes its rules and their version history from ContraForce. It does not remove rules already deployed to workspaces. Those keep running, and are no longer tracked by anything, so drift on them will stop being reported.