Handle a GitHub secret-scanning alert as a credential incident
Confirm the detected credential, revoke it at its issuer and review use before closing the repository alert.
In brief
A secret-scanning alert is a starting point for containment. Deleting the string from the current branch does not make the issued credential unusable, and repository history can retain it.
Revocation at the provider closes the actual access route; code cleanup and alert resolution are separate follow-up tasks.
Confirm the scope of the exposure
Identify the credential type, location and history noted by the alert. Determine what it could access and which legitimate system uses it. If it is a false positive, document why; do not mark it safe solely because the repository is private.
Contain before cosmetic cleanup
Revoke the exposed credential and issue a replacement with only required permissions. Review provider logs or billing for misuse. Put the replacement in the intended secret store, not a new committed configuration file. Coordinate rotation if other services depend on it.
Prevent the same path recurring
Check applicable push protection and repository access. Add secret-bearing local files to appropriate exclusions, but remember exclusions do not remove prior history. A history rewrite can disrupt collaborators and is not a substitute for revocation; plan it separately when justified.
Before you act
Detection coverage and available features depend on repository type and account settings. No scanner recognizes every secret or guarantees that an undetected value is safe.
What to do next
- Inspect the repository Security alert without copying the detected value into messages or tickets.
- Identify the issuer and revoke or rotate the credential through its official controls.
- Review affected use, replace the legitimate configuration securely and resolve the alert with the real action taken.
