Exposed Credentials in Git: 90-Minute Incident Response Playbook

Your single priority: kill the credential.

Do not stop to investigate whether the key was actually used. Do not wait for management approval. Do not scrub history first. Revoke immediately.

AWS IAM keys

1. Go to IAM > Users > [user] > Security credentials
2. Find the exposed access key and click Deactivate (not Delete yet -- deactivate first to confirm nothing breaks)
3. Wait 5 minutes; if no production alerts fire, click Delete
4. Create a new key pair for the legitimate service that was using it

Or via CLI if you have credentials available:

aws iam update-access-key \
  --access-key-id AKIA... \
  --status Inactive \
  --user-name [username]

GitHub personal access tokens / GitHub Actions secrets

1. Settings > Developer settings > Personal access tokens > Revoke
2. For organization tokens: Settings > Developer settings > GitHub Apps / OAuth Apps
3. For Actions secrets: The secret itself is not the token -- find the underlying service credential and revoke that

Generic API keys (Stripe, Twilio, SendGrid, etc.)

Every major SaaS API has a key revocation path in their dashboard. Go directly to the provider's dashboard, not through your own UI. Most providers have a "Roll API key" option that revokes and reissues in one step.

Database passwords

-- PostgreSQL
ALTER USER app_user WITH PASSWORD 'new_strong_password';

-- MySQL
ALTER USER 'app_user'@'%' IDENTIFIED BY 'new_strong_password';

-- SQL Server
ALTER LOGIN app_user WITH PASSWORD = 'new_strong_password';

Update the secret in your secrets manager (Vault, AWS Secrets Manager, Azure Key Vault) and trigger a deployment to pick up the new credential. Do not manually update application config files.

With the credential revoked, you now have time to understand what happened and whether the attacker did anything with it.

Check cloud provider access logs immediately

AWS CloudTrail -- query for the exposed access key ID:

# Find all API calls made by the exposed key in the last 30 days
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIA... \
  --start-time $(date -v-30d +%Y-%m-%dT%H:%M:%SZ) \
  --query 'Events[*].{Time:EventTime,Event:EventName,Region:CloudTrailEvent}'

Key things to look for in CloudTrail:

• CreateUser, CreateRole, AttachUserPolicy -- attacker creating persistence
• GetSecretValue -- accessing other secrets
• RunInstances, CreateKeyPair -- spinning up infrastructure for cryptomining or C2
• S3:GetObject on buckets you did not know the key had access to
• API calls from unusual geographic regions or IP addresses

GCP Cloud Audit Logs

gcloud logging read \
  'protoPayload.authenticationInfo.principalEmail="[service-account]"' \
  --freshness=30d \
  --format=json | jq '.[] | {time: .timestamp, method: .protoPayload.methodName, ip: .protoPayload.requestMetadata.callerIp}'

Azure Monitor / Entra ID Sign-in Logs

Search the sign-in logs for the service principal or application that owned the exposed credential. Look for sign-ins from unfamiliar IPs or countries.

GitHub audit log (for GitHub tokens):

# If you have GitHub Enterprise or GitHub.com org audit log access
gh api /orgs/{org}/audit-log \
  --jq '.[] | select(.actor == "[username]") | {action: .action, created_at: .created_at, ip: ."@ip"}'

What to document during assessment

Answer these questions before your incident report:

• When was the commit made that introduced the credential?
• When was the repository made public (if it was previously private)?
• How long was the credential exposed and accessible?
• Was the credential actually used by an attacker? (Check access logs for unexpected IPs, times, or API calls)
• What resources did the credential have access to? (IAM policy, OAuth scopes, database permissions)
• Is there any evidence of data exfiltration? (S3 GetObject on sensitive buckets, large data transfers)
• Who else may have seen the credential? (Check the repo star/fork history; if it was forked, assume it was harvested)

Once the credential is revoked and the blast radius is understood, clean the repository. Note: this step is for compliance and to prevent the credential from being used by someone who cached the repo history -- it does NOT eliminate risk for any attacker who already cloned the repo.

Step 1: Delete the file or commit (simple case)

If the secret was added in the most recent commit:

# Remove the secret from the latest commit
git rm --cached [file-with-secret]
echo "[file-with-secret]" >> .gitignore
git add .gitignore
git commit --amend --no-edit
git push --force-with-lease origin [branch]

Step 2: Remove from full git history (BFG Repo Cleaner -- recommended)

BFG is faster and simpler than git filter-branch:

