secret-scanning

Reviewers can now add comments to push protection bypass requests in secret scanning. These comments help provide context, explaining the reasoning behind approving or denying a request. Requesters gain clarity on why their request was denied, and other reviewers can better understand why a request was approved or denied.

The comment is included in the response email sent to the requester, as well as in the timeline of the resulting alert, the API, the audit log, and webhook responses.

Learn more about how to secure your repositories with secret scanning and push protection bypass controls.

A new REST API endpoint lists the secret scanning scan history for a repository, giving you visibility into when different types of secret scanning scans have occurred in your repository. This information can be helpful for auditing purposes and troubleshooting.

To get your repository’s scan history, call the /repos/{owner}/{repo}/secret-scanning/scan-history endpoint. The following table lists the responses returned by the API:

Secret scanning covers multiple scan sources, triggers, and methods of scanning. Scans listed in the API are not an exhaustive list of all scans for a repository. The following scans are not included:
– incremental scans and pattern update scans for non-git content types
– non-git backfills for custom patterns set at the repository level
– any pattern update scans completed before September 2024
– scans for passwords detected with Copilot Secret Scanning

A repository must have a GitHub Advanced Security license to get the scan history.

Learn more about how to secure your repositories with secret scanning.

To remediate and triage alerts more effectively, you can now add an optional comment when reopening a secret scanning alert. Comments will appear in the alert timeline. Previously, you could only add a comment when closing the alert.

Learn more about how to secure your repositories with secret scanning. Let us know what you think by participating in a GitHub community discussion or signing up for a 60 minute feedback session.

Secret scanning alerts resulting from an approved push protection bypass request will now show relevant details in the alert information surfaced in the REST API, webhooks, and audit logs. This allows information currently visible in the UI to be used in automated workflows.

Secret scanning alert REST API endpoints and webhook events now include the following fields:
– push_protection_bypass_request_reviewer
– push_protection_bypass_request_comment
– push_protection_bypass_request_html_url

Audit log events for push protection bypasses now include the following fields:
– push_protection_bypass_request_reviewer
– push_protection_bypass_request_reviewer_id

Learn more about secret scanning and bypass controls for push protection.

Secret scanning now supports delegated bypass controls for repository file uploads from the browser.

If delegated bypass is configured for an organization or repository, anyone without bypass permissions will need to submit a bypass request to approved reviewers in order to upload a file that contains a secret. This helps ensure that secrets are not accidentally committed to a repository.

For more information, see “About secret scanning” and “About delegated bypass for push protection.”

Public leak and multi-repository indicators are now included in webhook and audit log event payloads for secret scanning alerts.

What are public leak and multi-repo labels?

To help you triage and remediate secret leaks more effectively, GitHub secret scanning indicates if a secret detected in your repository has also leaked publicly with a public leak label on the alert. The alert also indicates if the secret was exposed in other repositories across your organization or enterprise with a multi-repo label.

These labels provide additional understanding into the distribution of an exposed secret, while also making it easier to assess an alert’s risk and urgency. For example, a secret which has a known associated exposure in a public location has a higher likelihood of exploitation. Detection of public leaks is only currently supported for provider-based patterns.

The multi-repo label makes it easier to de-duplicate alerts and is supported for all secret types, including custom patterns. You can only view and navigate to other enterprise repositories with duplicate alerts if you have appropriate permissions to view them.

Both indicators currently apply only for newly created alerts.

Learn more

Learn more about reviewing alert labels and how to secure your repositories with secret scanning. Let us know what you think by participating in our GitHub community discussion or signing up for a 60 minute feedback session.

Secret scanning bypass privileges for push protection are now generally available.

These controls allow you to choose who is allowed to bypass push protection, and introduce a review and approval cycle for pushes containing secrets from all other contributors. This can ensure push protection blocks are not accidentally bypassed and prevent secrets from being committed to your repositories.

Controls for bypass privileges can be set as part of your organization’s security configurations or at the repository level in your code security settings. You can add specific roles or teams to your bypass list. The individuals in these roles and teams will be able to bypass push protection themselves, and will act as reviewers for any bypass requests submitted by another contributor. The requests can be approved or denied, determining whether the commit can proceed into the repository.

Reviewers can view the requests under the Security tab at either the organization level or repository level. Requests can also be accessed through audit log and webhook events.

Learn more about secret scanning and push protection, or join the discussion in the GitHub Community.

You can now view exact locations of known public leaks for a secret scanning alert, as well as any repositories with duplicate alerts across your enterprise. Public leak and duplicate alert labels are now also surfaced via the REST API.

