Secret scanning automatically detects leaked secrets across all public packages on the npm registry. If secret scanning detects a potential secret, we notify the service provider who issued the secret. The service provider validates the string and then decides whether they should revoke the secret, issue a new secret, or contact the committer directly. Package maintainers will not receive secret scanning alerts for these detections.
Dependabot user-defined rules for security updates and alerts; enforcement of auto-triage rules and presets for organizations (public beta)
Auto-triage rules are a powerful tool to help you reduce alert and pull request fatigue substantially, while better managing your alerts at scale.
What's changing?
Starting today, you can define your own rules to control and enforce Dependabot behaviors across organizations and individual repositories.
- You can now define which alerts receive pull requests to resolve them, rather than targeting all alerts.
- You can enable and enforce those Dependabot security update rules across organizations, in addition to individual repositories.
- You can enable, disable, or enforce how GitHub default rulesets are applied across your organization.
- You can also now enable and enforce custom auto-dismiss (alert ignore and snooze) rules across organizations.
Auto-triage rules are defined by alert targeting criteria, the behaviors you'd like Dependabot to automatically perform for these alerts, as well as how you want the rule to be enabled or enforced across your organization.
Alerts can be targeted based on metadata related to the advisory, dependency, and how it's used. For this public beta, currently supported attributes at the organization level are: severity, scope, package-name, cwe, and ecosystem. At the repository level, you can also target specific manifest files.
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, choose which alerts open Dependabot security updates, and – as rules apply to both future and current alerts – manage existing alerts in bulk.
This feature is free for open source (all public repositories) and available for use in private repositories through GitHub Advanced Security.
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 a flexible and powerful alert rules engine. Our first ship – Dependabot presets – leveraged our rules engine with GitHub-curated vulnerability patterns and has helped millions of repositories filter out false positive alerts. Today’s ship exposes our rules engine at the organization and repository levels, so you can create and enforce custom rules, too.
How do I create a rule?
From your organization or repository settings page, admins and security managers can navigate to Code security and analysis settings. Under Dependabot, select Dependabot rules to add or modify your own custom rules or modify GitHub presets.
How do I enforce rules for my organization?
At the organization level, rules can be set with the following states.
| State | Description |
|---|---|
Enabled |
This rule will be enabled across all eligible repositories in your organization. It will be on by default (new repositories are included). Any individual repository can choose to disable the rule. |
Enforced |
This rule will be enabled across all eligible repositories in your organization. It will be on by default (new repositories are included). Individual repositories cannot override this setting. |
Disabled |
This rule will be disabled and hidden across your organization. |
At the repository level, rules can be set to enabled or disabled if they're not enforced.
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. |
Note: manifest is only available at the repository level.
How do I control how Dependabot automatically generates pull requests for alerts?
You can use the alert criteria (above) to indicate which alerts Dependabot will attempt to open pull requests to resolve. To use auto-triage rules with Dependabot updates, you must disable Dependabot's option to always open pull requests to resolve all open alerts from the repository Code security and analysis settings.
How do I control how Dependabot automatically closes or reopens alerts?
Similar to Dependabot pull request rules, you can control how Dependabot filters out false postives (with dismiss indefinitely) or snoozes alerts (with dismiss until patch).
How many custom rules can I create?
At the time of public beta, you can create 20 rules per organization and 10 rules for each repository. Want more? Let us know!
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 and at the organization level.
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.
How do I learn more?
- About the auto-triage feature
- Dependabot alerts REST API
- Dependabot alerts GraphQL API
- Dependabot alerts webhook
How do I provide feedback?
Let us know what you think by providing feedback — we’re listening!
There are two new metrics available under the Repository object in the GraphQL API:
- LastContributionDate – The most recent date there was any of the following activity: a commit to a repository’s default branch, opening an issue or discussion, answering a discussion, proposing a pull request, or submitting a pull request review. This is a good single-number metric to find projects that may be unmaintained or in need of archiving.
- CommitCount – A monotonically increasing count of the total number of commits pushed to the default branch of the repository. Tracking the change in this over time will give a sense of the overall activity in the repository.
These metrics are currently in public beta, so you will need to include a header to your GraphQL requests to opt-in:
GraphQL-Features: ospo_metrics_apiAdditional documentation and context around these metrics is available in the github-ospo repo. Please provide your feedback on this discussion thread: https://github.com/orgs/community/discussions/72156