Gitleaks Detected a Secret: How to Fix It Safely

When Gitleaks flags a secret, the worst response is to blindly delete one line and move on. A leaked credential may already be exposed in commit history, CI logs, pull request diffs, forks, caches, or package artifacts. The safe fix is a sequence: confirm the finding, rotate the credential, remove the exposure, decide whether history rewrite is required, then add prevention so the same class of leak does not return.

Quick triage checklist

1. Confirm the finding. Check whether it is a real credential, a test fixture, a placeholder, or a false positive. Never paste the value into external websites to test it.
2. Assume exposure if it reached a remote repository. If the commit was pushed, treat the secret as compromised.
3. Rotate first. Revoke or rotate the key before spending time on code cleanup.
4. Remove from source. Replace the literal secret with environment variables, a local secret manager, or CI secret storage.
5. Check history and logs. Decide whether you need a history rewrite, branch protection update, or CI log purge.
6. Add prevention. Use pre-commit hooks, CI scanning, and safer config examples.

Step 1: confirm without spreading the secret

Open the Gitleaks report locally and identify the file, line, rule, and commit. Do not copy the secret into chat tools, public issue trackers, online validators, or screenshots. If the value is a real token format and came from a real config file, treat it as sensitive even if you are not sure whether it is active.

gitleaks detect --source . --redact --report-format json --report-path gitleaks-report.json

Step 2: rotate before cleanup

Deleting the line does not invalidate the credential. Go to the provider dashboard and revoke or rotate the token. For cloud credentials, also check recent activity. For GitHub tokens, check token scopes and audit logs. For payment, email, analytics, or deployment tokens, assume an attacker could have used the credential as soon as it was pushed.

Step 3: replace the secret with safe configuration

# .env.example
API_TOKEN=replace-with-local-secret

# application code
const token = process.env.API_TOKEN;
if (!token) throw new Error('API_TOKEN is required');

Commit `.env.example`, not `.env`. Add or verify `.gitignore` entries for `.env`, private keys, certificates, and local secret directories.

Step 4: decide whether history rewrite is needed

If the secret was pushed to a private repository and rotated immediately, rewriting history may not be necessary. If it was pushed to a public repository, package, fork, or long-lived shared branch, consider history cleanup with a careful communication plan.

What not to do

• Do not simply rename the variable and keep the same value.
• Do not post the unredacted finding in Slack, GitHub Issues, or a ticket system.
• Do not rely only on history rewrite; rotate the credential first.
• Do not mark a finding as false positive just because the app still works.

Minimal incident record

Write down when the secret was introduced, whether it was pushed, whether it was public, who rotated it, where the replacement is stored, and what prevention was added.

Related CodeRiskTools resources

• AI Code Security hub
• Free 5-point AI code review checklist
• CodeRiskTools product library — optional paid kits if you want templates and local checklists.
• Compare SAST tools
• Expert AI Code Security Audit — professional deep review for teams.

Note: This article is educational and designed for local/security-conscious workflows. Do not paste private source code or secrets into third-party tools.

Gitleaks remediation workflow for small teams

A useful Gitleaks response is not just a scanner cleanup task. It is a small incident workflow. The team should answer three questions: was the credential real, was it exposed outside the local machine, and what control prevents the same mistake next week?

1. Separate test data from real credentials

Some findings are examples, fixtures, or intentionally fake values. Still, do not assume that because a string is in a test file. Check the surrounding file name, variable name, provider format, and commit history. If a value follows a real provider format and appears in runtime configuration, treat it as real until proven otherwise.

2. Rotate before discussing the diff

Rotation is the safest first action because cleanup does not invalidate an exposed key. For GitHub, cloud, deployment, analytics, payment, email, and CI tokens, revoke the old value and create a replacement with the narrowest scope. If the token had write access, check recent activity before closing the incident.

3. Replace secrets with boring configuration

The best fix is simple and repeatable: store real values outside Git, document placeholders in `.env.example`, and make the application fail clearly when required environment variables are missing. Avoid clever fallback credentials, demo tokens, or sample keys that look real.

4. Review AI-generated config changes carefully

AI coding tools often create complete-looking setup files. That can include example tokens, fake API keys, or copied values from a prompt. When an AI agent touches `.env`, CI variables, Docker Compose, deployment YAML, or README setup instructions, run a secret scan before the merge.

Gitleaks prevention checklist

• Run Gitleaks locally before pushing large config changes.
• Run Gitleaks in CI for every pull request.
• Keep `.env.example` realistic but secret-free.
• Use provider-side push protection when available.
• Never paste live secrets into AI prompts, screenshots, tickets, or public issue comments.
• Document suppressions and false positives so the scanner remains trusted.

FAQ: Gitleaks detected a secret

Can I just delete the leaked line?

No. Deleting the line removes the current exposure from the file, but it does not revoke the credential and may not remove it from Git history, CI logs, forks, or cached artifacts.

Do I always need to rewrite Git history?

Not always. If the secret never left a local branch and was rotated, a history rewrite may be unnecessary. If it reached a public repository or shared remote, consider a careful history cleanup plan after rotation.

Should I mark test credentials as false positives?

Only if they are clearly non-functional and documented as safe. If the value could authenticate anywhere, rotate it and replace it with a safer fixture.