According to GitHub's documentation, new Dependabot alerts notify people with write, maintain or admin permissions in the affected repository. Security leads, service owners without those roles, and on-call engineers may never see them. Decide who should receive alerts, then make them visible to those people.
What the default means
GitHub's page on configuring Dependabot alerts says that when a new alert is raised, people with write, maintain or admin permissions in the affected repositories are notified. It also says you can make alerts visible to additional people or teams working on repositories you own or administer. It does not spell out the steps on that page, so follow the current settings screens for your organization.
That default is sensible for a small team where everyone with write access owns the code. It breaks down in three common cases.
| Case | What goes wrong |
|---|---|
| Large organization with many repos | Alerts spread across hundreds of inboxes, nobody sees the whole picture |
| Security team without write access | Security never sees alerts unless someone forwards them |
| Shared library owned by one team, used by many | Consumers are not told when the library has an alert |
Questions to answer before changing anything
- Who should fix a dependency alert? Usually the team that owns the service.
- Who should know about it? A tech lead, and sometimes security.
- Who should be told when nothing happens? Someone must see alerts that age past your service level.
- What happens when the owner is absent? See who watches security alerts when the solo maintainer is away.
Steps
- Export a list of repositories with the people who have write, maintain or admin roles. Compare it to your ownership list.
- Mark repositories where the real owner lacks one of those roles, and repositories with no active people at all.
- Make alerts visible to the security group and to each service owning team, using the sharing option GitHub provides in your settings.
- Add a second channel for high severity items, such as a chat message from an automation, so that the alert does not rely on email alone. See where should dependency alerts go.
- Run a monthly report of open alerts older than your target, grouped by owner.
- Test the route: pick a low risk repository, create a test alert path, and confirm the right people were informed.
Trade offs
More recipients means more noise, and each added person lowers the chance that any one person acts. Prefer routing to a named owner plus a single escalation group, not everyone. A person who is told about everything acts on nothing. The goal is that each alert has one clear owner and one clear backup.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how findings are assigned to owners and how ageing is tracked.
Quick check
Do all repository members see Dependabot alerts?
By the documented default, people with write, maintain or admin permissions are notified. Read-only members are not in that group.
Can alerts be shown to a security team that lacks write access?
GitHub says you can make alerts visible to additional people or teams for repositories you own or administer.
Safeguard's dependency scanning, SBOMs and policies can assign findings to owners across repositories. Try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
