Open the Dependabot tab of the repository, click the alert, and read four things in order: the package and version, the severity, the patched version if one exists, and the manifest it came from. Then decide whether to update, ask the code owner, or leave it for triage. Dismissing is a team decision.
Where alerts live
GitHub's documentation says that if it discovers insecure dependencies in your project, you can view alert details on the Dependabot tab of the repository, then update the project to resolve the alert or dismiss it. The tab lists open and closed alerts and corresponding Dependabot security updates. You can filter by package, ecosystem or manifest, sort the list, and click an alert for more detail. Each alert has a unique numeric identifier and the tab lists an alert for every detected vulnerability.
Access is limited. The docs name repository administrators, organization owners, and people with write or maintain access, plus users and teams granted explicit access to security alerts. If you cannot see the tab in your first week, ask for access rather than working around it.
The four fields to read
| Field | Why it matters |
|---|---|
| Package and your version | Confirms you are really on the affected range |
| Severity | A starting point for urgency, not the final word |
| Patched version | Tells you whether a fix exists at all |
| Manifest path | In a monorepo, shows which service owns it |
Deciding what to do
- A patched version exists and the update is small. Open a pull request, or merge the bot's pull request after tests pass.
- The fix is a major version. Check the changelog and talk to the owner before you start.
- No fix exists. Record it and ask about a mitigation or a time-boxed exception.
- You think it is not exploitable here. Write down why, with the code path you checked, and let the owner decide on dismissal.
Severity alone does not tell you exploitability in your service. Severity, reachability and exposure together do. That is why teams combine alerts with a view of what code actually calls the affected function.
Habits to build early
- Check the alert count weekly, not only when it shouts.
- Close the loop: every alert ends in a merged fix or a written decision.
- Never dismiss an alert to make a dashboard look clean.
For deeper background, see Dependabot security updates and automated pull requests.
Where Safeguard fits
Safeguard can do the inventory and watching for you. Its SBOM and dependency scanning lists what a repository actually pulls in, reachability analysis helps separate reachable findings from noise, and policies can gate a pull request. You can try a free scan on a repository to see the output.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how findings are grouped and prioritized rather than shown as a flat list.
Quick check
Who is allowed to dismiss an alert?
GitHub lets people with the right access dismiss alerts, but your team should decide who does it and require a written reason.
Is a low severity alert safe to ignore?
Not automatically. Low severity can still matter in a sensitive service. Record a decision either way.
Sources
Last reviewed: 19 October 2026.
