Secret Sprawl Incident Response Playbook for Security Teams

Why secret sprawl needs an incident playbook of its own

Secret sprawl is the steady accumulation of credentials across source repositories, build pipelines, container images, infrastructure-as-code, configuration files, chat history, ticket systems, error logs, and third-party SaaS integrations. Most credentials live where they should. Some do not. When a credential lands in a place outside its authorised trust boundary, that single instance can authenticate a real attacker for as long as the credential remains valid, and the attacker rarely waits for the organisation to notice. Public research from the secrets-detection community shows that leaked credentials on public GitHub are scraped and probed within minutes of being pushed; private repository leaks, internal log leaks, and SaaS-side leaks are slower but operate on the same principle. Treating the leak as a standard finding in the vulnerability backlog underestimates the timing pressure and the blast-radius work.

The general incident response plan guide covers the six NIST phases that wrap every incident. The general secret scanning remediation workflow covers the steady-state operational discipline that runs after each detection hit. This playbook sits between them. It is the per-incident response shape that activates the moment a leak is confirmed, that escalates if blast-radius indicators appear, and that hands off to the steady-state remediation workflow once the immediate path is closed.

Secret leaks span identity domains. A leaked database credential reads as a data risk. A leaked cloud access key reads as an infrastructure risk. A leaked OAuth token on a SaaS platform reads as a third-party access risk. A leaked signing key reads as a supply-chain risk. A leaked CI/CD token reads as a build-pipeline risk. The playbook covers each class with a common skeleton (detect, contain, rotate, revoke, clean, verify, close) and class-specific addenda for the steps that change depending on what the credential authenticates.

Severity classification at first sight

Triage starts the moment the leak is reported, whether the source is a Semgrep secret scan run, a third-party detection vendor, a customer or researcher disclosure, a developer self-report, or a build-log audit. Severity reads against three axes that together set the response shape.

The combined read sets the response timer. A Critical leak (production-mutation credential exposed on a public surface against regulated data) closes containment within minutes, not hours. A High leak (broad-scope internal credential on a private surface) closes within hours, not days. A Medium leak (narrow-scope sandbox credential on a private surface) closes within the working day. Recording the severity classification on the incident record on first sight, with the three axis values explicit, lets the auditor read why the response cadence was chosen rather than inferring it from the timeline.

The seven-step response shape

Every secret-leak incident follows the same seven steps in the same order. Class-specific details vary; the skeleton does not.

1. Detect and confirm. A detection event arrives from a secret-scanning rule, a third-party push notification, a researcher report, a customer ticket, or an internal audit. Confirm the credential is valid (does an authentication attempt succeed against the resource it authenticates to) and confirm the exposure surface is real (is the credential reachable to the party named in the detection).
2. Contain. The credential continues to be exploitable until it is revoked or rotated. Containment is the bridge between detection and rotation. Apply IP restrictions, scope reductions, MFA challenges, session revocations, and rate limits on the identity while the rotation work runs in parallel.
3. Rotate. Mint a new credential. Deploy the new credential to every consumer that uses it. Confirm the new credential is in use end-to-end before invalidating the old one. Rotation order matters: invalidating the old credential before the new one is in use creates an outage that pressures the team to roll back the rotation under time pressure.
4. Revoke. Invalidate the old credential at the identity provider, the cloud IAM control plane, the secret manager, the SaaS platform, or wherever the credential lives. Confirm the revocation is effective by attempting an authentication and receiving a denial. Capture the denial evidence on the incident record.
5. Clean. Remove the credential from the surface where it was exposed. For repositories this means a history rewrite, not only a delete commit; the credential remains in git history without one. For logs this means a retention purge or a redaction at the log aggregation layer. For SaaS this means revoking the OAuth grant and removing stored integration secrets.
6. Verify. Re-run the detection that found the leak and confirm the absence. Run the broader detection set against adjacent surfaces and confirm the credential class is gone. For exposed credentials with potential downstream use, audit the access logs of the resource the credential authenticated to for evidence of attacker activity during the exposure window.
7. Close and review. Close the incident record with the verification evidence attached. Schedule the post-incident review under the broader security incident postmortem and after-action review guide cadence. The review feeds back into the secrets-protection programme so the next leak in the same class is harder to produce.

