Scripts that scan five repositories fail in predictable ways at five hundred. At that size scanning is a service with onboarding, capacity, ownership and reporting. The scanners still work. The surrounding system, which you built in an afternoon, breaks first.
What changes with scale
| Area | At 5 repositories | At 500 repositories |
|---|---|---|
| Onboarding | Copy a workflow file | Automate discovery and enrolment |
| Data feeds | One key, rarely limited | Rate limits and caching matter |
| Ownership | Everyone knows who owns what | Findings need routing rules |
| Noise | A list you can read | A queue you must prioritise |
| Reporting | A spreadsheet | A pipeline and a datastore |
The rate limit problem
Public data sources and registries limit traffic. The Dependency-Check README describes NVD rate limits and says that multiple builds sharing a key can cause 403 errors. Trivy documents fallback to alternative registries on 429 and 5xx errors. At scale you need a shared cache or a mirror, and someone to run it.
Discovery and drift
New repositories appear daily. Without automatic discovery some will never be scanned. Dependabot version updates are enabled by a dependabot.yml file in each repository, so a repository without one is a silent gap.
Prioritisation becomes mandatory
Five hundred repositories produce more findings than any team can read. You need signals beyond severity: whether the vulnerable code is reachable, whether the issue is known exploited, and who owns the service. Each is another data source to maintain.
What to do before you hit the wall
- Automate repository discovery and report coverage as a percentage.
- Run a shared cache or mirror for data.
- Define routing from repository to owning team.
- Pick a prioritisation rule and write it down.
- Decide now what scale triggers a platform review.
Safeguard covers this ground with SBOM and dependency scanning, reachability analysis, policies and gates, and compliance evidence automation. Autonomous fix PRs are off by default, with every category set to Manual. You can try a free scan at gold.safeguard.sh/scan.
A growth trigger worth writing down
Agree in advance what number of repositories, teams or hours triggers a review, for example when upkeep takes a fifth of one engineer's time. Writing the trigger down turns a vague worry into a date on the calendar and keeps the decision from being made in the middle of an audit or an incident.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how coverage and ownership look across many projects at once.
Quick check
What breaks first at scale?
Usually onboarding and data feed limits, followed by ownership and prioritisation.
Can open source scanners handle 500 repositories?
The engines can. You must build the discovery, caching, routing and reporting around them.
Sources
- OWASP Dependency-Check README
- Trivy vulnerability database configuration
- Renovate documentation
- GitHub docs: about Dependabot alerts
Last reviewed: 19 October 2026.
