Dismiss or snooze only with a narrow rule, a written reason and a review date. A suppression with no expiry becomes a permanent blind spot. The safest rules are specific to a package or condition, logged, reversible, and rechecked when the facts around them change.
What the platforms offer
GitHub's documentation describes Dependabot auto-triage rules that can auto-dismiss or snooze certain alerts before notifications are sent. Preset rules include dismissing low impact issues for development scoped npm dependencies, which is on by default for public repositories. Custom rules can match on severity, package name and CWE. Two details matter for safety. Auto-dismissed alerts remain available for reporting and can be reopened, and they reopen automatically if metadata changes, such as a dependency moving from development to production scope.
Where suppression goes wrong
- Scope is too wide, such as dismissing a whole severity band.
- There is no reason recorded, so nobody remembers why six months later.
- The condition that justified it changes, but the suppression stays.
- The suppression outlives the person who made it.
- Nobody counts how many alerts are hidden.
GitHub's own page on auto-triage warns about this tradeoff: the malware dismissal preset is off by default, because it could also dismiss an alert for a truly malicious dependency added by a contributor.
A safe suppression record
Every suppression should carry these fields.
| Field | Example content |
|---|---|
| Scope | One package, one advisory, one repository |
| Reason | Not reachable, test only, fixed upstream, mitigated by config |
| Evidence | Link to analysis or ticket |
| Owner | Named person |
| Expiry | A date, commonly thirty to ninety days |
| Reopen trigger | Added to KEV, scope change, new exploit |
Review on a schedule
Once a month, list suppressions that expire within thirty days and decide: renew with fresh evidence, or lift. Also list suppressions with no expiry and fix them. Track the count of active suppressions as a metric. A rising count with a flat alert count means noise is being hidden rather than reduced.
Let reopen triggers do the watching
Do not rely on memory. Reopen automatically when a vulnerability enters the CISA KEV catalog, when a dependency changes scope, or when the advisory is revised. If your tool cannot do this, a small scheduled script that compares your suppression list with KEV can.
Where Safeguard fits
Safeguard's policies and reachability analysis give you a reason to attach to a decision, namely that the vulnerable path is not called, and policies are versioned so changes are visible. A free scan shows findings you can reason about.
Quick check
Is it fine to dismiss all low severity alerts?
Rarely. Severity alone ignores exploitation and exposure. Prefer rules tied to a specific condition.
How long should a snooze last?
Long enough to avoid churn, short enough to recheck, often thirty to ninety days. Pick one and enforce it.
Sources
Last reviewed: 19 October 2026.
