Use a hybrid. Set a central floor that every repository must meet, enforced at the organization level, and let repositories add stricter rules or narrow, expiring exemptions locally. Pure per repo policy drifts, and pure central policy ignores real differences between services.
The two models
| Model | Strength | Weakness |
|---|---|---|
| Per repository | Fits each service, teams own it | Drift, gaps, uneven quality |
| Central | Consistent, easy to audit | Rigid, central team becomes a bottleneck |
| Hybrid | Floor plus local flexibility | Needs clear rules about what can change |
Using platform features for the floor
GitHub rulesets show how a floor works. The documentation says rulesets have no priority, that rules from multiple rulesets targeting the same branch are aggregated, and that where a rule differs, the most restrictive version applies. Rulesets also layer with branch protection rules, and all applicable rules are enforced.
That gives you a clean pattern: an organization level ruleset sets the minimum, and a repository can add stricter rules but cannot loosen the floor through its own settings. Bypass is controlled by the actors you list, so keep that list under central control.
What belongs where
| Item | Central | Repository |
|---|---|---|
| Minimum severity to block | Yes | May tighten |
| Known exploited rule | Yes | No |
| License allow list | Yes | May request additions |
| Exemptions | Process is central | Entries are local, with expiry |
| Required check name | Yes | No |
| Dev dependency scope | Default central | May override with approval |
Steps to set it up
- Write the floor as a one page policy.
- Enforce it with an organization level ruleset on protected branches.
- Store local exemptions in each repository, in a file with required reviewers from security.
- Report monthly on repositories that fall below the floor or have many exemptions.
- Review the floor every quarter with engineering leads.
Avoid the central bottleneck
If every change to the policy needs a ticket to one team, developers will work around it. Publish a response time for exemption requests, and automate the easy ones: a narrow exemption with an expiry under 30 days could be approved by a service owner plus one reviewer.
Quick check
Can a repository weaken the central floor?
With layered rulesets, the most restrictive rule applies, so a local setting cannot loosen it. Check how your own platform combines rules.
Where should exemptions be stored?
Near the code they apply to, in version control, with required review.
Safeguard's policies, gates and guardrails can apply across repositories with per project settings. Try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
