Own the policy centrally (what blocks, what warns, which severities) and let repositories own scope (paths, languages, known false positives) with expiry dates. That layered split keeps standards consistent without forcing the platform team to approve every single ignore rule or path exclusion that a team needs.
Three models compared
| Model | How it works | Strength | Weakness |
|---|---|---|---|
| Fully central | One config in the platform repo, callers cannot change it | Consistent, easy to audit | Slow to adapt; teams work around it |
| Fully per repo | Each repo has its own config file | Fast, local knowledge | Drift, weak coverage, nothing to compare |
| Layered | Central defaults, repo level overrides inside limits | Balance | Needs tooling to show overrides |
What belongs at each layer
Central layer:
- Severity thresholds for block and warn
- Which scan types run at which stage
- License allow and deny tiers
- Expiry rules for exceptions
Repository layer:
- Paths to exclude, such as vendored code or generated files
- Language or framework settings
- Suppressions for specific findings, with a reason and a date
Service criticality can add a middle layer. A payments service may use stricter thresholds than an internal tool. Tag repositories with a property and choose the policy from the tag.
How to keep overrides honest
Overrides are where drift hides. Three habits help:
- Store overrides in the repo as a file that needs code owner review.
- Require a reason and an expiry date on every suppression.
- Report the count of active overrides per team each month. A rising count is a signal, not a verdict.
Handling disagreement
When a team believes a central rule is wrong, ask for evidence: a finding, the code path, and why it is not exploitable. Reachability data helps here, because it shows whether the vulnerable code is actually called. If the rule is wrong, change it centrally so every team benefits.
A starting setup
Put defaults in a shared repo, version them with tags, and let the shared pipeline fetch the policy at the pinned version. Add a small file in each repo, for example security.yaml, that can only narrow scope or add dated suppressions. Anything that lowers a severity threshold needs a platform team approval.
Quick check
Is a fully central config ever right?
Yes, for a small org or a regulated service where uniformity matters more than speed. Even then, provide an exception route.
How do we stop teams ignoring everything?
Require reasons and expiry dates, review overrides by code owners, and report counts so the pattern is visible.
Safeguard supports organization level policies and gates and reachability analysis, which can help ground override discussions in evidence.
Last reviewed: 19 October 2026.
