Move to an org-wide vulnerability view when you cannot answer simple questions across repositories: how many services use this package, who owns the oldest open issue, which teams are past their window. For many organizations that happens somewhere between ten and fifty repositories, but the questions matter more than the count.
What per-repository alerts do well
Alerts attached to a repository are excellent for the team that owns it. GitHub describes Dependabot alerts as appearing on the repository's Security and quality tab and dependency graph, with the affected file, details, severity, and fixed version where available. For a single product with a few repositories, that is often enough.
The same documentation notes a relevant limit: alert assignment visibility is currently scoped to the repository-level alerts view, and the organization-wide security overview does not display alert assignments. Check current documentation for your platform, since features change.
Triggers that say it is time
| Trigger | Why per-repo view fails |
|---|---|
| A new advisory lands and you cannot list affected services | No cross-repository search |
| Leadership asks for aging by team | Data lives in many places |
| Auditors ask for evidence across systems | Records are scattered |
| The same fix repeats in many repositories | No grouping |
| Repositories without owners appear | No inventory |
What the org-wide view must show
- Inventory. Every repository and deployable service, with an owner.
- Component search. Which services contain a given package and version.
- Aging by owner. Open items, oldest item, share past window.
- Known exploited matches. CISA recommends all organizations monitor and prioritize its Known Exploited Vulnerabilities catalog, so a match flag belongs on the home page.
- Exceptions. Active and expiring.
Roll it out in four steps
- Inventory first. You cannot view what you have not listed. Pull repositories from your source host and tag owners.
- Connect one data source. Start with dependency data. Add code scanning and container images later.
- Pilot with two teams. Pick one that is organized and one that is not. You learn from both.
- Retire the old process. If you run both, people split attention. Name a date to stop the old reports.
See also build a quarterly upgrade backlog from your SBOM.
Pitfalls
- A dashboard nobody opens. Tie it to a weekly review.
- Duplicated alerts. Keep one source of truth for status.
- Perfect data first. Start with partial ownership and fix gaps as they surface.
- Treating severity as the sort order. FIRST's CVSS guidance says Base scores measure severity and should not be used alone to assess risk. Add exploitation and reachability.
Try it yourself
Click through it at your own pace, or open it full screen. Try searching for one package and see which components contain it.
Safeguard's asset discovery and SBOM and dependency scanning provide this kind of inventory, and the free scan at gold.safeguard.sh/scan is an easy way to try one repository.
Quick check
Do we need an org-wide view at five repositories?
Usually not. Native repository alerts and a shared board are enough until cross-repository questions start going unanswered.
What should we inventory first?
Repositories that deploy to production, with an owner for each.
Sources
- GitHub Docs, About Dependabot alerts
- CISA, Reducing the Significant Risk of Known Exploited Vulnerabilities
- FIRST, CVSS v4.0 User Guide
Last reviewed: 19 October 2026.
