About push protection for repositories and organizations
So far, secret scanning checks for secrets after a push and alerts users to exposed secrets. When you enable push protection for your organization or repository, secret scanning also checks pushes for supported secrets. Secret scanning lists any secrets it detects so the author can review the secrets and remove them or, if needed, allow those secrets to be pushed.
If a contributor bypasses a push protection block for a secret, GitHub:
- Creates an alert in the Security tab of the repository.
- Adds the bypass event to the audit log.
- Sends an email alert to organization or personal account owners, security managers, and repository administrators who are watching the repository, with a link to the secret and the reason why it was allowed.
This table shows the behavior of alerts for each way a user can bypass a push protection block.
| Bypass reason | Alert behavior |
|---|---|
| It's used in tests | GitHub creates a closed alert, resolved as "used in tests" |
| It's a false positive | GitHub creates a closed alert, resolved as "false positive" |
| I'll fix it later | GitHub creates an open alert |
On the secret scanning alerts page for a repository or organization, you can apply the bypassed:true filter to easily see which alerts are the result of a user bypassing push protection. For more information on viewing these alerts, see "Managing alerts from secret scanning."
You can monitor security alerts to discover when users are bypassing push protections and creating alerts. For more information, see "Auditing security alerts."
Note: The github.dev web-based editor doesn't support push protection. For more information about the editor, see "The github.dev web-based editor."
For information on the secrets and service providers supported for push protection, see "Secret scanning patterns."
Enabling secret scanning as a push protection
For you to use secret scanning as a push protection in public repositories, the organization or repository needs to have secret scanning enabled. For more information, see "Managing security and analysis settings for your organization," "Managing security and analysis settings for your repository," and "About GitHub Advanced Security."
Organization owners, security managers, and repository administrators can also enable push protection for secret scanning via the API. For more information, see "REST API endpoints for repositories" and expand the "Properties of the security_and_analysis object" section.
Organization owners can provide a custom link that will be displayed when a push is blocked. This custom link can contain organization-specific resources and advice, such as directions on using a recommended secrets vault or who to contact for questions relating to the blocked secret.
You can also enable push protection for all of your existing public repositories through your personal account settings. For any new public repositories you create, push protection will be enabled by default. For more information, see "Configuring secret scanning for your repositories."
Note: When you fork a repository with secret scanning as a push protection enabled, this is not enabled by default on the fork. You can enable it on the fork the same way you enable it on a standalone repository.
Enabling secret scanning as a push protection for an organization
You can find a set of repositories and enable or disable secret scanning as a push protection for them all at the same time. For more information, see "Applying the GitHub-recommended security configuration in your organization."
Enabling secret scanning as a push protection for a repository
-
On GitHub.com, navigate to the main page of the repository.
-
Under your repository name, click Settings. If you cannot see the "Settings" tab, select the dropdown menu, then click Settings.
-
In the "Security" section of the sidebar, click Code security and analysis.
-
Under "Code security and analysis", find "GitHub Advanced Security."
-
Under "Secret scanning", under "Push protection", click Enable.
