Secret scanning support for public leak and multi-repository indicators in webhook and audit log events

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.

Repository deploy keys are controlled by enterprise and organization policy [GA]

GitHub Enterprise Cloud enterprise and organization administrators can now configure policies to restrict the usage of deploy keys across all the repositories of their organizations, giving you more control and greater security over your deploy keys.

Deploy keys provide SSH access to a single repository and are often used by integrations with external servers to a repository without using a personal GitHub account. However, this makes it hard to track the lifecycle of deploy keys across your repositories, as they exist outside of a user context and have no timed expiration capability. Now with the ability to set deploy key policies, you can more easily track and manage your deploy keys across your repositories.

All new enterprises and organizations will have the deploy key policy disabled by default.

For compatibility reasons, the deploy key policy will be enabled by default for all existing enterprises and organizations. You may want to explicitly disable the setting after evaluating and replace your deploy key usage with more secure alternatives like GitHub Apps.

For more details, learn more about the new policy for managing deploy keys.

See more

Announcing GitHub for Nonprofits

Now, verified nonprofits can access the GitHub Team plan for free or receive 25% off the GitHub Enterprise Cloud plan through GitHub for Nonprofits. This includes nonprofit organizations that are 501(c)(3) or equivalent and are non-governmental, non-academic, non-commercial, non-political in nature, and have no religious affiliation.

You can sign up here to get exclusive discounts automatically applied to your account. Join GitHub for Nonprofits, where technology meets purpose, and together, let’s create a more sustainable and equitable future for all.

Join the discussion within GitHub Community.

See more
View all changes