Git for Security Teams

Run detection-as-code: version control, review, and CI/CD.

Git for the workflows security teams actually use, version-controlled detection rules, playbooks, and scripts with branching, conflict resolution, and CI/CD pipelines that deploy rules to Sentinel automatically.

See Pricing

Short Course | Premium tier | 3 hours at your own pace | Updated May 2026

The problem this solves

Git tracks every change to every file. You can see who changed what, when, and why. You can revert to any previous version. You can work on changes in a branch without affecting the main version. When you're ready, a pull request lets a colleague review before merging. For security teams, this means: detection rules have an audit trail, playbooks have version history, scripts can be safely updated and rolled back, and CI/CD can automatically deploy reviewed changes to your SIEM.

What you will be able to do

1. Initialise a repository, commit changes with meaningful messages, and push to GitHub, for any type of security content: Sigma rules, YARA rules, PowerShell scripts, KQL queries, IR playbooks.

2. Use branches to work on changes without breaking the main version. Create feature branches for new detection rules, fix branches for tuning, and merge them via pull request.

3. Review pull requests: read diffs, leave comments, request changes, and approve. The code review workflow adapted for detection content.

4. Resolve merge conflicts when two people edit the same file, the most common Git problem for teams.

5. Set up a basic CI/CD pipeline that validates Sigma rules on push and optionally deploys converted KQL to Sentinel.

Sections

GT0.1

Your First RepositoryInstalling Git, configuring identity, initialising a repo, staging, committing, and pushing to GitHub. The mental model: working directory → staging area → local repo → remote. Applied to a YARA rules directory.

GT0.2

The Daily WorkflowPull, edit, add, commit, push. Writing commit messages that explain why, not what. Viewing history, diffing changes, and checking out previous versions. .gitignore for security content: excluding API keys, credentials, evidence files.

GT0.3

Branching and Pull RequestsCreating feature branches for new detection rules. The branch-commit-push-PR-review-merge cycle. Writing PR descriptions that reviewers can action. Branch naming conventions for security repos: detection/t1059-encoded-powershell, fix/ca001-exclusion-update.

GT0.4

Merge Conflicts and RollbacksWhy conflicts happen, how to read conflict markers, and how to resolve them. Rolling back a bad commit. Reverting a merged PR. The reflog as a safety net. Applied to: two analysts editing the same Sigma rule simultaneously.

GT0.5

CI/CD for Detection RulesGitHub Actions for security repos. A pipeline that validates Sigma rules on push (sigma check), converts to KQL, and optionally deploys to Sentinel via API. Automated testing for detection content. Branch protection rules that require review before merge.

Lab

Guided Lab: Build the NE Detection Rules RepositoryCreate a Git repository for Northgate Engineering's detection rules. Commit the 5-rule INC-2026-0501 Sigma pack. Create a branch for a new rule, submit a PR, review, and merge. Set up a GitHub Action that validates all rules on push. Simulate a merge conflict and resolve it.