At around 20 engineers, shift from one shared triage owner to a service ownership map. Each alert routes to the team that owns the code, one lightweight weekly review checks the totals, and a small number of shared rules cover exceptions. The central role becomes coordination, not reading every alert.
What breaks at 20
A single rotating owner works while everyone knows the whole codebase. At twenty people there are usually several services, a couple of squads, and code that few people can explain. The weekly owner either becomes a bottleneck or starts guessing who owns what.
Typical symptoms are alerts sitting in the shared channel for days, the same finding raised by three people, and arguments over whose problem it is.
Build a service ownership map
Start with a plain table. It does not need a platform.
| Repository or service | Owning team | Backup contact | Tier |
|---|---|---|---|
| Payments API | Squad A | Squad B lead | Customer facing |
| Internal admin | Squad B | Squad A lead | Internal |
| Batch jobs | Platform | Squad A lead | Internal |
Then route alerts by that table. GitHub documents that alerts can be assigned to people or teams and filtered by assignee, and that the alerts view is scoped to the repository. That means the repository to team mapping you keep is what makes assignment cheap.
Three rules that scale
- Tier decides the clock. Customer facing services get tighter fix windows than internal tools. State the windows in one paragraph and keep them.
- Known exploited beats everything. CISA recommends all organizations prioritize remediation of vulnerabilities in the Known Exploited Vulnerabilities catalog. Make that an override that skips the tier clock.
- No orphan repositories. Any repository without a team in the map gets one or gets archived. GitHub notes it does not scan archived repositories, so archiving is a real choice with a real consequence for alerting.
One weekly review
Run a thirty minute review with one lead per squad. Look at three numbers: new this week, closed this week, and open past the clock. Do not walk through individual alerts unless one is stuck. For a longer agenda see the weekly findings triage meeting.
Reduce volume before routing
Every alert you can remove before it reaches a squad is a saved context switch. Rules that run before notification delivery, such as auto-dismissing low-impact alerts in development-scoped dependencies, cut noise at the source. GitHub notes the development dependency preset auto-dismisses certain npm issues that are unlikely to be exploitable outside a developer environment, and that dismissed alerts can be reopened if metadata changes.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how new findings appear against an existing inventory rather than as a fresh pile.
Safeguard's asset discovery and policies can help build the repository inventory and gate on rules, and the free scan at gold.safeguard.sh/scan is a quick way to see one service's current picture.
Quick check
Do we need a dedicated security person at 20 engineers?
Not always. Many teams add a part-time coordinator first. The deciding factor is whether alerts are being closed on time, not headcount.
What if two teams share a library?
Assign the alert to the team that owns the library repository, and let consuming teams take the upgrade once it is released.
Sources
- CISA, Reducing the Significant Risk of Known Exploited Vulnerabilities
- GitHub Docs, About Dependabot alerts
- GitHub Docs, Dependabot auto-triage rules
Last reviewed: 19 October 2026.
