secret-scanning

Subscribe to all “secret-scanning” 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

Alerts for non-provider patterns and Copilot-detected passwords are now categorized as generic instead of experimental. This change applies to alert filters and the secondary inbox in your alert list views.

Non-provider patterns and Copilot secret scanning were made generally available in October 2024, after careful iteration to reach the level of quality you’ve come to know and expect from provider-based patterns. These alerts are not considered experimental and should be remediated in accordance with your organization’s standard policies.

Detection for these secret types are available for repositories with a GitHub Advanced Security license. They can be enabled through your repository settings or organization and enterprise code security configurations.

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

See more

Keep control over the security posture of your organization with delegated alert dismissal. With this feature, you can require a review process before alerts are dismissed in code scanning and secret scanning. This helps you manage security risk better, as well as meet audit and compliance requirements.

While this feature adds oversight and control, organizations should carefully balance security needs with development velocity. Things to consider include:

  • Who can close alerts
  • When and how alerts should be closed
  • Who should review and approve dismissal requests.

This feature can be configured and managed at scale using security configurations or at the repository level.

Each dismissal request requires a mandatory comment explaining the rationale, with email notifications sent to both approvers and requesters throughout the process. If rejected, the alert remains open.

People with the organization owner or security manager role can review and approve dismissal requests by default. The state of previously dismissed alerts does not change when enabling this feature.

The dismissal and approval process is visible on the alert timeline, included on the audit log, and accessible through both the REST API and webhooks.

You can enable this feature today for code scanning and secret scanning in GitHub Enterprise Cloud. It will also be available in version 3.17 of GitHub Enterprise Server.

See more

GitHub Advanced Security: Introducing GitHub Secret Protection and Code Security

At GitHub, we believe that investing in the security of your codebases should be straightforward, cost-effective, and accessible for everyone. Today, we’re announcing changes to pricing plans and availability of GitHub Advanced Security (GHAS), aligning with our ongoing mission to help organizations of all sizes secure their code with the flexibility they seek.

Announcing new pricing plans for GitHub Advanced Security

Starting April 1, 2025, GitHub Advanced Security will be available as two standalone security products: GitHub Secret Protection and GitHub Code Security. In addition, these products will become available to GitHub Team plan customers for the first time.

GitHub Secret Protection

New customers can purchase GitHub Secret Protection, which includes features that help detect and prevent secret leaks (e.g. secret scanning, AI-detected passwords, and push protection for secrets). Secret Protection will be available for $19 per month per active committer, with features including:

  • Push protection, to prevent secret leaks before they happen
  • AI detection with a low rate of false positives, so you can focus on what matters
  • Secret scanning alerts with notifications, to help you catch exposures before they become a problem
  • Custom patterns for secrets, so you can search for sensitive organization-specific information
  • Security overview, which provides insight into distribution of risk across your organization
  • Push protection and alert dismissal enforcement for secrets, which supports governance at enterprise scale

In addition, we’re launching a new scanning feature to help organizations understand their secret leak footprint across their GitHub perimeter. This feature will be free for GitHub Team and Enterprise organizations.

GitHub Code Security

New customers will also be able to purchase Code Security, which detects and fixes vulnerabilities in your code before it reaches production. Code Security will be available for $30 per month per active committer with features including:

  • Copilot Autofix for vulnerabilities in existing code and pull requests for developer-first security management
  • Security campaigns to address security debt at scale
  • Dependabot features for protection against dependency-based vulnerabilities
  • Security overview, which provides insight into distribution of risk across your organization
  • Security findings for third-party tools

Availability for GitHub Team customers

Starting April 1, 2025, customers on the GitHub Team plan can purchase Secret Protection and Code Security. These products will be available through a consumption-based, pay-as-you-go model (i.e., metered billing) to ensure security remains affordable, scalable, and accessible for all customers on GitHub.

Get started today

Existing customers with plans managed with a GitHub or Microsoft sales account team can transition to the new GitHub Advanced Security plans at start time of renewal for renewal dates after April 1, 2025. Please contact your account team for further details. For existing self-serve customers, instructions on how to transition to the new GitHub Advanced Security plans will be announced over the coming months through GitHub’s roadmap and changelog.

GitHub Team customers can choose to purchase Secret Protection or Code Security from their organization settings pages starting April 1, 2025.

If you have any feedback, join the discussion in GitHub Community.

See more

