Scan every repository, but do not gate every repository. Scanning for visibility should be the default everywhere. Blocking merges should apply only to code that ships to production or handles sensitive data. Splitting those two decisions removes most of the argument between security and engineering.
Two decisions hiding in one question
"Mandatory" mixes coverage with enforcement. Coverage means the scanner runs and results are recorded. Enforcement means a failing result stops a merge or deploy. Teams usually resist enforcement, not coverage.
If a scan is quiet, cheap and does not block anyone, there is little reason to opt out. You get an inventory, and you find the forgotten repo with the old dependency before an attacker does.
A simple tier model
| Tier | Examples | Scan | Enforce |
|---|---|---|---|
| 1 | Customer facing services, payment or auth code, shared libraries | Every pull request and nightly | Block on high priority findings |
| 2 | Internal tools, batch jobs | Every pull request | Warn, review weekly |
| 3 | Prototypes, forks, samples | Weekly | Report only |
| Archived | Read only repos | Monthly or on request | None |
Assign tiers by what the code does, not by which team wrote it. Let repo owners propose a tier and let a short review confirm it.
Handle the awkward cases
Forks and vendored code produce findings the team cannot fix directly. Record them, point to the upstream, and keep them out of enforcement.
Archived repositories should be archived on purpose. If a repo is dead, say so, and stop alerting on it. If it is not dead, it belongs in tier 2 or above.
New repositories should start in tier 2 by default. A repo that nobody classified is the one most likely to be skipped.
What to ask before making it mandatory
- Does the scan finish fast enough that nobody waits on it?
- Can an owner dispute a result without a ticket to security?
- Is there a path to move a repo up or down a tier?
- Who sees coverage numbers, and are they honest about gaps?
If you cannot answer yes to the first two, fix them before expanding coverage. Mandatory plus slow plus no appeal is how a program loses developer goodwill.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a single inventory view covers many components at once.
Safeguard covers SBOM and dependency scanning plus asset discovery, so repos without a scan show up as gaps. Try the free scan on one repo first.
Quick check
Will scanning every repo overload the team with alerts?
Not if only tier 1 produces blocking results and the rest report quietly. Volume is a routing and threshold problem.
How do you count coverage honestly?
Count repos with a recent successful scan over all repos in your source control system, and list the exceptions by name.
Last reviewed: 19 October 2026.
