Secret rotation

MopokeHQ raised a P1 because a credential is in a repository. Treat it as leaked: anyone who can read the repository, its history, a fork, a clone or a CI log can use it. Deleting it from the code does not change that, which is why MopokeHQ keeps the finding open until someone marks it rotated.

The finding shows what MopokeHQ knows without ever holding the value: the file and line, Added by (the commit that added it, linked), Variable (the name it sits in, and the files that use that name), and Lilly’s note on what the credential most likely is and what someone holding it could do. Use them to find where the credential is used before you change it.

Do these in order. Rotating and revoking come first, because the copy in history can’t be fully recalled.

1. Rotate

Issue a new credential at the provider (cloud console, API dashboard, database, SSH key pair) and deploy it everywhere the old one is used. The Variable files are a good list to start from. Put the new one in a secret store or a masked CI/CD variable, never in the repository.

2. Revoke

Delete or disable the old credential at the provider, so the committed copy stops working. Check nothing still depends on it (a forgotten cron job, a second environment) before you call it done.

3. Check the logs

Look at the provider’s access logs for the old credential from the day it was committed (the finding’s Found date, or the Added by commit’s date if earlier) until you revoked it: sign-ins, API calls, source addresses and actions you don’t recognise.

If you find use you can’t account for, stop treating this as routine clean-up. It is a possible security incident, and if personal information was reachable it may be a notifiable data breach under the privacy law that applies to you (in Australia, the Notifiable Data Breaches scheme). Escalate it to whoever owns incidents in your organisation.

4. Purge it from history

Remove the secret from the repository’s history so new clones don’t carry it, for example with git filter-repo:

git filter-repo --replace-text <(echo 'THE-OLD-SECRET==>REMOVED') --force
git push --force --all && git push --force --tags

Then:

• ask everyone with a clone to clone again (an old clone would push the secret back);
• clear it from places history doesn’t reach: merge request and pull request diffs, CI job logs and artifacts, forks, caches, and container images built from the repository;
• on GitLab, a maintainer can run a repository cleanup after the rewrite (Settings, Repository, Repository cleanup) to drop the old objects from the server;
• on GitHub, old commits can stay reachable through pull requests and cached views after a rewrite; GitHub’s guide to removing sensitive data covers asking its support to purge them.

Purging is clean-up, not a fix: the rotation and revocation above are what make the leaked copy useless.

5. Close the finding

On the Issues page, open the finding and choose Mark rotated. It records who did it and when in the evidence log.

If it was not a real secret (a test value, an example, a false match), choose Not a real secret with a reason instead, so it doesn’t come back.

Keep it from happening again

• Keep credentials in your CI/CD settings, a secret store, or .env files that .gitignore excludes.
• Run gitleaks as a pre-commit hook on developer machines, so a secret is caught before it is pushed.
• Let the merge gate fail a merge request that adds a secret: set the project’s gate to Enforce and the CI variable MOPOKE_GATE to enforce. The new_secret rule fails by default.