advanced-security

Subscribe to all “advanced-security” posts via RSS or follow GitHub Changelog on Twitter to stay updated on everything we ship.

~ cd github-changelog
~/github-changelog|main git log main
showing all changes successfully

The GitHub Advanced Security billing REST API and CSV download now includes the email addresses for active committers. This provides information for insights into Advanced Security license usage across your business. Here is an example response from the GitHub Advanced Security billing REST API:

      "advanced_security_committers_breakdown": [
        {
          "user_login": "octokitten",
          "last_pushed_date": "2023-10-26",
          "last_pushed_email": "octokitten@email.com"
        }

Read more about the GHAS billing API here and the GHAS billing CSV download here.

This is available now on GitHub.com and will ship to GitHub Enterprise Server 3.12

See more

GitHub Advanced Security users can now use the REST API to retrieve the validity status of a secret scanning token and retrieve all tokens of a particular validity status. The API will return the status of the token as of the last validity check. Valid statuses are active, inactive, or unknown. Validity checks must be enabled for the enterprise, organization, or repository.

See more

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.

Dependabot auto-triage rules list

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.

Create a stacked Dependabot auto-triage ruleset

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?

Enforce a Dependabot auto-triage rule

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.

Target alerts based on attributes

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?

How do I provide feedback?

Let us know what you think by providing feedback — we’re listening!

See more

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.

See more

Code scanning default setup now automatically attempts to analyze all CodeQL supported languages in a repository. This means default setup supports all CodeQL languages at the organization level, including enabling code scanning from an organization's Security Overview coverage page or settings page.

Previously, users would have to manually include the languages C, C++, C#, Java, or Kotlin in a default setup analysis, and enabling these languages was not supported at the organization level. Now, code scanning default setup automatically attempts to analyze all languages supported by CodeQL in a repository. If any analyses fail, the failed language will be automatically deselected from the code scanning configuration. Any alerts from the successfully analyzed languages will be shown on GitHub. This means code scanning will automatically set up the best possible configuration to get started easily with CodeQL and show the most relevant alerts to developers.

A warning banner is shown in the repository settings page if any languages fail and are deseslected. The "edit configuration" page shows all languages in the configuration, and allows users to change the language selection if required. For more information about the languages and versions supported by CodeQL and code scanning, see Supported languages and frameworks. To learn more about code scanning, see About code scanning.

This change is already available on GitHub.com and will be available in GitHub Enterprise Server 3.12.

See more

GitHub secret scanning protects users by searching repositories for known types of secrets such as tokens and private keys. By identifying and flagging these secrets, our scans help prevent data leaks and fraud.

We have partnered with Authress to scan for their service client access keys and their user API tokens to help secure our mutual users in public repositories. Authress access keys allow users to secure applications and platforms through machine-to-machine authentication and they enable granular resource-based authorization. GitHub will forward any exposed access keys found in public repositories to Authress, who will automatically revoke the exposed access key, create an audit trail message that can be ingested by SIEM technologies, and send an email alert to your Authress account admin. Read more information about Authress API access keys.

All users can scan for and block Authress keys from entering their public repositories for free with push protection. GitHub Advanced Security customers can also scan for and block Authress keys in their private repositories.

See more

To enable developers to write code as securely as possible in their language of choice and using the latest features available, we constantly update code scanning with CodeQL. As such we are happy to announce that CodeQL now supports analyzing code written in Go 1.21.

Go 1.21 support is available by default in GitHub.com code scanning, CodeQL version 2.14.6, and GHES 3.11. For more information about the languages and versions supported by CodeQL and code scanning, see Supported languages and frameworks. To learn more about code scanning, see About code scanning.

See more

GitHub secret scanning protects users by searching repositories for known types of secrets such as tokens and private keys. By identifying and flagging these secrets, our scans help prevent data leaks and fraud.

We have partnered with Mercury to scan for their license keys and help secure our mutual users on public repositories. Mercury tokens allow users to automate your banking needs through their API. GitHub will forward tokens found in public repositories to Mercury, who will then revoke them, keeping your account safe. Read more information about Mercury tokens.

All users can scan for and block Mercury tokens from entering their public repositories for free with push protection. GitHub Advanced Security customers can also scan for and block Mercury tokens in their private repositories.

See more

GitHub Advanced Security customers that have validity checks enabled for secret scanning will see the validation status for the following Discord tokens:

  • discord_api_token_v2
  • discord_bot_token

View our supported secrets documentation to keep up to date as we expand validation support.

See more

GitHub secret scanning protects users by searching repositories for known types of secrets such as tokens and private keys. By identifying and flagging these secrets, our scans help prevent data leaks and fraud.

We have partnered with MaxMind to scan for their license keys and help secure our mutual users on public repositories. MaxMind keys allow users to run queries against minFraud®, GeoIP®, and GeoLite services, and download GeoIP and GeoLite databases. GitHub will forward license keys found in public repositories to MaxMind, who will then email the user about the leaked key. You can read more information about MaxMind keys here.

All users can scan for and block MaxMind keys from entering their public repositories for free with push protection. GitHub Advanced Security customers can also scan for and block MaxMind keys in their private repositories.

Learn more about secret scanning
Partner with GitHub on secret scanning

See more

GitHub secret scanning protects users by searching repositories for known types of secrets. By identifying and flagging these secrets, our scans help prevent data leaks and fraud.

We have partnered with Pinterest to scan for their API tokens and help secure our mutual users on public repositories. Pinterest tokens allow developers to interact with Pinterest's API in order to build experiences and apps for creators, advertisers, merchants and users on top of Pinterest. GitHub will forward access tokens found in public repositories to Pinterest, which will then notify the user about the leaked token. You can read more information about Pinterest tokens here.

All users can scan for and block Pinterest's tokens from entering their public repositories for free with push protection. GitHub Advanced Security customers can also scan for and block Pinterest tokens in their private repositories.

See more

GitHub Advanced Security customers that have validity checks enabled will see the validation status for select AWS, Google, Microsoft, and Slack tokens on the alert.

The following tokens are supported:

  • aws_access_key_id
  • aws_secret_access_key
  • aws_session_token
  • aws_temporary_access_key_id
  • aws_secret_access_key
  • google_oauth_access_token
  • google_api_key
  • nuget_api_key
  • slack_api_token

AWS tokens will have validation checks performed periodically in the background, with on-demand validity checks to come in the future.

View our supported secrets documentation to keep up to date as we expand validation support.

See more

In February 2022, we introduced experimental CodeQL queries that utilize machine learning to identify more potential vulnerabilities. This feature was only available for JavaScript / TypeScript code and was available to code scanning users that enabled the optional security-extended or security-and-quality query suites.

We disabled this experimental feature for new code scanning users in June 2023. Today, we're sunsetting it for all users.

Any currently open code scanning alerts from these queries (Rule ID starts with js/ml-powered/) will be closed. Closed alerts will still be visible in the code scanning alerts view in your repository’s Security tab. The complete history of each alert will remain accessible by clicking on the alert.

CodeQL will continue to run the existing non-ML versions of these queries and provide you with highly precise and actionable alerts.

We’ve learned a lot from the feedback and experience of the repositories that participated in this experiment, and we’ve since ramped up our investment in AI-powered security technology. This new technology is already boosting our ability to cover more sources and sinks of untrusted data in order to significantly increase the coverage and depth of all queries.

See more

GitHub Advanced Security now automatically only consumes licenses for commits and pushes made after a repository is migrated to GitHub, rather than considering all historic contributions from before the migration.

When a repository is migrated to GitHub, all historic commits are combined into a single push. This meant that when GitHub Advanced Security was enabled the repository would use licenses for all commits in that combined push, and so consume licenses for all historic commits. Previously this would be resolved manually, but this ship automates this work. GitHub Advanced Security now only uses licences for commits and pushes made after migration and does not consider legacy pushes that occurred in migrated repositories.

This has shipped to GitHub.com and will ship to GitHub Enterprise Server 3.12. Read more about billing for GitHub Advanced Security.

See more