Find secrets in your organization with the secret risk assessment

GitHub is committed to empowering the developer community by helping organizations recognize and address the risks of secret leaks. That’s why we’re launching a new free tool next month which will provide clear insights into their exposure, along with actionable steps to strengthen their security and protect their code.

Scan your organization for aggregate insights on public leaks, private exposures, and token types.

The secret risk assessment provides insights about secret leak exposures

When will this feature be available?

The secret risk assessment will be available on April 1, 2025 as part of the launch of Secret Protection for GitHub Team and Enterprise plans.

What will this dashboard include?

Available in the ‘Security’ tab, organization and security admins will be able to run a scan in order to understand how their organization is affected by secret leaks and exposures. Once a scan is initiated, GitHub will look for secret leaks and exposures across your organization, returning a collection of insights including:

  • Number of secrets leaked per type
  • Number of publicly visible secrets in your public repositories
  • Number of repositories affected per secret type

No specific secrets will be stored or shared. The scan will be a point-in-time assessment across all public and private repositories. For organizations ready to adopt a continuous monitoring tool, we recommend enabling secret scanning for detection and incident management of specific secrets.

Why are we doing this?

We’re launching this feature to help organizations understand their secret leak footprint across their GitHub perimeter.

GitHub is committed to making a meaningful impact on the developer community by helping organizations recognize their risk from secret leaks. Our goal is to provide clear insights into their exposure and a clear path to stronger security.

Who can use this feature?

This feature will be available for free to organizations with a GitHub Team or Enterprise plan. Organization admins and security managers will be able to run the report and review any results.

To learn more about the launch of GitHub Secret Protection, please refer to this changelog. Have questions? Let us know what you think by starting a discussion in GitHub Community — we’re listening.

See more

Push protection for secret scanning blocks any push that contains a secret. By default, this block can be bypassed, which results in a secret scanning alert in the repository. Delegated bypass controls let you choose who is allowed to bypass push protection, and contributors without permissions to bypass must submit a request for approval by the listed reviewers. These controls can reduce the risk of secrets being accidentally exposed in your codebase.

Managing bypass requests is now available with the REST API, offering flexibility for triaging and reviewing by integrating with your existing workflows.

Reviewers can retrieve bypass requests for an organization or repository with the following endpoints:

Reviewers can review a request and dismiss a response to a request with the following endpoints:

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

See more

Copilot secret scanning, which scans for passwords using AI, offers greater precision for detecting unstructured credentials that can cause security breaches if exposed.

You can now use code security configurations to enable Copilot secret scanning across your enterprise or organization, allowing you to control which repositories are detecting passwords at scale.

Copilot secret scanning is available for all repositories with a GitHub Advanced Security license. You do not need a Copilot license. To give you control over how AI is used across your repositories, Copilot secret scanning is not included in the GitHub Recommended configuration.

Learn more about protecting your repositories with secret scanning and generic secret detection.

See more

GitHub continually updates its detectors for secret scanning with new patterns and upgrades of existing patterns, ensuring your repositories have comprehensive detection for different secret types.

GitHub now automatically detects Base64-encoded secrets for the following token types:

  • GitHub personal access tokens
  • GitHub OAuth access tokens
  • GitHub user to server tokens
  • GitHub server to server tokens.

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. See the full list of supported secrets in the documentation.

Learn more about secret scanning or join the discussion on our dedicated GitHub community.

See more

GitHub continually updates the default pattern set for secret scanning with new patterns and upgrades of existing patterns, ensuring your repositories have comprehensive detection for different secret types.

The following new patterns were added over the last few months. Secret scanning automatically detects any secrets matching these patterns in your repositories. See the full list of supported secrets in the documentation.

