About the secret scanning alerts page
When you enable secret scanning for a repository or push commits to a repository with secret scanning enabled, GitHub scans the contents for secrets that match patterns defined by service providers and any custom patterns defined in your enterprise, organization, or repository.
When secret scanning detects a secret, GitHub generates an alert. GitHub displays an alert in the Security tab of the repository.
To help you triage alerts more effectively, GitHub separates alerts into two lists:
- High confidence alerts.
- Other alerts.
High confidence alerts list
The "High confidence" alerts list displays alerts that relate to supported patterns and specified custom patterns. This list is always the default view for the alerts page.
Other alerts list
The "Other" alerts list displays alerts that relate to non-provider patterns (such as private keys), or generic secrets detected using AI (such as passwords). These types of alerts have a higher rate of false positives.
In addition, alerts that fall into this category:
- Are limited in quantity to 5000 alerts per repository (this includes open and closed alerts).
- Are not shown in the summary views for security overview, only in the "Secret scanning" view.
- Only have the first five detected locations shown on GitHub for non-provider patterns, and only the first detected location shown for AI-detected generic secrets.
For GitHub to scan for non-provider patterns and generic secrets, you must first enable the features for your repository or organization. For more information, see "Configuring secret scanning for your repositories" and "Enabling AI-powered generic secret detection."
Viewing alerts
-
On GitHub.com, navigate to the main page of the repository.
-
Under the repository name, click Security. If you cannot see the "Security" tab, select the dropdown menu, and then click Security.
-
In the left sidebar, under "Vulnerability alerts", click Secret scanning.
-
Optionally, toggle to "Other" to see alerts for non-provider patterns or generic secrets detected using AI.
-
Under "Secret scanning", click the alert you want to view.
Note
Only people with admin permissions to the repository containing a leaked secret can view security alert details and token metadata for an alert. Enterprise owners can request temporary access to the repository for this purpose.
Filtering alerts
You can apply various filters to the alerts list to help you find the alerts you're interested in. You can use the dropdown menus above the alerts list, or input the qualifiers listed in the table into the search bar.
Qualifier | Description |
---|---|
is:open | Displays open alerts. |
is:closed | Displays closed alerts. |
bypassed: true | Displays alerts for secrets where push protection has been bypassed. For more information, see "Push protection for repositories and organizations." |
validity:active | Displays alerts for secrets that are still active. For more information about validity statuses, see "Checking a secret's validity." |
validity:inactive | Displays alerts for secrets that are no longer active. |
validity:unknown | Displays alerts for secrets where the validity status of the secret is unknown. |
secret-type:SECRET-NAME | Displays alerts for a specific secret type, for example, secret-type:github_personal_access_token . For a list of supported secret types, see "Secret scanning patterns." |
provider:PROVIDER-NAME | Displays alerts for a specific provider, for example, provider:github . For a list of supported partners, see "Secret scanning patterns." |
confidence:high | Displays alerts for high-confidence secrets, which relate to supported secrets and custom patterns. For a list of supported high-confidence patterns, see "Secret scanning patterns." |
confidence:other | Displays alerts for non-provider patterns, such as private keys, and AI-detected generic secrets, such as passwords. For a list of supported non-provider patterns, see "Secret scanning patterns." For more information AI-detected generic secrets, see "About the detection of generic secrets with secret scanning." |
Evaluating alerts
There are some additional features that can help you to evaluate alerts in order to better prioritize and manage them. You can:
- Check the validity of a secret, to see if the secret is still active. For more information, see "Checking a secret's validity."
- Perform an "on-demand" validity check, to get the most up to date validiation status. For more information, see "Performing an on-demand-validity-check."
- Review a token's metadata. Applies to GitHub tokens only. For example, to see when the token was last used. For more information, see "Reviewing GitHub token metadata."
Checking a secret's validity
Note
Validity checks for partner patterns is currently in beta and subject to change.
Validity checks help you prioritize alerts by telling you which secrets are active
or inactive
. An active
secret is one that could still be exploited, so these alerts should be reviewed and remediated as a priority.
By default, GitHub checks the validity of GitHub tokens and displays the validitation status of the token in the alert view.
You can additionally choose to enable validity checks for partner patterns. Once enabled, GitHub will periodically check the validity of a detected credential by sending the secret directly to the provider, as part of GitHub's formal secret scanning partnership program. GitHub typically makes GET requests to check the validity of the credential, picks the least intrusive endpoints, and selects endpoints that don't return any personal information.
GitHub displays the validation status of the secret in the alert view.
Validity | Status | Result |
---|---|---|
Active secret | active | GitHub checked with this secret's provider and found that the secret is active |
Possibly active secret | unknown | GitHub does not support validation checks for this token type yet |
Possibly active secret | unknown | GitHub could not verify this secret |
Secret inactive | inactive | You should make sure no unauthorized access has already occurred |
Validity checks for partner patterns is available on all types of repositories on GitHub.com. To use this feature, you must have a license for GitHub Advanced Security.
For information on how to enable validity checks for partner patterns, see "Configuring secret scanning for your repositories," and for information on which partner patterns are currently supported, see "Secret scanning patterns."
You can use the REST API to retrieve a list of the most recent validation status for each of your tokens. For more information, see "REST API endpoints for secret scanning" in the REST API documentation. You can also use webhooks to be notified of activity relating to a secret scanning alert. For more information, see the secret_scanning_alert
event in "Webhook events and payloads."
Performing an on-demand validity check
Once you have enabled validity checks for partner patterns for your repository, you can perform an "on-demand" validity check for any supported secret by clicking Verify secret in the alert view. GitHub will send the pattern to the relevant partner and display the validation status of the secret in the alert view.
Reviewing GitHub token metadata
Note
Metadata for GitHub tokens is currently in public beta and subject to change.
In the view for an active GitHub token alert, you can review certain metadata about the token. This metadata may help you identify the token and decide what remediation steps to take.
Tokens, like personal access token and other credentials, are considered personal information. For more information about using GitHub tokens, see GitHub's Privacy Statement and Acceptable Use Policies.
Metadata for GitHub tokens is available for active tokens in any repository with secret scanning enabled. If a token has been revoked or its status cannot be validated, metadata will not be available. GitHub auto-revokes GitHub tokens in public repositories, so metadata for GitHub tokens in public repositories is unlikely to be available. The following metadata is available for active GitHub tokens:
Metadata | Description |
---|---|
Secret name | The name given to the GitHub token by its creator |
Secret owner | The GitHub handle of the token's owner |
Created on | Date the token was created |
Expired on | Date the token expired |
Last used on | Date the token was last used |
Access | Whether the token has organization access |
Only people with admin permissions to the repository containing a leaked secret can view security alert details and token metadata for an alert. Enterprise owners can request temporary access to the repository for this purpose. If access is granted, GitHub will notify the owner of the repository containing the leaked secret, report the action in the repository owner and enterprise audit logs, and enable access for 2 hours. For more information, see "Accessing user-owned repositories in your enterprise."
Fixing alerts
Once a secret has been committed to a repository, you should consider the secret compromised. GitHub recommends the following actions for compromised secrets:
- For a compromised GitHub personal access token, delete the compromised token, create a new token, and update any services that use the old token. For more information, see "Managing your personal access tokens."
- If your organization is owned by an enterprise account, identify any actions taken by the compromised token on your enterprise's resources. For more information, see "Identifying audit log events performed by an access token."
- For all other secrets, first verify that the secret committed to GitHub Enterprise Cloud is valid. If so, create a new secret, update any services that use the old secret, and then delete the old secret.
Note
If a secret is detected in a public repository on GitHub.com and the secret also matches a partner pattern, an alert is generated and the potential secret is reported to the service provider. For details of partner patterns, see "Secret scanning patterns."
Closing alerts
Note
Secret scanning doesn't automatically close alerts when the corresponding token has been removed from the repository. You must manually close these alerts in the alert list on GitHub.
-
On GitHub.com, navigate to the main page of the repository.
-
Under the repository name, click Security. If you cannot see the "Security" tab, select the dropdown menu, and then click Security.
-
In the left sidebar, under "Vulnerability alerts", click Secret scanning.
-
Under "Secret scanning", click the alert you want to view.
-
To dismiss an alert, select the "Close as" dropdown menu and click a reason for resolving an alert.
-
Optionally, in the "Comment" field, add a dismissal comment. The dismissal comment will be added to the alert timeline and can be used as justification during auditing and reporting. You can view the history of all dismissed alerts and dismissal comments in the alert timeline. You can also retrieve or set a comment by using the Secret scanning API. The comment is contained in the
resolution_comment
field. For more information, see "REST API endpoints for secret scanning" in the REST API documentation. -
Click Close alert.
Configuring notifications for secret scanning alerts
Notifications are different for incremental scans and historical scans.
Incremental scans
When a new secret is detected, GitHub Enterprise Cloud notifies all users with access to security alerts for the repository according to their notification preferences. These users include:
- Repository administrators
- Security managers
- Users with custom roles with read/write access
- Organization owners and enterprise owners, if they are administrators of repositories where secrets were leaked
Note
Commit authors who've accidentally committed secrets will be notified, regardless of their notification preferences.
You will receive an email notification if:
- You are watching the repository.
- You have enabled notifications for "All Activity", or for custom "Security alerts" on the repository.
- In your notification settings, under "Subscriptions", then under "Watching", you have selected to receive notifications by email.
-
On GitHub.com, navigate to the main page of the repository.
-
To start watching the repository, select Watch.
-
In the dropdown menu, click All Activity. Alternatively, to only subscribe to security alerts, click Custom, then click Security alerts.
-
Navigate to the notification settings for your personal account. These are available at https://github.com/settings/notifications.
-
On your notification settings page, under "Subscriptions", then under "Watching", select the Notify me dropdown.
-
Select "Email" as a notification option, then click Save.
For more information about setting up notification preferences, see "Managing security and analysis settings for your repository" and "Configuring your watch settings for an individual repository."
Historical scans
For historical scans, GitHub Enterprise Cloud notifies the following users:
- Organization owners, enterprise owners, and security managers—whenever a historical scan is complete, even if no secrets are found.
- Repository administrators, security managers, and users with custom roles with read/write access—whenever a historical scan detects a secret, and according to their notification preferences.
We do not notify commit authors.
For more information about setting up notification preferences, see "Managing security and analysis settings for your repository" and "Configuring your watch settings for an individual repository."
Auditing responses to secret scanning alerts
You can audit the actions taken in response to secret scanning alerts using GitHub tools. For more information, see "Auditing security alerts."