Class-specific addenda

The seven-step skeleton applies to every leak. The class-specific work varies by what the credential authenticates and where it was exposed.

Repository history cleanup, not just deletion

A delete commit removes the credential from the working tree but leaves it in git history, where every clone, fork, and mirror retains a usable copy. The platform-side and history-side cleanup are two different operations. Delete-commit alone is not cleanup.

Repository cleanup is the second-most-common gap in secret-leak responses after slow-rotation. The defensible procedure runs in this order:

1. Confirm the credential is revoked at source. History rewrites are slow; the credential should already be invalid before the rewrite starts so the attacker window closes regardless of clone state.
2. Run a history rewrite using git filter-repo (or BFG Repo-Cleaner on legacy estates) to remove the credential from every commit in history. The default git filter-branch is now deprecated and should not be used.
3. Force-push the rewritten history. This invalidates every existing clone. Communicate the force-push to active contributors so they re-clone rather than rebase against a stale tree.
4. On GitHub, GitLab, and Bitbucket, request the platform-side garbage collection of the old commit objects through the support flow. Without that step, the old commit objects remain reachable through the API (and through forks) even after the force-push.
5. For every fork of the repository, the fork retains its own copy of the original history. If the repository is public, accept that any credential pushed to a public fork can never be fully retracted; the post-revocation cleanup is necessary but the recovery posture must assume the credential was harvested. Treat the leak as a public-surface credential exposure regardless of how fast the rewrite was.

The repository-history exposure model is covered in more depth on the secrets in version control explainer; the SAST-side detection model that catches secrets at the build-time review boundary is covered on the hardcoded secrets explainer.

Blast-radius review and downstream audit

The rotation closes the path forward. The blast-radius review closes the path backward. Every revoked credential needs an audit of every action the credential could have taken during the exposure window, regardless of whether a specific compromise indicator is present. The defensible posture is to assume the credential was used and to audit for evidence of use, not to assume it was unused and audit only on a triggering signal.

The blast-radius review covers three layers.

• Authentication evidence. Did the credential authenticate during the exposure window from an unexpected origin (IP range, geography, user agent, time-of-day pattern)? Most identity providers and cloud control planes log every authentication with origin metadata.
• Action evidence. What did the credential do during the exposure window? Look for actions inconsistent with the consumer that normally uses the credential (a deploy credential running enumeration queries, an analytics credential running schema modifications, a CI token publishing packages from a non-CI source).
• Data evidence. If the credential reached data, did the consumption pattern change during the exposure window? Look for large reads, bulk extracts, slow recurring scrapes, and unfamiliar query shapes.

When evidence of unauthorised use is found, the incident escalates from a credential leak to a confirmed compromise. The compromise response activates the broader incident response workflow and may trigger the breach notification and regulator readiness workflow depending on what was accessed.

Verification before closure

A closure record without verification evidence is a status change, not a verified close. The verification step needs to produce four artefacts before the incident closes:

• Revocation evidence. An authentication attempt against the old credential fails with the expected denial response. Capture the request and response on the incident record.
• Rotation evidence. The new credential is in use end-to-end. Confirm with an authentication against the new credential that succeeds, and confirm the consumer of the credential is using the new value (not still configured to the old one).
• Cleanup evidence. Re-running the detection that found the leak returns clean. For repository leaks, the leak does not re-surface from the history; for log leaks, the leak does not re-surface from the log aggregator; for SaaS leaks, the OAuth grant is revoked.
• Blast-radius evidence. The audit-log review for the exposure window is complete, with a written conclusion on whether unauthorised activity was detected. A negative finding (no evidence of unauthorised use) is a finding; record it explicitly so the auditor reads the conclusion rather than inferring it.

Verification quality is the difference between a defensible close and a closed ticket. The same discipline that applies to vulnerability fix verification applies here; the vulnerability fix verification fidelity research covers the eight low-fidelity verification patterns that recur across enterprise remediation programmes, several of which apply directly to credential-leak verification (status-change-only closure, self-attestation closure, single-payload replay).

Common failure modes

Eight failure modes recur in secret-leak incident responses across enterprise programmes. Each maps to a specific structural control that prevents the next occurrence.

