Note: Secret scanning as a protection push is currently in beta and subject to change. To request access to the beta release, contact your account management team.
About push protection for secrets
Up to now, secret scanning for advanced security checks for secrets after a push and alerts users to exposed secrets. When you enable push protection, secret scanning also checks pushes for high-confidence secrets (those identified with a low false positive rate). 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:
- generates an alert.
- creates an alert in the "Security" tab of the repository.
- adds the bypass event to the audit log.
- sends an email alert to organization owners, security managers, and repository administrators, with a link to the related secret and the reason why it was allowed.
Secret scanning as a push protection currently scans repositories for secrets issued by the following service providers.
If access to a resource requires paired credentials, then secret scanning will create an alert only when both parts of the pair are detected in the same file. This ensures that the most critical leaks are not hidden behind information about partial leaks.
Provider | Supported secret | Secret type |
---|---|---|
Adafruit IO | Adafruit IO Key | adafruit_io_key |
Alibaba Cloud | Alibaba Cloud Access Key ID with Alibaba Cloud Access Key Secret | alibaba_cloud_access_key_id alibaba_cloud_access_key_secret |
Amazon | Amazon OAuth Client ID with Amazon OAuth Client Secret | amazon_oauth_client_id amazon_oauth_client_secret |
Amazon Web Services (AWS) | Amazon AWS Access Key ID with Amazon AWS Secret Access Key | aws_access_key_id aws_secret_access_key |
Amazon Web Services (AWS) | Amazon AWS Session Token with Amazon AWS Temporary Access Key ID and Amazon AWS Secret Access Key | aws_session_token aws_temporary_access_key_id aws_secret_access_key |
Asana | Asana Personal Access Token | asana_personal_access_token |
Atlassian | Bitbucket Server Personal Access Token | bitbucket_server_personal_access_token |
Azure | Azure Active Directory Application Secret | azure_active_directory_application_secret |
Azure | Azure Cache for Redis Access Key | azure_cache_for_redis_access_key |
Azure | Azure DevOps Personal Access Token | azure_devops_personal_access_token |
Azure | Azure Storage Account Key | azure_storage_account_key |
Checkout.com | Checkout.com Production Secret Key | checkout_production_secret_key |
Clojars | Clojars Deploy Token | clojars_deploy_token |
Databricks | Databricks Access Token | databricks_access_token |
DigitalOcean | DigitalOcean Personal Access Token | digitalocean_personal_access_token |
DigitalOcean | DigitalOcean OAuth Token | digitalocean_oauth_token |
DigitalOcean | DigitalOcean Refresh Token | digitalocean_refresh_token |
DigitalOcean | DigitalOcean System Token | digitalocean_system_token |
Discord | Discord Bot Token | discord_bot_token |
Doppler | Doppler Personal Token | doppler_personal_token |
Doppler | Doppler Service Token | doppler_service_token |
Doppler | Doppler CLI Token | doppler_cli_token |
Doppler | Doppler SCIM Token | doppler_scim_token |
Doppler | Doppler Audit Token | doppler_audit_token |
Dropbox | Dropbox Short Lived Access Token | dropbox_short_lived_access_token |
Duffel | Duffel Live Access Token | duffel_live_access_token |
EasyPost | EasyPost Production API Key | easypost_production_api_key |
Flutterwave | Flutterwave Live API Secret Key | flutterwave_live_api_secret_key |
Fullstory | FullStory API Key | fullstory_api_key |
GitHub | GitHub Personal Access Token | github_personal_access_token |
GitHub | GitHub OAuth Access Token | github_oauth_access_token |
GitHub | GitHub Refresh Token | github_refresh_token |
GitHub | GitHub App Installation Access Token | github_app_installation_access_token |
GitHub | GitHub SSH Private Key | github_ssh_private_key |
Google Cloud Storage Service Account Access Key ID with Google Cloud Storage Access Key Secret | google_cloud_storage_service_account_access_key_id google_cloud_storage_access_key_secret | |
Google Cloud Storage User Access Key ID with Google Cloud Storage Access Key Secret | google_cloud_storage_user_access_key_id google_cloud_storage_access_key_secret | |
Google OAuth Client ID with Google OAuth Client Secret | google_oauth_client_id google_oauth_client_secret | |
Grafana | Grafana API Key | grafana_api_key |
Hubspot | Hubspot API Key | hubspot_api_key |
Intercom | Intercom Access Token | intercom_access_token |
JFrog | JFrog Platform Access Token | jfrog_platform_access_token |
JFrog | JFrog Platform API Key | jfrog_platform_api_key |
Ionic | Ionic Personal Access Token | ionic_personal_access_token |
Ionic | Ionic Refresh Token | ionic_refresh_token |
Linear | Linear API Key | linear_api_key |
Linear | Linear OAuth Access Token | linear_oauth_access_token |
Midtrans | Midtrans Production Server Key | midtrans_production_server_key |
New Relic | New Relic Personal API Key | new_relic_personal_api_key |
New Relic | New Relic REST API Key | new_relic_rest_api_key |
New Relic | New Relic Insights Query Key | new_relic_insights_query_key |
npm | npm Access Token | npm_access_token |
NuGet | NuGet API Key | nuget_api_key |
Onfido | Onfido Live API Token | onfido_live_api_token |
OpenAI | OpenAI API Key | openai_api_key |
PlanetScale | PlanetScale Database Password | planetscale_database_password |
PlanetScale | PlanetScale OAuth Token | planetscale_oauth_token |
PlanetScale | PlanetScale Service Token | planetscale_service_token |
Postman | Postman API Key | postman_api_key |
Prefect | Prefect Server API Key | prefect_server_api_key |
Prefect | Prefect User API Key | prefect_user_api_key |
Proctorio | Proctorio Secret Key | proctorio_secret_key |
ReadMe | ReadMe API Access Key | readmeio_api_access_token |
redirect.pizza | redirect.pizza API Token | redirect_pizza_api_token |
Samsara | Samsara API Token | samsara_api_token |
Samsara | Samsara OAuth Access Token | samsara_oauth_access_token |
SendGrid | SendGrid API Key | sendgrid_api_key |
Sendinblue | Sendinblue API Key | sendinblue_api_key |
Sendinblue | Sendinblue SMTP Key | sendinblue_smtp_key |
Shippo | Shippo Live API Token | shippo_live_api_token |
Shopify | Shopify App Shared Secret | shopify_app_shared_secret |
Shopify | Shopify Access Token | shopify_access_token |
Slack | Slack API Token | slack_api_token |
Stripe | Stripe Live API Secret Key | stripe_api_key |
Tencent Cloud | Tencent Cloud Secret ID | tencent_cloud_secret_id |
Typeform | Typeform Personal Access Token | typeform_personal_access_token |
Uniwise | WISEflow API Key | wiseflow_api_key |
WorkOS | WorkOS Production API Key | workos_production_api_key |
Zuplo | Zuplo Consumer API Key | zuplo_consumer_api_key |
Enabling secret scanning as a push protection
For you to use secret scanning as a push protection, the organization or repository needs to have both GitHub Advanced Security and 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 enable push protection for secret scanning via the UI and API. For more information, see "Repositories" and expand the "Properties of the security_and_analysis
object" section in the REST API documentation.
Enabling secret scanning as a push protection for an organization
-
On GitHub.com, navigate to the main page of the organization.
-
Under your organization name, 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 all.
-
Optionally, click "Automatically enable for private repositories added to secret scanning."
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.
-
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.
Using secret scanning as a push protection from the command line
When you attempt to push a supported secret to a repository or organization with secret scanning as a push protection enabled, GitHub will block the push. You can remove the secret from your commit or follow a provided URL to allow the push.
Up to five detected secrets will be displayed at a time on the command line. If a particular secret has already been detected in the repository and an alert already exists, GitHub will not block that secret.
If you need to remove the secret from your latest commit (that is, HEAD
) on the branch being pushed and any earlier commits that contain the secret, you can remove the secret from HEAD
, then squash the commits between when the commit was introduced and the first version of HEAD
for which the secret has been removed.
Notes:
- If your git configuration supports pushes to multiple branches, and not only to the default branch, your push may be blocked due to additional and unintended refs being pushed. For more information, see the
push.default
options in the Git Docs. - If secret scanning upon a push times out, GitHub will still run a scan after the push.
Allowing a blocked secret to be pushed
If GitHub blocks a secret that you believe is safe to push, you can allow the secret and specify the reason why it should be allowed.
If you confirm a secret is real and that you intend to fix it later, you should aim to remediate the secret as soon as possible. For example, you might revoke the secret and remove the secret from the repository's commit history. For more information, see "Removing sensitive data from a repository."
When you allow a secret to be pushed, an alert is created in the "Security" tab. GitHub closes the alert and doesn't send a notification if you specify that the secret is a false positive or used only in tests. If you specify that the secret is real and that you will fix it later, GitHub keeps the security alert open and sends notifications to the author of the commit, as well as to repository administrators. For more information, see "Managing alerts from secret scanning."
When a contributor bypasses a push protection block for a secret, GitHub also sends an email alert to the organization owners, security managers, and repository administrators who have opted in for email notifications.
- Visit the URL returned by GitHub when your push was blocked.
- Choose the option that best describes why you should be able to push the secret.
- If the secret is only used in tests and poses no threat, click It's used in tests.
- If the detected string is not a secret, click It's a false positive.
- If the secret is real but you intend to fix it later, click I'll fix it later.
- Click Allow me to push this secret.
- Reattempt the push on the command line within three hours. If you have not pushed within three hours, you will need to repeat this process.
Using secret scanning as a push protection from the web UI
When you use the web UI to attempt to commit a supported secret to a repository or organization with secret scanning as a push protection enabled, GitHub will block the commit. You will see a banner at the top of the page with information about the secret's location, and the secret will also be underlined in the file so you can easily find it.
GitHub will only display one detected secret at a time in the web UI. If a particular secret has already been detected in the repository and an alert already exists, GitHub will not block that secret.
You can remove the secret from the file using the web UI. Once you remove the secret, the banner at the top of the page will change and tell you that you can now commit your changes.
Bypassing push protection for a secret
If GitHub blocks a secret that you believe is safe to push, you can allow the secret and specify the reason why it should be allowed. If you confirm a secret is real and that you intend to fix it later, you should aim to remediate the secret as soon as possible.
When you allow a secret to be pushed, an alert is created in the "Security" tab. GitHub closes the alert and doesn't send a notification if you specify that the secret is a false positive or used only in tests. If you specify that the secret is real and that you will fix it later, GitHub keeps the security alert open and sends notifications to the author of the commit, as well as to repository administrators. For more information, see "Managing alerts from secret scanning."
When a contributor bypasses a push protection block for a secret, GitHub also sends an email alert to the organization owners, security managers, and repository administrators who have opted in for email notifications.
If you confirm a secret is real and that you intend to fix it later, you should aim to remediate the secret as soon as possible.
-
In the banner that appeared at the top of the page when GitHub blocked your commit, click Bypass protection.
-
Choose the option that best describes why you should be able to push the secret.
- If the secret is only used in tests and poses no threat, click It's used in tests.
- If the detected string is not a secret, click It's a false positive.
- If the secret is real but you intend to fix it later, click I'll fix it later.
-
Click Allow secret.