Auto-triage rules filter alerts by metadata such as severity, package name or weakness type, then dismiss, snooze or choose which alerts get pull requests. They shorten the triage stage by removing alerts that are not worth a person's time. Used carelessly, they hide real exposure. Review them like code.
What the rules can do
GitHub's documentation says Dependabot auto-triage rules let you instruct Dependabot to automatically triage alerts, including malware alerts. You can automatically dismiss or snooze certain alerts and specify which alerts you want Dependabot to open pull requests for. Rules apply before alert notifications are sent, so dismissing low risk alerts reduces notification noise.
There are two types: GitHub presets and custom rules. One preset dismisses low impact issues for development scoped npm dependencies, which the documentation describes as unlikely to be exploitable in a non production environment. It is enabled by default for public repositories and optional for private ones. Another preset auto-dismisses alerts that flag all versions of a package as malicious, is off by default, and the docs warn that if a contributor adds a truly malicious dependency across all versions, that rule will auto-dismiss the alert. Custom rules are available for certain repository types and plans, so check yours.
What is reasonable to automate
| Rule idea | Risk | Verdict |
|---|---|---|
| Dismiss low severity in development scoped dependencies | Low | Reasonable, with a review date |
| Open PRs for high severity in production dependencies | Low | Reasonable |
| Snooze alerts with no patch available | Medium | Reasonable, if you track them elsewhere |
| Dismiss all alerts for a named package | High | Avoid without a recorded decision |
| Auto-dismiss malware alerts | High | Avoid, per GitHub's own warning |
How rules change the exposure window
Each rule moves time. A rule that opens PRs for serious alerts immediately removes a human step. A rule that dismisses a class of alerts removes exposure from your dashboard without removing it from the world, and that is where a rule can mislead.
Governance for rules
- Write the reason next to each rule: the risk you accepted and who approved it.
- Give each rule a review date. A dismissal decision from last year may not hold.
- Log what a rule dismissed. Sample a handful each month and confirm they were right.
- Keep reachability in mind. A rule keyed on severity cannot know whether you call the vulnerable code. If you have that data, use it as an extra input.
- Restrict who can edit rules. A rule that silences alerts is a control, so treat changes like a policy change.
Steps to start
- Export a month of alerts and tag each as acted on, dismissed, or ignored by default.
- Look for patterns among the ones dismissed without action.
- Turn the clearest pattern into one rule, then watch it for a month.
- Add rules one at a time. Many small rules with owners beat one broad rule nobody remembers.
Try it yourself
Open the exploitability check demo and compare how a flaw in a package looks when the vulnerable code is or is not reachable. That is the kind of signal a good rule should respect.
Click through it at your own pace, or open it full screen.
Safeguard's reachability analysis and policies give you code level context for which findings matter. A free scan is available at gold.safeguard.sh/scan.
Quick check
Do auto-dismissed alerts disappear?
They leave your notifications and alert list. The vulnerability is still in your software, so sample what rules dismiss.
Should rules be reviewed?
Yes, on a schedule, with a named owner.
Sources
Last reviewed: 19 October 2026.
