Secret scanning before and after a Git push
A key caught before push can be removed from the change. A key found afterward needs issuer-side revocation or rotation, even if the commit is deleted.
On this page(4)
“Shift left” means checking a change before it reaches a shared repository. It can reduce one path of exposure, but it cannot prove that a key was never copied elsewhere. The useful distinction is when the key was found: before or after the push.
Before push: keep the value out of history
Run a local scanner such as Gitleaks against the intended change, or enable the repository provider’s push protection for supported secret patterns. Review which files, commits and patterns the check covers. A skipped file, an unsupported pattern or an allowed bypass can still leave a key in the change.
If a test value triggers the check, remove it from the change and replace the credential with the project’s approved secret delivery method. Then rerun the check. Do not paste the key into a pull request comment or a support ticket to explain the finding.
After push: treat the key as exposed
A key committed to a shared or public repository may remain in history, forks, clones or other copies after the current file is fixed. Identify the issuer and affected account, then revoke or rotate the key there. Test dependent workloads and review relevant activity. GitHub recommends revocation or rotation before considering a history rewrite; rewriting history has operational costs and cannot erase every copy.
Record the finding location, owner, issuer-side action and known copies without storing the secret value in the incident record. Remove accessible copies where practical after containment. A successful repository cleanup is not evidence that the old key has stopped working.
Where Cremit fits
Cremit scans supported connected sources for credential patterns. For supported credential types it can check validity at the issuer; AWS and GCP integrations can add access context. A configured GitHub App can report findings in a pull request. These checks depend on the connected source, permissions and configuration. Cremit is not a local pre-commit hook, and connecting a repository does not make every push protection or CI check run.
For a team, track three concrete things: which sources and changes were checked, how long an identified live key remained active after discovery, and whether copies or dependent workloads still need attention. Avoid treating a clean scan as proof that no credential exists.
Related guide
CI/CD pipeline: code, build logs and published images
GitHub: removing sensitive data from a repository
Read next
Secret scanning false positives: how to triage findings
A pattern match, a revoked key, and an unverified key need different responses. Learn how to separate them and prioritize exposed credentials.
From exposed credentials to Cremit Platform: the workflow we support
How Cremit Platform finds exposed credentials, verifies supported types, and routes findings to an owner, with clear limits.
Eight credential exposure patterns and how to respond
A practical summary of eight NHI credential exposure patterns, the evidence to check, and what Cremit Platform can help investigate.
Get the next one in your inbox
Monthly NHI security brief from Cremit. One email, high signal.