Protecting pushes with secret scanning

About push protection for secrets

Up to now, >- Secret scanning 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.

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	サポートされているシークレット	シークレットの種類
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
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アクセストークン	github_oauth_access_token
GitHub	GitHub Refreshトークン	github_refresh_token
GitHub	GitHub App Installation Access Token	github_app_installation_access_token
GitHub	GitHub SSH Private Key	github_ssh_private_key
Google	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	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	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

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

1. GitHub Enterprise Serverインスタンスで、Organizationのメインページにアクセスしてください。
2. Organization 名の下で、クリックします Settings.

1. In the "Security" section of the sidebar, click Code security and analysis.

2. Under "Code security and analysis", find "GitHub Advanced Security."

3. "Secret scanning"の下の"Push protection（プッシュ保護）"の下で、Enable all（すべて有効化）をクリックしてください。

4. あるいは、"Automatically enable for private repositories added to secret scanning"をクリックしてください。

Enabling secret scanning as a push protection for a repository

1. GitHub Enterprise Serverインスタンスで、リポジトリのメインページにアクセスしてください。

2. リポジトリ名の下で Settings（設定）をクリックしてください。

3. In the "Security" section of the sidebar, click Code security and analysis.

4. Under "Code security and analysis", find "GitHub Advanced Security."

5. "Secret scanning"の下の"Push protection（プッシュ保護）"の下で、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.

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

1. Visit the URL returned by GitHub when your push was blocked.
2. 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.
3. Click Allow me to push this secret.
4. 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.