What are public leak and multi-repo labels?

To help you triage and remediate secret leaks more effectively, GitHub secret scanning now indicates if a secret detected in your repository has also leaked publicly with a public leak label on the alert. The alert also indicates if the secret was exposed in other repositories across your organization or enterprise with a multi-repo label.

These labels provide additional understanding into the distribution of an exposed secret, while also making it easier to assess an alert’s risk and urgency. For example, a secret which has a known associated exposure in a public location has a higher likelihood of exploitation. Detection of public leaks is only currently supported for provider-based patterns.

The multi-repo label makes it easier to de-duplicate alerts and is supported for all secret types, including custom patterns. You can only view and navigate to other enterprise repositories with duplicate alerts if you have appropriate permissions to view them.

Both indicators currently apply only for newly created alerts.

Learn more

Learn more about reviewing alert labels and how to secure your repositories with secret scanning. Let us know what you think by participating in our GitHub community discussion or signing up for a 60 minute feedback session.

Copilot secret scanning is now generally available. Copilot secret scanning, which detects generic passwords using AI, offers greater precision for unstructured credentials that can cause security breaches if exposed. Over 350,000 repositories have already enabled this password detection.

To enable Copilot secret scanning, select “Scan for generic secrets” within your code security and analysis settings at the repository level, or the code security global settings at the organization level. You can also use the Update a repository API endpoint for enablement at the repository level. Support for enablement through your organization’s code security configurations, as well as enablement for organizations and enterprises with the API, will come in a future release.

Password detection is backed by the Copilot API and is available for all repositories with a GitHub Advanced Security license. You do not need a Copilot license to enable generic secret detection. Passwords found in git content will create a secret scanning alert in the “Experimental” tab, separate from regular alerts.

In effort to reduce false positives and detections of secrets that are used in tests, Copilot secret scanning will not:
– detect more than 100 passwords per push
– detect secrets in media files (.svg, .png, .jpeg)
– detect secrets in language files (.js, .py, .ts, .java, .cs, or .rb) that contain test, mock, or spec in the filepath
– detect additional secrets in files where five or more alerts have been marked as false positive

Note that passwords will not be detected in non-git content, like GitHub Issues or pull requests. Passwords are also excluded from push protection, another feature of secret scanning designed to prevent sensitive information from being pushed to your repository.

Learn more about secret scanning and generic secret detection or join our community discussion.

Secret scanning support for non-provider patterns is now generally available for all GitHub Advanced Security customers.

Non-provider patterns are generic detectors that help you uncover secrets outside of patterns tied to specific token issuers, like HTTP authentication headers, connection strings, and private keys. You can enable them in your repository’s code security and analysis settings, or through code security configurations at the organization level.

Learn more about secret scanning and non-provider patterns, and join the GitHub Community discussion.

The secret scanning alert lists are now named “Default” and “Experimental,” better reflecting the alert categories and making it easier for you to tell experimental alerts from default alerts.

The Default list includes alerts for provider patterns and custom patterns. The Experimental list includes alerts for non-provider patterns and AI-detected passwords. You can view the alert counts of these two lists in the organization-level Security tab in the sidebar, bringing more clarity and visibility into your alerts.

You can filter within the alert list using results:default and results:experimental.

Learn more about secret scanning and the supported patterns.

You can now report compromised GitHub personal access tokens to GitHub, directly from a secret scanning alert. When you let GitHub know that the secret has been compromised, GitHub will treat the token like a publicly leaked token and revoke it. This change simplifies remediation and makes it more easily actionable.

The token owner will receive an email notification when their token is revoked. As a best practice, you should review any associated token metadata and reach out to the token owner, if possible, before reporting the token. Consider rotating the secret first to prevent breaking workflows.

Learn more

Learn more about how to report a compromised GitHub personal access token. Let us know what you think by participating in a GitHub community discussion or signing up for a 60 minute feedback session.

GitHub Advanced Security customers using secret scanning can now use the REST API to enable or disable support for non-provider patterns at the enterprise level. This enables you to manage your enterprise settings programatically.

The following endpoints have been updated:
– Get code security and analysis features for an enterprise: check if non-provider patterns are enabled for the enterprise
– Update code security and analysis features for an enterprise: enable or disable non-provider patterns for all new repositories in an enterprise
– Enable or disable a security feature: enable or disable non-provider patterns for all existing repositories in an enterprise

Non-provider patterns scans for token types from generic providers, like private keys, auth headers, and connection strings.

Learn more about secret scanning and non-provider patterns.

Join the community discussion and share feedback with us in this dedicated community post.