A good dismissal comment states the reason, the evidence behind it, who decided, and when to re-check. "False positive" alone is not enough. GitHub stores a dismissal reason and an optional comment on each Dependabot alert, and its docs say the comment can serve as justification during auditing and reporting.
What the platform keeps
GitHub's documentation on Dependabot alerts describes the dismiss flow. You pick a reason from a dropdown, and you can add a dismissal comment. The comment is added to the alert timeline, and the docs say it can be used as justification during auditing and reporting. You can read or set it through the GraphQL API in a field called dismissComment.
Two other details from the same docs matter. Unfixed dismissed alerts can be reopened later, but closed alerts that were already fixed cannot be reopened. And when someone in an organization dismisses an alert, the audit log event shows the dismissal reason and comment.
So the comment is not a private note. It is part of an audit trail.
The five parts of a useful comment
| Part | What to write | Example wording |
|---|---|---|
| Reason | One plain sentence | The flagged function is not called by our code |
| Evidence | Where you checked | Call path search on the main branch, reviewed in the pull request |
| Scope | What the claim covers | Applies to the billing service only |
| Owner | Who decided | Named person or team |
| Re-check | A date or trigger | Review on upgrade of the parent library or by the next quarter |
Keep the sentence short and the evidence findable. A link to a pull request, ticket or analysis output beats a paragraph of prose.
Wording to avoid
- Vague reasons such as "not an issue" or "known".
- Claims you cannot show, such as "no attacker can reach this" with nothing behind it.
- Open ended dismissals with no re-check, which turn into permanent blind spots.
- Reasons that describe your workload instead of the risk, such as "no time". If the real reason is that the fix is scheduled, say that and give the date.
Make it repeatable
Agree on a short list of reasons for your team, and a comment template that holds the five parts. Review dismissed items on a schedule, and sample a few each quarter to check the evidence still stands. If an auditor asks how you handle accepted risk, you can show the template, a sample, and the review record.
For a deeper look at how to cut noise in the first place, see reachability analysis for triage.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at what evidence the check produces, then think about which of it you would link in a comment.
Quick check
Can a dismissal comment be edited later?
Check your platform. The safer habit is to add a new dated note rather than rewrite the old one, so the history stays intact.
Is a comment enough evidence on its own?
It is the pointer. The evidence is the thing it points to, such as an analysis result or a reviewed pull request.
Safeguard offers dependency scanning with SBOM output and reachability analysis, and the free scan lets you try it on your own project.
Sources
Last reviewed: 19 October 2026.