Provider Token Partner User Push protection
Anthropic anthropic_admin_api_key
Asaas asaas_api_token
Asana asana_legacy_format_personal_access_token  ✓
Azure azure_openai_key
Azure microsoft_azure_common_annotated_security_key
Azure microsoft_azure_entra_id_token
Cfx.re cfxre_server_key
Cockroach Labs ccdb_api_key
Coveo coveo_access_token
Databento databento_api_key
Datastax datastax_astracs_token
Google google_cloud_service_account_credentials
Google google_gcp_api_key_bound_service_account ✓  
Hubspot hubspot_private_apps_user_token
Hubspot hubspot_smtp_credential
Hugging Face hf_user_access_token
Iterative iterative_dvc_studio_access_token
Lichess lichess_personal_access_token
Lichess lichess_oauth_access_token
MongoDB mongodb_atlas_db_uri_with_credentials
Netflix netflix_netkey
OpenRouter openrouter_api_key
Oracle oracle_api_key
Polar polar_access_token
Polar polar_authorization_code
Polar polar_client_registration_token
Polar polar_client_secret
Polar polar_personal_access_token
Polar polar_refresh_token
Replicate replicate_api_token
Scalr scalr_api_token
Sentry sentry_org_auth_token
Sentry sentry_user_auth_token
Sentry sentry_user_app_auth_token
Sentry sentry_integration_token
Shopee shopee_open_platform_partner_key
Siemens siemens_api_token
Sindri sindri_api_key
Tailscale tailscale_api_key

The following existing patterns were upgraded to be included in push protection. When push protection is enabled, secret scanning automatically blocks any pushes that contain a secret matching these patterns.

Provider Token
Contentful contentful_personal_access_token
GitLab gitlab_access_token
Ionic ionic_refresh_token
Orbit orbit_api_token
PyPI pypi_api_token
Thunderstore thunderstore_io_api_token
Yandex yandex_cloud_iam_access_secret

Learn more about securing your repositories with secret scanning.

See more

To enhance auditing and troubleshooting, we’ve introduced new webhook and audit log events to track the completion of certain secret backfill scans on repositories.

The events specify the type of backfill scan completed (e.g., Git backfill or issues backfill) and the secret types scanned, including custom patterns. Note that secrets detected through Copilot Secret Scanning are not included.

Backfill scans cover the entire repository and occur when secret scanning is enabled or patterns are updated. These events do not include information on incremental scans, which focus on new content pushed to a repository.

A repository must have a GitHub Advanced Security license to access these events.

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

See more

You can now more easily filter secret scanning alerts, with new filter options and advanced filtering.

  • Enterprise and organization level list views now include a new menu with commonly used and suggested filter options, like bypassed secrets, publicly leaked secrets, and those with enterprise duplicates. The repository level list view now supports a new “advanced filtering” menu.
  • The experimental toggle has been removed from the alert list header UI, but you can still access it from the sidebar navigation menu and with the results:experimental filter.
  • Public leak and multi-repository indicators are fully supported across list views, including alert list views and the REST API. In the UI, in addition to menu options, you can access these filters with is:multi-repository and is:publicly-leaked. These indicators are also 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 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-repository 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-repository 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.

See more

As part of our ongoing efforts to improve flexibility and control for managing the security manager role, we are retiring the security manager API and replacing it with the more robust organization roles API, which provides expanded functionality for managing roles in an organization, including security managers.

Endpoints Affected

The following security manager endpoints will be retired in 12 months:

  • GET /orgs/{org}/security-managers/teams
  • PUT /orgs/{org}/security-managers/teams/{team_slug}
  • DELETE /orgs/{org}/security-managers/teams/{team_slug}

After this period, these endpoints will no longer be available. Instead, you can use the organization roles API to perform the same actions and much more.

Retirement Timeline

  • GitHub.com: 2025-12-31
  • GitHub Enterprise Server: Version 3.20

Replacements

The organization roles API offers enhanced capabilities for managing roles across an organization. Use the following endpoint as a replacement:

  • GET /orgs/{org}/roles
  • GET /orgs/{org}/roles/{role_id}/teams
  • PUT /orgs/{org}/roles/{role_id}/teams/{team_slug}
  • DELETE /orgs/{org}/roles/{role_id}/teams/{team_slug}

You can start transitioning to the organization roles API today on GitHub.com. For GitHub Enterprise Server users, the organization roles API will support the security manager role starting in version 3.16.

Learn more about the organization roles API and send us your feedback

See more

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.

screenshot of an alert that has bypassed push protection, with a reviewer comment in the timeline

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

See more

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:

Response Description
incremental_scans The latest scan for all patterns on new git content committed to a repository
backfill_scans The latest scan for all patterns on the entire contents of a specific type (git, issues, pull-requests, discussions, wiki)
custom_pattern_backfill_scans The latest scan for a specific custom pattern on the entire contents of a specific type (git, issues, pull-requests, discussions, wiki)
pattern_update_scans The latest scan for a new or updated native pattern on git content in a repository

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.

See more

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.

See more

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.

See more