Your triage process has outgrown the team when alerts age without owners, the same issue is handled twice, one person is the bottleneck, or nobody can say how many exceptions exist. Any two of these together mean it is time to move to the next stage for your size.
The signs, with a check for each
| Sign | How to check | Likely fix |
|---|---|---|
| Alerts with no owner | Filter for unassigned alerts older than a week | Ownership map and auto-assignment |
| Duplicate work | Search for one advisory across repositories | Group into one work item |
| One person reads everything | Ask who triaged the last ten alerts | Rotate or route by team |
| Nobody knows the exception count | Try to list accepted risks | Exception register with expiry |
| Notifications muted | Ask engineers if they filter alert emails | Digest, rules, tiering |
| New repositories add alerts for months | Look at backlog after each onboarding | Baseline and ratchet |
| Leadership asks and you rebuild numbers by hand | Time the last report | Automated weekly summary |
Sign one: alerts with no owner
GitHub documents that users with write access can assign Dependabot alerts to collaborators or teams, and that you can filter alerts by assignee. If a large share of alerts have no assignee, nobody is accountable for them. This is the earliest and most reliable warning.
Sign five: muted notifications
When engineers filter alert emails to a folder, the system has failed quietly. The usual cause is volume. GitHub notes that auto-triage rules run before notifications go out, and that a weekly digest or turned-off notifications are options when alerts remain enabled. Use those, and tier what is left. See tier alerts: page, ticket, or digest.
Sign four: unknown exceptions
If you cannot list every accepted risk with an owner and an expiry, some of them are permanent. This grows with team size, so it is a good signal that your process is from an earlier stage. See exceptions by team size.
What the next stage looks like
- Under 10 people: one queue, one weekly owner.
- 10 to 50: ownership map, per-team queues, one weekly review.
- 50 to 200: automatic routing, gates on new findings, escalation.
- 200 plus: policy as code, exception governance, business unit reporting.
These bands are a rule of thumb. A small team with a large, old codebase may need the mid stage earlier.
A ten minute self-audit
- Count unassigned alerts older than seven days.
- List the three oldest open items and their owners.
- Ask three engineers when they last looked at an alert and why.
- Check whether any known exploited item has been open longer than your window. CISA strongly recommends all organizations prioritize those entries.
- Write down one change to try this month.
Do not try to fix everything at once. Moving one stage at a time is easier to sustain.
Try it yourself
Click through it at your own pace, or open it full screen. Check where unowned or aging findings would show up.
Safeguard's asset discovery and policies can help with ownership and aging, and the free scan at gold.safeguard.sh/scan gives a snapshot to start from.
Quick check
Is a growing alert count a sign of a broken process?
Not by itself. It can reflect new repositories or advisories. Aging, ownership, and exceptions are better signals.
How often should we run the self-audit?
Quarterly is a reasonable rhythm, and after any big change in team size.
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.
