Auto-triage rules are a powerful tool to help you reduce false positives and alert fatigue substantially, while better managing your alerts at scale.
Starting today, you can now create your own custom rules to control how Dependabot auto-dismisses and reopens alerts – so you can focus on the alerts that matter, without worrying about the alerts that don’t.
What’s changing?
For any existing or future alerts that match a custom rule, Dependabot will perform the selected behavior accordingly. You can proactively filter out false positives, snooze alerts until patch release, and – as rules apply to both future and current alerts – manage existing alerts in bulk.
Frequently asked questions
Why is GitHub making this change?
At GitHub, we’ve been thinking deeply about how to responsibly address long-running issues around alert fatigue and false positives. Rather than over-indexing on one criterion like reachability or dependency scope, we believe that a responsibly-designed solution should be able to detect and reason on a rich set of complex, contextual alert metadata.
That’s why, moving forward, we’re releasing a series of ships powered by an underlying, all-new, flexible and powerful alert rules engine. Our first ship – Dependabot presets – leveraged our rules engine with GitHub-curated vulnerability patterns. Today’s ship exposes our rules engine so you can create your own rules, too.
Which criteria are supported?
Rules can be created across the following attributes:
Attribute
Description
severity
Alert severity, based on CVSS base score, across the following values: low, medium, high, and critical.
scope
Scope of the dependency: development (devDependency) or runtime (production).
package-name
Packages, listed by package name.
cwe
CWEs, listed by CWE ID.
ecosystem
Ecosystems, listed by ecosystem name.
manifest
Manifest files, listed by manifest path.
What behaviors are supported?
Today’s ship covers support for auto-dismissing alerts indefinitely as well as snoozing alerts until patch. Auto-dismissing ensures all activity is easily visible and can be caught by existing reporting systems and workflows, while also ensuring that alerts can be reintroduced if metadata across the alert changes.
How will this activity be reported?
Auto-dismissal activity is shown in webhooks, REST, GraphQL, and the audit log for Dependabot alerts. Alerts are dismissed without a notification or new pull request and appear as a special timeline event. As these alerts are closed, you’ll still be able to review any auto-dismissed alerts with the resolution:auto-dismissed filter.
Who can create and modify rules?
Auto-triage rules are free for open source repositories. Anyone who can enable Dependabot alerts for a public repository will be able to create custom rules for it. Customers of GitHub Advanced Security can create and manage custom rules across private repositories.
How do I reopen an automatically dismissed alert?
Like any manually dismissed alert, you can reopen an auto-dismissed alert from the alert list view or details page. This specific alert won’t be auto-dismissed again (by any other auto-dismiss rule).
What happens if alert metadata changes or advisory information is withdrawn?
Dependabot recognizes and immediately responds to any changes to metadata which void auto-dismissal logic. For example, if you change the dependency scope and the alert no longer meets the criteria to be auto-dismissed, the alert will automatically reopen.
In October 2022, we released a private beta adding linked SAML single sign-on (SSO) identities for relevant users to GitHub Enterprise audit log events.
We are expanding the private beta to now include linked identities within git events, making this information available across all relevant events.
We have implemented a fix so that GITHUB_REF and the github.ref context value return a fully-formed ref (e.g – refs/heads/main) when a workflow is triggered as a result of a pull request being merged. This change only impacts a small subset of workflows that trigger as a result of a pull request closing after being merged and that make use of GITHUB_REF or github.ref.
Previously, GITHUB_REF and github.ref were incorrectly returning a shortened ref (e.g. – main). These should always return a fully-formed ref regardless of the scenario.
Please visit our documentation for more details about using Actions context and variables.