Framework references

Secret-leak incident response intersects multiple control frameworks. The defensible position is to record the framework references on the incident record so the auditor reads the closure trail against the controls the leak engages.

• ISO 27001:2022 Annex A 5.17 (Authentication Information), 5.26 (Response to Information Security Incidents), 5.27 (Learning from Information Security Incidents), 8.24 (Use of Cryptography), 8.28 (Secure Coding), and 8.29 (Security Testing in Development and Acceptance).
• SOC 2 Trust Services Criteria CC6.1 (Logical Access Controls), CC6.6 (Restricts Logical Access), CC7.1 (Detection of Vulnerabilities), CC7.4 (Incident Response), and CC7.5 (Recovery from Identified Incidents).
• PCI DSS v4.0 Requirements 3.3.2 (Sensitive Authentication Data), 6.3.1 (Identify and Manage Vulnerabilities), 8.3 (Authentication Controls), and 12.10 (Respond Immediately to a Suspected or Confirmed Security Incident).
• NIST SP 800-53 Rev. 5 controls IA-5 (Authenticator Management), IR-4 (Incident Handling), IR-5 (Incident Monitoring), IR-6 (Incident Reporting), and IR-8 (Incident Response Plan).
• NIST CSF 2.0 functions PR.AA (Identity Management and Authentication), DE.CM (Continuous Monitoring), RS.MI (Response Mitigation), and RS.AN (Response Analysis).
• CISA Secure by Design names eliminating long-lived shared credentials as a foundational programme goal, which directly informs the post-incident migration step that takes the same identity from a static credential to a short-lived federated credential.
• DORA Articles 9 (ICT Security Policies) and 11 (Identification, Protection and Prevention) cover the EU financial services expectations around credential-leak handling.
• EU Cyber Resilience Act Articles 13 (Essential Cybersecurity Requirements) and 14 (Reporting Obligations) cover credential management and incident reporting expectations for products with digital elements.

How SecPortal supports the playbook

SecPortal provides the operating record an internal security, AppSec, security engineering, vulnerability management, or GRC team uses to run secret-leak incident response with evidence captured at every step rather than reconstructed from chat history at audit time. The platform does not detect, rotate, revoke, or clean credentials directly; it carries the engagement, finding, evidence, and verification record that the technical response produces.

• Code scanning via Semgrep on connected GitHub, GitLab, and Bitbucket repositories surfaces secret patterns at the build-time review boundary. SAST findings land on the same finding record the incident response operates against, so the detection-to-response handoff stays on one record rather than crossing systems.
• Findings management with CVSS 3.1 scoring, over 300 finding templates, and a unified schema lets a secret-leak incident inherit the same lifecycle and severity calibration as the wider vulnerability backlog while still carrying the per-incident addenda (severity axes, class-specific steps, blast-radius review, verification artefacts).
• Retesting workflows pair the verification step to the original finding rather than opening a new record, so the revocation evidence, rotation evidence, cleanup evidence, and blast-radius evidence attach to the same record the original detection sits on.
• Encrypted credential storage with AES-256-GCM is the workspace scanner credential vault used to authenticate against the scanning targets the workspace owns. It is scoped to scanner credentials and is not a general enterprise secret manager; teams running this playbook should continue to rely on their existing secret manager (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Google Secret Manager, CyberArk Conjur, Akeyless) as the authoritative store for application secrets, with SecPortal holding the incident-response record around the rotation.
• Activity log with CSV export carries every state change with named actor and timestamp, so the auditor reads the incident timeline from the operating record rather than reconstructing it from chat logs and ticket history. The activity log is the audit spine that supports SOC 2 CC7.1 and CC7.4 evidence requests.
• Bulk finding import accepts Nessus, Burp, and CSV inputs. For teams running a dedicated secrets-detection vendor (GitGuardian, TruffleHog, Wiz, Aqua, GitHub Advanced Security secret scanning), the CSV export lands the secret-leak inventory into the same operating record the wider backlog uses.
• Document management holds the per-incident artefacts (severity classification on first sight, runbook walkthrough, revocation evidence, rotation evidence, cleanup evidence, blast-radius audit conclusion, after-action review note) on the engagement record where the audit recall is reproducible.
• AI report generation produces the leadership-read of the secret-leak cadence (number of incidents by class, mean time to revocation, mean time to verified close, percentage with blast-radius evidence) so the secrets-protection programme reports to leadership on durable metrics rather than headline counts.
• Compliance tracking against 21 framework templates carries the finding-to-control mapping, so the incident closure record reads against ISO 27001 A.5.17, A.5.26, A.5.27, SOC 2 CC6.1, CC7.4, PCI DSS 12.10, NIST SP 800-53 IR-4, and NIST CSF 2.0 RS.MI from one record.
• Team management with RBAC and MFA enforcement keep the response-team workspace itself defensible. A secrets-protection programme that operates inside an unauthenticated workspace inherits the workspace risk.

