A fix pull request can remove a hardcoded secret from your code and point it at a secret store, but it cannot make the leaked value safe. GitHub's guidance is to treat a leaked secret as compromised and revoke it with the provider. The pull request is cleanup, and revocation is the actual fix.
Why deleting the line is not enough
Once a secret has been committed, copies can exist in git history, forks, build logs, caches and anyone's clone. GitHub's remediation guidance states that removing the secret, pushing a new commit, or deleting and recreating the repository does not stop it being exploited.
So a bot that only edits the file leaves you exposed while the dashboard shows a closed finding. That is a bad outcome, and it is the main reason to treat secrets differently from dependency upgrades.
What an automated change can safely do
A fix pull request is useful for the code side of the problem:
- Replace the literal value with a read from an environment variable or secret manager.
- Add the file or pattern to ignore rules where that is appropriate.
- Add a pre-commit or push check so the same mistake is caught earlier.
These changes are low risk for the build in most repositories, but the new variable has to exist in every environment, or the app fails at startup. A reviewer should confirm that.
What a person must do
Follow the order in leaked secret response steps:
- Identify the secret type, owner and where it is used.
- Check whether it is still active and whether anyone used it.
- Revoke it with the provider and issue a replacement.
- Update every service that used the old value, and test them.
- Review provider and platform audit logs for unauthorised use.
- Clean history if practical, and close the alert as revoked.
GitHub lists these steps in a similar order. Notice that the code change is not on the list until late.
A decision table
| Task | Bot can do it | Needs a person |
|---|---|---|
| Move the value into a secret store reference | Yes, with review | Confirm the store has the value |
| Revoke the credential | Usually no | Yes, with the provider |
| Check logs for misuse | Can assist | Yes, judge the results |
| Rewrite git history | Not advised | Yes, with team coordination |
Where Safeguard fits
Safeguard can flag exposed credentials alongside dependency findings, and its policies and gates can block a pull request that introduces one. Fix pull requests stay on manual approval by default, so a person decides each change. You can run a free scan to see what turns up.
Quick check
If the bot removes the secret, can I close the alert?
Only after the credential is revoked and dependent services use the new one. GitHub's guidance is to close it as revoked.
Should secret fixes ever merge automatically?
Keep them on manual approval. The environment must hold the new value before the code change ships.
Sources
Last reviewed: 19 October 2026.
