Large organizations keep scanning consistent by putting policy in one place, building an inventory of every repository, applying scans by default through shared pipeline templates, and tiering by risk. Individual teams can tune within limits, but cannot opt out silently.
The problem is coverage, not tooling
With over a hundred engineers and hundreds of repositories, the question changes from "what should we scan?" to "which repositories are we not scanning at all?" Unscanned repositories are invisible by definition, so the first task is inventory.
Five parts of the operating model
- Inventory. A live list of repositories with owner, language, tier, and whether a scan has run recently. Without it you cannot measure coverage.
- Default-on pipelines. A shared pipeline template that includes the scan, so a new repository gets it without anyone remembering.
- Central policy. One definition of severity thresholds, banned licenses, and exceptions, versioned like code.
- Tiering. Stricter gates for critical services, lighter ones elsewhere.
- Routing. Findings go to the owning team automatically.
Where each stage fits
| Stage | Large org role |
|---|---|
| IDE | Optional, encouraged, not relied on |
| Pull request | The main control, required via shared templates |
| Default branch | Source of truth for the inventory |
| Scheduled | Safety net for new advisories across all repositories |
| Release | Gate for tier 1 only, to limit friction |
The pull request stage still does the heavy lifting, but a template makes it consistent. A repository that wants to deviate files a request, so deviations are visible.
Beware of template pitfalls
If a template supplies the scan job but a platform needs rules in the project file, the job may not run where you think it does. GitLab documents this for merge request pipelines: matching rules must be defined directly in the project file, not only in included files. Test a template in a real repository before announcing it.
Likewise, on GitHub, required checks can be satisfied by a skipped status, so verify the job cannot skip on risky changes.
What to measure
- Coverage: the share of repositories with a scan in the last 7 days.
- Time to fix by severity and tier.
- Number of active exceptions and how many have expired.
- Rate of blocked pull requests that later get waived, which signals a bad rule.
Do not measure raw finding counts as a success metric. It rewards noise.
Governance without a bottleneck
A small central team owns the policy and the templates, and does not triage everyone's findings. Triage belongs to the owning team. The central team reviews exceptions in aggregate and changes the rule when it sees the same waiver repeatedly.
Where Safeguard fits
Safeguard offers asset discovery to build the inventory, policies and gates for central rules, dependency scanning with reachability analysis, and compliance evidence automation. You can try a scan at https://gold.safeguard.sh/scan.
Quick check
How do we find repositories nobody scans?
Start from the source control inventory and compare it with scan results. Any repository with no recent scan is a gap, even if it looks inactive.
Should teams be allowed to opt out?
Only through a recorded, time-limited exception. Silent opt-outs make coverage numbers meaningless.
Sources
Last reviewed: 19 October 2026.
