Secret scanning supports delegated bypass for push protection on file uploads (GA)

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.”

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.

See more

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
View all changes