A platform or security group should own the defaults, the pipeline integration and the exception process. Each directory owner should own triage, fixes and requests for exceptions in their area. Splitting responsibility this way avoids a central bottleneck and avoids every team inventing its own rules.
Why ownership is unclear in a monorepo
In separate repositories, each team controls its own configuration by default. In a monorepo, one configuration file at the root can affect hundreds of developers. A change that suits one team can block another, and nobody is sure who may edit it.
Who owns what
| Item | Owner | Reason |
|---|---|---|
| Default rules and severity thresholds | Platform or security | Needs consistency across teams |
| CI integration and scan performance | Platform | Shared infrastructure |
| Exclusion list for rebuilt output | Platform | Applies repository wide |
| Triage of findings in a directory | Directory owner | Knows the code |
| Fixes and upgrades | Directory owner | Can test the change |
| Exception requests | Directory owner proposes; security approves | Separation of duty |
| Baseline file | Platform, with directory owners reviewing their parts | Shared record |
Put the rules in files with owners
Keep scanner configuration in the repository and protect it with the same ownership file used for reviews, so a change to the root configuration requires approval from the platform group. A team that wants a stricter rule for its own directory can add a scoped file, subject to review by the platform group and by its own members.
Say who may loosen a rule and who may tighten one. Tightening can be broad; loosening should require a reason and approval.
A short charter
Write a half page document with these parts:
- What the scanner is for.
- Who owns defaults and who owns exceptions.
- How a team asks for a change, and how long a reply takes.
- What happens if the platform group is unavailable.
The last point matters. A gate with a single approver who is on holiday stops work. Name a backup.
Avoid two failure modes
Central bottleneck: if every exception needs the same two people, teams stop asking and work around the tool. Give approval rights to a small group, with response time targets.
Free for all: if each team edits the root configuration, the result is a collection of conflicting rules and nobody can explain why one directory is stricter than another.
Review regularly
Once a quarter, list all exceptions and scoped overrides, with owners and expiry dates. Remove anything expired. Share the list with leadership as a short note, so the exception count is visible.
Where Safeguard fits
Safeguard policies can be applied at different scopes, with gates and guardrails that platform and security teams manage, and audit trails support the quarterly review. A free scan is available at https://gold.safeguard.sh/scan.
Quick check
Should developers be allowed to disable the scanner for their directory?
No. They can request an exception with a reason and expiry, approved by someone outside the team.
Who answers when a gate blocks a release at night?
Name an on call approver and a documented bypass path, and review every bypass the next working day.
Last reviewed: 19 October 2026.
