Automate in this order as you grow: notification control first, then ownership routing, then grouping, then gating, then escalation and reporting. Smaller teams stop after the first two or three. Larger teams add the rest. Keep exception decisions with a person at every size.
The short table
| Team size | Automate first | Add next | Keep human |
|---|---|---|---|
| 1 to 3 people | Notification digest, auto-dismiss of clear low-impact categories | Scheduled dependency updates | Every real fix and every skip reason |
| 4 to 10 | Single queue, owner assignment | Grouped update PRs | Exceptions, risk acceptance |
| 11 to 50 | Repository to team routing | Duplicate grouping across repositories | Policy changes |
| 51 to 200 | Pipeline gates on new findings | Aging and escalation reminders | Exploitability disputes |
| 200 plus | Policy as code, exception expiry | Cross unit reporting | Review board decisions |
The bands are a planning guide drawn from how work usually breaks, not a measured standard. Use them to start a conversation.
Why this order
Notification control is the cheapest win. GitHub's documentation describes weekly email digests, the option to switch notifications off while keeping alerts, and auto-triage rules that apply before notifications are sent. You reduce interruptions without losing data.
Ownership routing is next because an alert without an owner does not get fixed. GitHub notes that users with write access can assign alerts to collaborators or teams and filter by assignee.
Grouping matters once the same advisory appears in many repositories. One work item beats forty tickets. See one fix, many alerts.
Gating keeps new debt from entering. Use it only after the backlog has a plan, otherwise it blocks everything.
Escalation and reporting make the system run without meetings.
What not to automate early
- Auto-merge of dependency updates. Safe for patch bumps on well-tested services, risky elsewhere. Start with grouped pull requests that humans merge.
- Permanent dismissals. Always attach an expiry.
- Policy decisions. Windows and thresholds should be argued once and written down.
Be careful with presets as well. GitHub's documentation says a rule that auto-dismisses malware alerts for packages flagged in all versions would also dismiss a truly malicious dependency a contributor adds, and that this preset is off by default. Read the failure case before you enable anything.
Use outside signals as inputs
The Known Exploited Vulnerabilities catalog and EPSS are two free inputs for automated ordering. CISA recommends all organizations prioritize the catalog's entries. FIRST describes EPSS as the estimated probability of exploitation within 30 days, updated daily, and says it is not a complete risk score. Combine them with whether the vulnerable code is used in your product.
Try it yourself
Click through it at your own pace, or open it full screen. Compare how the same finding looks before and after an exploitability check.
Safeguard offers reachability analysis, policies, and gates for several rows of this table, and fix PRs are off by default. The free scan at gold.safeguard.sh/scan shows a first pass.
Quick check
Should a three-person team automate fix pull requests?
Maybe grouped update pull requests, merged by a person. Full automation is rarely worth the risk at that size.
What is the first thing to turn off?
Notifications nobody reads. Keep the alerts enabled, change the delivery.
Sources
- GitHub Docs, About Dependabot alerts
- GitHub Docs, Dependabot auto-triage rules
- FIRST, EPSS frequently asked questions
- CISA, Reducing the Significant Risk of Known Exploited Vulnerabilities
Last reviewed: 19 October 2026.
