Pick the reason that matches your real situation: fix_started if work is under way, inaccurate if the alert is wrong, no_bandwidth if you cannot do it now, not_used if the code is not used, or tolerable_risk if you accept the risk. Then add a comment that explains why.
The five reasons
GitHub's REST API documentation lists the allowed values for a dismissed alert. The web interface asks for a reason from the Dismiss menu. The documentation for viewing alerts adds that dismissing alerts you have already assessed makes it easier to triage new ones, and that the optional comment goes on the alert timeline and can serve as justification during auditing and reporting.
| API value | Use it when | Evidence worth writing |
|---|---|---|
| fix_started | An upgrade or patch is in progress | Ticket or pull request link and target date |
| inaccurate | The alert does not describe your situation | Why, for example wrong package or version |
| no_bandwidth | You cannot fix it now but plan to | Owner, planned date and interim control |
| not_used | The vulnerable code or package is not used | How you checked, such as a search or reachability result |
| tolerable_risk | You have decided to accept it | Who approved, the reasoning and a review date |
Be honest about the difference
The labels are not interchangeable. no_bandwidth and tolerable_risk read similarly in a list, but one says "we intend to fix this" and the other says "we decided not to". An auditor will treat them differently, and so should you.
not_used deserves care. It is a claim about your code, so write down how you know. "Not imported anywhere" is checkable. "Probably not used" is not. If you are unsure, use a reachability result or a code search and note the date.
inaccurate is for cases where the data is wrong for you, for instance the advisory names a package but your dependency is a differently named fork. Do not use it to mean "I disagree with the severity". That is a risk decision.
Writing a good comment
Keep it short and specific. A useful comment has four parts: what you checked, what you decided, who decided, and when to look again. For example: "Not used. Package only appears in a build script that is not shipped. Checked 19 Oct by the platform team. Re-review at next major upgrade."
Avoid comments like "ignore" or "false positive". They give a reviewer nothing to verify.
Unfixed dismissals can come back
The documentation says unfixed dismissed alerts can be reopened later, and that alerts already fixed cannot. Use that. Set a calendar review for tolerable_risk and no_bandwidth items, and reopen them if exposure changes.
Dismiss in bulk with care
You can select several alerts and dismiss them with one reason. That is fine for a group with the same cause, such as a test-only dependency. It is a poor idea for a mixed list, because one reason and comment will be wrong for some of them.
Where Safeguard fits
Safeguard's policies and gates give you a controlled place to handle accepted findings, and reachability analysis supplies evidence for a not-used claim. You can try a free scan at gold.safeguard.sh/scan. For a deeper look at the idea, read our post on ignoring an advisory without hiding real risk.
Try it yourself
Click through it at your own pace, or open it full screen.
Open a finding and look at how its status and the reason for it are tracked.
Quick check
Is a dismissal comment required?
The GitHub documentation calls it optional, but it is the part that gives an auditor something to check, so write one.
Can I undo a dismissal?
You can reopen unfixed dismissed alerts. Alerts that have already been fixed cannot be reopened, according to the GitHub documentation.
Sources
- GitHub Docs: viewing and updating Dependabot alerts
- GitHub Docs: REST API endpoints for Dependabot alerts
Last reviewed: 19 October 2026.
