Require approval for dismissals that carry real risk, such as high severity findings in production code, and keep a light, comment-only path for clear false positives and test-only code. A single rule for everything either floods reviewers or lets risky dismissals slip through.
What a dismissal is
A dismissal closes an alert without fixing it. It is an exception in miniature: someone decided the alert does not need action. Without a reason, an owner and an end date, it is also the quietest way to lose track of risk.
Some platforms give a built-in approval path. GitHub documents delegated alert dismissal for Dependabot, where once enabled, organization owners and security managers can dismiss alerts, so other users request dismissal instead. The same page warns that the approval process can create friction, so security managers need enough coverage to review requests. Dismissed alerts that have not been fixed can be reopened, and a dismissal comment is added to the alert timeline, which can be used as justification in auditing.
Two models compared
| Aspect | Free dismissal with comment | Approval required |
|---|---|---|
| Speed | Fast | Slower |
| Control | Relies on discipline | Enforced |
| Audit | Good if comments are real | Strong, two people involved |
| Risk | Quiet bad dismissals | Reviewer bottleneck |
| Fits | Low risk classes | High risk classes |
A tiered rule
Define tiers by what is at stake.
| Tier | Example | Rule |
|---|---|---|
| Light | Test-only dependency, clear false positive | Dismiss with required reason and comment |
| Standard | Medium severity, non-exposed service | Dismiss with comment, reviewed in a weekly sample |
| Controlled | High or critical, production, internet facing | Approval before dismissal, with evidence and expiry |
What every dismissal needs
- A reason from a fixed list, not free text only
- A comment that says why, with a link to evidence where relevant
- The person who dismissed it
- For anything beyond light, a review date
See how to write a dismissal comment an auditor will accept.
Sampling as a cheap control
Even where approval is not required, review a random sample each week. Look for empty comments, repeated reasons from one person, and dismissals on exploited vulnerabilities. Sampling is cheaper than approving everything and catches the worst habits.
Detecting bad patterns
- One user dismissing many high severity alerts quickly
- Dismissals with identical comments
- Alerts reopened and redismissed repeatedly
- Dismissals on a vulnerability that later appears on a known exploited list
Dismissal versus exception
A dismissal inside a scanner is local to that tool. If you rely on several tools, or auditors want one list, mirror controlled dismissals into the central exception register. See where should vulnerability exceptions live.
Safeguard's policies and gates set what blocks a build, so you can decide in policy which classes need review, and its reachability analysis gives evidence for a dismissal reason.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how alerts are triaged, then think about which ones you would let a developer close alone.
Quick check
Can dismissed alerts come back?
On GitHub, unfixed dismissed alerts can be reopened. Alerts already fixed cannot.
Is a comment enough for audit?
Only if it states a real reason. GitHub notes the comment can serve as justification, so make it count.
Sources
- GitHub Docs: Enabling delegated alert dismissal for Dependabot
- GitHub Docs: Viewing and updating Dependabot alerts
Last reviewed: 19 October 2026.
