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.

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

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.

screenshot of bypass privileges within security configurations

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.

See more