SecPortal does not push to ticketing systems (no packaged Jira, ServiceNow, or PagerDuty connectors), does not run an autonomous secret-rotation engine, does not enumerate cloud IAM identities or SaaS OAuth grants, does not provide a built-in secret manager, and does not classify regulator notification obligations. The platform keeps the operating record so the technical response (which lives in the cloud control plane, the secret manager, the identity provider, the SaaS platform, and the build system) produces a defensible audit trail on one record rather than dissolving at the seams between tools.

From one-off response to a defensible secrets-protection programme

The first leak gets handled. The second leak in the same class indicates a structural gap. The post-incident review is the bridge between one-off response and a secrets-protection programme that reduces the standing population of long-lived, broadly-scoped credentials over time.

Three programme-level actions reduce the recurrence rate.

• Identity-design changes. Replace long-lived static credentials with short-lived federated identities (Workload Identity Federation, OIDC tokens for CI/CD, STS-assumed roles, GitHub Apps over PATs, scoped GitHub Actions OIDC). The next leak in the same class no longer reproduces because the credential class has shrunk. The wider non-human identity (NHI) operating model is covered on the Non-Human Identity (NHI) security guide.
• Detection coverage expansion. The secret-scanning rule set has to grow to catch the credential classes that produced recent leaks. Coverage gaps are the upstream cause of late detection; the scanner coverage gap analysis discipline names the gap before the next leak does.
• Workflow consolidation. The steady-state secret scanning remediation workflow handles the detection-to-rotation lifecycle for every non-incident finding. This playbook handles the per-incident response for findings that escalate. Both feed the same operating record, so the secrets-protection programme reads as one programme rather than as two parallel disciplines.

Conclusion

A leaked credential is a live attack path with a stopwatch attached. The defensible response classifies severity on first sight, runs the seven-step skeleton (detect, contain, rotate, revoke, clean, verify, close), applies the class-specific addenda, rewrites repository history rather than only deleting, runs the blast-radius review regardless of indicators, captures verification evidence on the closure record, and feeds the post-incident review back into the secrets-protection programme. The teams that win this discipline treat secret leaks as incidents with a structured response shape, not as backlog items, and they hold every leak to a closure record that an auditor can read against the controls the leak engages. SecPortal is the operating record that keeps the closure trail durable; the technical response runs in your identity stack, your secret manager, and your build pipeline, and the operating record keeps them aligned.

Related reading

• Incident response plan guide covers the six NIST phases that wrap every incident, including the secret-leak class.
• Security incident postmortem and after-action review guide covers the post-incident discipline that turns one closed leak into one fewer leak class in the future.
• Non-Human Identity (NHI) security guide covers the standing inventory, classification, and governance discipline that pairs with this playbook so the next leak is harder to produce.
• NIST SSDF implementation guide covers the federal secure-development reference model that includes secrets-protection practices PS.3 and PW.5.
• Secret scanning remediation workflow covers the steady-state operational workflow that runs after each detection hit, with this playbook handling the per-incident escalation shape.
• Breach notification and regulator readiness workflow covers the parallel track that activates when a leak reaches regulated data.
• Hardcoded secrets explainer and secrets in version control explainer cover the build-time SAST view and the repository-history exposure view of the underlying vulnerability class.
• Vulnerability fix verification fidelity research covers the eight low-fidelity verification patterns that apply directly to credential-leak verification.
• For security engineering teams covers the buyer view from the security engineering perspective, who typically own the platform-side rotation and revocation coordination during a secret leak.