# Install BFG
brew install bfg

# Create a text file with the secret value (one per line)
echo 'AKIA...' > secrets.txt
echo 'actual-secret-value-here' >> secrets.txt

# Run BFG on a mirror clone of the repo
git clone --mirror https://github.com/org/repo.git
bfg --replace-text secrets.txt repo.git

# Clean and push
cd repo.git
git reflog expire --expire=now --all && git gc --prune=now --aggressive
git push --force

Step 3: Invalidate GitHub's cache

Even after force-pushing, GitHub caches commit history. Contact GitHub support to flush the cache for the specific commits, or make the repository private temporarily to limit exposure while the cache expires.

Step 4: Check for forks

Anyone who forked the repository before you cleaned it has the full history. Use the GitHub API to list all forks:

gh api /repos/{owner}/{repo}/forks --jq '.[].full_name'

If the repo has forks, assume the secret is permanently harvested. The cleanup is still worth doing to prevent casual discovery, but treat it as a compromised credential regardless of the history scrub.

Internal notification template

Send to your security team, engineering leadership, and legal/compliance within 90 minutes of detection:

Subject: [SECURITY INCIDENT] Exposed Credential - [Service/Key Type] - RESOLVED

Summary:
A [AWS IAM key / API token / database credential] was found in a public 
GitHub repository. The credential has been revoked as of [TIME UTC].

Timeline:
- [DATE TIME]: Credential committed to repository [URL] by [user/commit]
- [DATE TIME]: Repository made public (if applicable)
- [DATE TIME]: Exposure detected via [method]
- [DATE TIME]: Credential revoked
- [DATE TIME]: New credential issued and deployed

Blast Radius:
- Credential type: [type]
- Resources in scope: [IAM policy / API scopes / database access]
- Evidence of attacker use: [Yes/No -- detail if yes]
- Data potentially exposed: [description or None identified]

Immediate Actions Taken:
1. Credential revoked at [TIME]
2. New credential issued and deployed at [TIME]
3. Git history cleaned (in progress / complete)
4. Access logs reviewed -- [findings]

Next Steps:
- [Pre-commit hook / secret scanning enforcement deployment by DATE]
- [Incident review meeting: DATE/TIME]
- [Customer/regulator notification if required: DATE]

Severity: [Low/Medium/High based on blast radius assessment]
Incident Commander: [Name]

When to notify customers or regulators

• If CloudTrail/audit logs show the credential was used to access customer data: notify affected customers and assess regulatory notification requirements
• GDPR: 72-hour clock to supervisory authority if personal data was accessed
• HIPAA: 60-day notification requirement if PHI was accessed
• If no evidence of attacker use and the blast radius is limited to internal infrastructure: internal notification only is typically sufficient
• Always loop in legal before external notifications

Pre-commit secret scanning (prevent at the source)

git-secrets (AWS) or detect-secrets (Yelp) run at commit time:

# Install detect-secrets
pip install detect-secrets

# Initialize baseline (scan existing codebase)
detect-secrets scan > .secrets.baseline

# Add pre-commit hook
cat > .git/hooks/pre-commit << 'EOF'
#!/bin/bash
detect-secrets-hook --baseline .secrets.baseline
EOF
chmod +x .git/hooks/pre-commit

For team-wide enforcement, use pre-commit framework:

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/Yelp/detect-secrets
    rev: v1.5.0
    hooks:
      - id: detect-secrets
        args: ['--baseline', '.secrets.baseline']

GitHub push protection (prevent before the push reaches GitHub)

Enable in GitHub Advanced Security settings. Blocks pushes containing known secret patterns before they reach the repository. Free for public repositories, requires GitHub Advanced Security for private repos.

Repository-level secret scanning

• GitHub secret scanning: Settings > Security > Secret scanning (free for public repos, included in GHAS for private)
• GitGuardian: monitors all commits across your organization in real time, sends alerts within seconds
• Gitleaks: open-source option that runs in CI/CD

# GitHub Actions: run Gitleaks on every PR
jobs:
  gitleaks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Move secrets to environment variables and a secrets manager

No secret should ever live in source code. The architecture:

1. Secrets stored in AWS Secrets Manager, HashiCorp Vault, or Azure Key Vault
2. Applications fetch secrets at runtime via the SDK, not from environment config files
3. CI/CD secrets live in the pipeline's secret store (GitHub Actions Secrets, GitLab CI Variables), not in .env files committed to the repo
4. Local development uses .env.local files that are in .gitignore and never committed