Identify the credential owner, scope and repository access. Preserve enough incident information to review usage without spreading the secret further.

1. Revoke or rotate the exposed credential promptly through its issuing service. Update authorised consumers with a replacement and verify their operation.

2. Review provider audit records for unexpected use. Consider whether logs, CI artifacts, forks or release archives also contain the value.

3. Remove the secret from active files and replace it with protected runtime configuration. Add a safe example template where developers need the variable name.

4. When history cleanup is necessary, follow the Git host’s supported sensitive-data removal process and coordinate with collaborators before rewriting shared history.

5. Check remaining copies and enable appropriate secret detection or review controls. Document the incident without including the secret itself.

Confirm the old credential no longer works and the replacement has the intended narrow permissions. Verify new commits and build artifacts no longer contain the value.

Rotate or revoke the exposed credential through the issuing service first. Deleting the line from the current branch does not invalidate a key someone may already have copied.

Identify where the credential was used, update legitimate applications through approved secret storage and verify that the replacement works. Review relevant provider logs for unexpected use, with an authorised incident owner deciding the response.

Why does removing the file not finish the cleanup?

Repository history, forks, pull requests, build logs and distributed copies may retain the old value. Follow the repository provider's documented sensitive-data removal procedure and coordinate with collaborators before rewriting history. Do not assume you can erase every copy.

Add controls to prevent recurrence, such as reviewing ignored environment files and using supported secret scanning. Keep a harmless configuration example that names required variables without including real credentials. When you contact our team about hosting access affected by the incident, identify the exposed credential type and rotation status. Never paste the live secret into the ticket to prove that it was exposed.

History rewriting can disrupt clones and does not guarantee deletion from every fork or cached copy. Revocation remains essential even after a successful repository cleanup.

• Protecting production secrets in CI jobs
• Rotating an application secret without breaking active traffic
• Keeping browser bundles free of private API credentials
• Giving a deployment server read-only Git repository access

• GitHub sensitive-data removal