At about 200 engineers, central triage cannot keep up. Route each alert automatically to the owning team, give teams safe defaults so most fixes are routine, and have the security group manage exceptions, escalation, and policy. Success is measured by time to close per team, not by how many alerts security read.
Why central triage stops working
When a security group reads every alert, queue time grows with the number of repositories, not with risk. Two hundred engineers can easily mean hundreds of repositories. A handful of security staff cannot hold the context for all of them, and the engineers who do know the code are waiting on a reply.
The reverse model works better: the owning team triages its own alerts, and security sets the rules and watches the totals.
The four pieces
- Automatic ownership. Every repository maps to a team in a file or catalog that is kept current. GitHub's documentation shows alerts can be assigned to teams and that assignment events fire a webhook, so assignment can be automated from your ownership data.
- Paved defaults. A starter template for new services with dependency update configuration, branch protection, and policy checks already on. Teams inherit good behavior rather than choosing it.
- Tiered clocks. Faster for internet facing and customer data services. Slower for internal tools. Overrides for known exploited vulnerabilities.
- Escalation. An alert past its clock goes to the team lead, then to the director, on a schedule you publish.
What security does instead
| Central security does | Teams do |
|---|---|
| Sets policy windows and exceptions process | Triage and fix their own alerts |
| Runs the weekly numbers | Close alerts inside the clock |
| Handles unclear exploitability disputes | Provide code context |
| Tunes rules and presets | Report false positives |
| Watches new public signals | Act when routed |
The public signals matter here. CISA's Known Exploited Vulnerabilities catalog is a list that central security can monitor once and push to every team, so the matching logic lives in one place. CISA states that it strongly recommends all organizations prioritize remediation of vulnerabilities in the catalog, including those not bound by its federal directive.
Guardrails against gaming
When teams own their own queues, three habits show up: mass dismissal, stalled assignments, and moving the problem to another repository. Counter them with an audit trail. GitHub's auto-triage documentation notes that automatic dismissal activity appears in webhooks, APIs, and the audit log, and that dismissed alerts can be filtered and reopened. Review dismissals by team once a month, not alert by alert.
Make onboarding cheap
New repositories are where backlog starts. Use a baseline approach: mark existing findings as accepted debt with a date, and block only new ones. See baseline and ratchet for a new repository.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how ownership and status travel with each finding.
Safeguard's asset discovery, policies, and gates support this split, and the free scan at gold.safeguard.sh/scan shows how a single repository reads today.
Quick check
Who handles alerts for repositories with no owner?
Security should assign a temporary owner, then require a team to claim or archive it. Orphans are where old alerts hide.
How often should clocks be reviewed?
Review them once or twice a year, or when closure rates show they are unrealistic.
Sources
- GitHub Docs, About Dependabot alerts
- GitHub Docs, Dependabot auto-triage rules
- CISA, Reducing the Significant Risk of Known Exploited Vulnerabilities
Last reviewed: 19 October 2026.
