Set the baseline once at the organization level, using rulesets and shared pipeline templates, allow overrides that are documented and reviewed, and audit for drift on a schedule. Copying settings repo by repo does not scale past a handful of repositories and drifts within weeks.
Why drift happens
Every repo starts from a copy of something. Then a team tweaks a threshold to unblock a release, someone forgets to revert it, and a year later no two repos match. When an incident happens, nobody can say which repos had the check turned on.
Three layers that work together
| Layer | What it controls | Example |
|---|---|---|
| Organization rules | Branch protection and required checks across many repos | A ruleset targeting all repos, or repos with a given property |
| Shared pipeline templates | The scan step itself, versioned in one place | A reusable workflow that every repo calls |
| Repo level config | Allowed local tuning | Paths to exclude, with a reason |
GitHub's organization rulesets can target all repositories, a selected list, name patterns, or repositories matching custom properties. Only organization owners can edit a ruleset that targets a repository, and repository admins can add repository level rulesets that only make rules stricter, never looser. That asymmetry is useful: teams can tighten but not quietly loosen.
Make overrides visible
Allow local overrides, because blanket rules break legitimate cases. Require each override to carry a reason and an owner, stored in the repo where reviewers can see it. Then query for overrides across the organization every month.
Good override: exclude a generated code folder, with a note that it is rebuilt from a schema.
Bad override: lower the severity threshold to pass a release, with no end date.
Watch the status check names
When a shared workflow is used in many repos, required checks are matched by name. GitHub advises making job names unique across workflows, because reusing a name can cause ambiguous status results and block pull requests. Pick a naming convention for the security check and keep it stable, or a rename will quietly turn a required check into one that never reports.
Audit drift
Once a month, list repos where the required security check is missing, disabled, or overridden. Send each team a short list. Treat the first audit as a baseline, not a punishment.
Quick check
Should the security team own the shared pipeline template?
Co-own it with platform engineering. Security sets the intent, platform engineering handles versioning and speed, and teams can open pull requests against it.
How do you roll out a change to the shared template safely?
Version it, release to a few repos first, watch scan time and failure rates, then widen. Keep the previous version available for a quick rollback.
Sources
- GitHub Docs, Creating rulesets for repositories in your organization
- GitHub Docs, About protected branches
Last reviewed: 19 October 2026.
