RSSAmplifier

eshlox · Apr 7, 2026

When a secret leaks: incident response

0
Sign in to vote or save

Przemysław Kołodziejczyk · eshlox

TLDR: Rotate first, investigate second. Every minute the old secret is valid is a minute an attacker can use it. Check Infisical audit log. Scan git history. Document everything.


Secrets will leak eventually. Have a plan.

# 1. Generate new credential in the provider (Stripe, AWS, etc.)

# 2. Update in Infisical

infisical secrets set COMPROMISED_KEY=new-value --env=production

# 3. Revoke the OLD credential in the provider's dashboard

# 4. Restart affected services

infisical run --env=production -- docker compose restart api

Do not investigate first. Rotate first.

First hour: investigate

Check Infisical audit log. Dashboard > Audit Logs > filter by the compromised secret.

Scan git history:

infisical scan

git log --all --oneline -S "leaked-value"

Determine scope. What was the secret? What can it access? Read-only or full admin?

Check downstream. Was the repo public? Were there forks? Was it in a CI log?

Cleanup

If the secret was committed to git:

pip install git-filter-repo

git filter-repo --invert-paths --path path/to/file-with-secret

git push --force-with-lease

For public repos, consider the secret permanently compromised regardless of cleanup.

After every incident

Ask: would the Docker-first architecture have prevented this? Usually yes. If the secret was never on disk, it could not have been committed. Use incidents to close gaps.


Spot something wrong?

Found a typo, a broken link, or something that could be better? I would love to hear from you. Drop me a message and I will fix it.

Read the original on eshlox.net

Comments

Nothing yet. Say the first thing.

    Sign in to join the conversation.