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.
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 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.
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 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.
In the coming months, the current interface for managing code security settings for an enterprise will be deprecated and replaced with new and improved code security configurations that will provide you a more consistent and scalable way to manage security settings across repositories within your enterprise.
The current REST API endpoint to enable or disable a security feature for an enterprise is now deprecated. It will continue to work for an additional year in the current version of the REST API before being removed in September of 2025, but note that it may conflict with settings assigned in code security configurations if the configuration is unenforced, potentially resulting in a security configuration being unintentionally removed from a repository. To change the security settings for repositories at the enterprise level, you can use the current enterprise-level security settings UI or the upcoming code security configurations API.
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 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.
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. Both indicators apply only for newly created alerts.
In the future, GitHub will surface locations of the known public leak, as well as repository names with duplicate alerts. This metadata will also be surfaced via the REST API and webhooks.
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.
GitHub Advanced Security customers that have enabled delegated bypass rules for push protection can now manage and review their bypass requests at the organization level. The list is located within the Security tab of your organization.
To view and manage requests from this list, you must either be an organization owner, security manager, or have the fine-grained permission to review and manage push protection bypass requests within your organization.
Learn more about secret scanning or delegated bypass. If you have feedback, we would love for you to join the discussion within GitHub Community.
You can now use Copilot Chat in GitHub.com to search across GitHub to find and learn more about GitHub Advanced Security Alerts from code scanning, secret scanning, and Dependabot. This change helps you to better understand and seamlessly fix security alerts in your pull request. ✨
Try it yourself by asking questions like:
– How would I fix this alert?
– How many alerts do I have on this PR?
– What class is this code scanning alert referencing?
– What library is affected by this Dependabot alert?
– What security alerts do I have in this repository?
Learn more about asking questions in Copilot Chat on GitHub.com or about GitHub Advanced Security.
