At 20 to 50 engineers, run scans in three places: IDE feedback for speed, a required pull request check for control, and a scheduled rescan for new advisories. Add shared policy so rules are the same everywhere, and name an owner for each repository's findings.
What changes at this size
Below ten people, a conversation settles most questions. At 20 to 50, you have several teams, perhaps dozens of repositories, and nobody knows every change. Three problems appear:
- Inconsistent setups, where each repository scans differently or not at all.
- Findings with no owner, so they pile up.
- Exceptions granted informally, with no record.
The stage layout matters less than fixing these three.
A layout that works
| Stage | Purpose | Enforced? |
|---|---|---|
| IDE extension | Fast hints for authors | No |
| Pull request check | Block new serious issues | Yes, required |
| Default branch scan | Record of what shipped | No |
| Scheduled rescan | Catch new advisories | Opens tickets |
| Release gate | Last look before production | Yes, for tier 1 services |
Not every repository needs every row. An internal script repository can skip the release gate. A customer-facing service should have all five.
Tier your repositories
Sort services into two or three tiers by what breaks if they are compromised. Tier 1 is customer-facing or handles sensitive data. Tier 3 is internal tooling. Tie strictness to the tier: tier 1 blocks on high and critical, tier 3 comments only.
This keeps developers working on low-risk repositories from fighting rules designed for payment code.
Shared policy, local overrides
Write the rules once, in a central place, and let repositories override within limits. Without a central policy, 40 repositories become 40 different definitions of "critical." With one, an audit or a customer questionnaire has a single answer.
Ownership and exceptions
- Every repository has an owning team recorded in one place.
- Scheduled findings route to that team with a due window.
- Exceptions need a named approver, a reason, and an expiry date.
- A short monthly review looks at expired and soon-to-expire exceptions.
Rollout order
- Install the pull request check in comment mode on all repositories.
- Review the noise for a month and tune.
- Switch tier 1 repositories to blocking.
- Add the scheduled rescan and ownership routing.
- Add release gates for tier 1.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice how findings are grouped and prioritized, which is what owners need once several teams share the same tool.
Where Safeguard fits
Safeguard provides policies, gates, and guardrails you can apply across repositories, dependency scanning with reachability analysis to cut noise, and extensions for VS Code and JetBrains. A free scan is at https://gold.safeguard.sh/scan.
Quick check
Should every repository block on the same severity?
Not necessarily. Tie strictness to risk tier so low-risk repositories are not slowed by rules meant for critical services.
Who should approve exceptions?
A named person with authority over the service risk, such as a tech lead or security champion, with a reason and an expiry recorded.
Last reviewed: 19 October 2026.
