Resolving alerts from secret scanning

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:

1. Verify that the secret committed to GitHub is valid. Applies to GitHub tokens only. See Checking a secret's validity and Performing an on-demand validity check.
2. For secrets detected in private repositories, report the leaked secret to GitHub, who will treat it like any publicly leaked secret and revoke it. Applies to active or unconfirmed GitHub personal access tokens only. See Reporting a leaked secret in a private repository.
3. Review and update any services that use the old token. For GitHub personal access tokens, delete the compromised token and create a new token. See Managing your personal access tokens.
4. Depending on the secret provider, check your security logs for any unauthorized activity.

Fixing alerts for secrets in GitHub Actions workflow logs

When a secret is detected in a GitHub Actions workflow log, follow these steps in order.

1. Review the alert and linked job log to identify the credential and the source of the exposure. The secret may have been printed by the workflow, an action, or another dependency.
2. Check whether the credential is still valid. See Checking a secret's validity. If the credential is active or you cannot confirm its status, rotate or revoke it immediately using the secret provider's dashboard.
3. Fix the source of the exposure. For example, update the workflow or dependency, remove hardcoded secrets, or store credentials as encrypted secrets. See Using secrets in GitHub Actions.
4. If necessary, add ::add-mask::<value> to redact the value from future log output.

Reporting a leaked secret in a private repository

1. On GitHub, navigate to the main page of the repository.

2. Under the repository name, click the Security and quality tab. If you cannot see the " Security and quality" tab, select the dropdown menu, and then click Security and quality.

3. In the left sidebar, under "Vulnerability alerts", click Secret scanning.

4. From the alert list, click the alert you want to view.

5. In the alert view for the leaked secret, click Report leak.

   Note

   In order to prevent breaking workflows, consider first rotating the secret before continuing, as disclosing it could lead to the secret being revoked. If possible, you should also reach out to the token owner to let them know about the leak and coordinate a remediation plan.

6. Review the information in the dialog box, then click I understand the consequence, report this secret.

Closing alerts

If a branch ruleset requires secret scanning alerts to be resolved, an open alert introduced by a pull request can block merging. After fixing the exposed secret, close the alert using the following steps. After all blocking alerts are closed, the alerts no longer prevent merging. The rule can continue to block merging until a secret scanning scan completes for the pull request's head commit.

1. On GitHub, navigate to the main page of the repository.

2. Under the repository name, click the Security and quality tab. If you cannot see the " Security and quality" tab, select the dropdown menu, and then click Security and quality.

3. In the left sidebar, under "Vulnerability alerts", click Secret scanning.

4. Under "Secret scanning", click the alert you want to view.

5. To dismiss an alert, select the "Close as" dropdown menu and click a reason for resolving an alert.

   

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

7. Click Close alert.

Next steps

• Monitoring alerts from secret scanning