Secrets Scanner Compromise Playbook

A compromised secrets scanner hands the attacker a curated, validated list of your leaked credentials, read access to most of your source code, and often a foothold inside the CI pipelines it runs in. The scanner's whole job is to find secrets, so its findings store is effectively a map of which keys exist, where they live and, if validity checks are on, which ones still work. The incident can start with a stolen admin login, a leaked scanner API token, a malicious rule or plugin update, a poisoned CI step that runs the scanner, or a breach of the vendor's hosted service. This playbook covers how to contain the scanner, decide which secrets to treat as exposed, rotate them in a sensible order, and rebuild the scanner with narrower trust. It is vendor-neutral and written for application security engineers, platform teams and incident responders. Hardening before an incident is covered in Securing the secrets scanning tool itself.

Key takeaways

Every finding is now an exposed secret. Open, dismissed, allowlisted and "false positive" findings all count, because the attacker can read them and decide for themselves.
Active secrets come first. Validity status, where the scanner recorded it, tells you which credentials an attacker could use today; rotate those before anything else.
The scanner's own access is broad. Organisation-wide repository read tokens, app installations, CI credentials and ticketing or chat webhooks all need revocation.
CI integrations widen the blast radius. A scanner step running in a pipeline can see that pipeline's environment variables, so a tampered scanner binary or action can harvest them.
Rule and allowlist changes are a hiding place. An attacker who can edit rules or suppressions can stop new leaks being reported, so restore detection from a reviewed baseline.

What the scanner holds and why it matters

Scanners differ, but most hold some combination of the items below. Knowing which apply to yours sets the size of the response.

Asset	Why it matters in a compromise
Findings store (secret type, location, commit, author, sometimes the value or a partial value)	A ready target list; even without the full value, the location lets an attacker fetch it from the repository
Validity check results	Tells the attacker which credentials are live. Some platforms check validity by contacting the issuing service, so the scanner holds a way to test credentials
Repository read tokens or app installations across the organisation	Read access to source code, full git history, and often issues, pull requests and wikis, which some scanners also cover (T1213 Data from Information Repositories)
CI pipeline step, action or container image	Runs inside builds with access to pipeline secrets (T1552.001 Credentials In Files and environment exposure)
Pre-commit hooks and IDE plugins on developer machines	Code running on workstations with developer credentials
Rules, custom patterns, allowlists and dismissals	Control over what is reported and what is silently ignored
Integrations: ticketing, chat, SIEM, secrets manager	Webhook secrets and, in some setups, rights to trigger rotation in the secrets manager

How the compromise shows up

Unexpected exports or API reads of findings: bulk downloads in the scanner's audit log, or API calls from unknown addresses.
Use of leaked secrets that were never public: a credential found only by the scanner, in a private repository, being used from an unknown source is a strong signal.
Rule, allowlist or dismissal changes nobody made: bulk dismissals, new path exclusions, or disabled detectors, in line with T1685 Disable or Modify Tools.
Repository activity by the scanner's identity: clones of repositories outside its normal schedule, or any write action from an identity that should be read only.
Changed scanner binaries, actions or images: a checksum or digest that no longer matches the published release, or a CI step pinned to a moving tag that changed.
Outbound connections from build runners: the scanner step calling hosts other than the vendor's documented endpoints.
A vendor notice: a security advisory asking customers to rotate tokens or credentials.

Triage: the first hour

Where did it start? Your scanner tenant or server, a token, the CI integration, a developer-side component, or the vendor's service.
Does the findings store hold full secret values? If yes, treat every finding as disclosed. If it holds only locations, treat every secret still present in a reachable repository as disclosed.
Which findings were validated as active? Export the list with validity status and the time it was last checked.
What repositories and pipelines could the scanner reach? List organisations, projects, app installations and CI systems with the identity used for each.
Could the attacker change code or pipeline content? Any write scope, or a tampered scanner step, turns this into a CI/CD incident; run the CI/CD Pipeline Compromise Playbook alongside this one.
Is it ongoing? Recent token use or exports from unknown sources mean containment starts before the investigation finishes.

Containment by priority

Revoke the scanner's access to code. Suspend or uninstall its repository app installations, revoke its tokens and deploy keys. Some git hosting platforms also let organisation owners revoke SSO authorisations for tokens, which cuts access quickly.
Remove the scanner from pipelines. Disable or skip the scanner step in CI, and pin any remaining third-party steps to a known good commit or digest until the investigation clears them.
Lock the tenant or server. Disable compromised admins, revoke API tokens, remove unknown SSO or integration changes; isolate a self-hosted server for imaging.
Cut integrations. Rotate ticketing, chat and SIEM webhook secrets, and remove any rights the scanner had to trigger rotation or read from a secrets manager.
Start rotating active secrets. Begin with the validated-active list while the rest of containment proceeds; see the next section.
Keep some detection running. Use the git hosting platform's native scanning or a separate, clean scanner on high-risk repositories so new leaks during the incident are not missed.

Rollback: record every installation, token and pipeline change you made with its previous state, so scanning can be restored deliberately.

Credential rotation: what and in what order

OWASP's Secrets Management Cheat Sheet sets the response order for exposed secrets as revocation, rotation, deletion from exposed systems, and logging of the secret's history. Apply it to every secret the scanner knew about, in this priority order.

Priority	Secrets	Action
1	Findings marked active or possibly active, especially cloud keys, CI tokens and production database credentials	Revoke immediately, issue replacements, review the provider's logs for use since the finding was created
2	The scanner's own credentials: repository tokens and app keys, CI credentials, API tokens, integration webhooks	Revoke and reissue with the narrowest scopes
3	Secrets in pipelines where the scanner step ran during the window	Rotate every secret available to those pipelines, not only the ones found
4	Dismissed, allowlisted and "test" findings	Verify each is truly inert; rotate any that are real
5	Findings marked inactive	Confirm no unauthorised use happened before they became inactive
6	Secrets on developer machines where hooks or plugins ran	Rotate developer tokens and keys if the client-side components were tampered with

Rotation alone is not enough: delete the old values from code and logs as well, and accept that rewriting git history has side effects. See How to Remove Secrets From Git History and Credential Rotation at Scale for large rotation programmes. For cloud keys, the Cloud Access Key Leak Playbook covers provider-side checks.

Developer-side components

Pre-commit hooks, IDE plugins and command line scanners run on developer workstations with the developer's own git, cloud and package registry credentials. If the incident involved a tampered release of any of these, the response widens from the scanner to every machine that installed it.

Component	How to find affected machines	Response
Pre-commit hook pinned by version in a repository config	Search repositories for the hook reference and the affected versions	Pin to a verified commit; ask owners of affected machines to reinstall
IDE plugin from a marketplace	Endpoint management or EDR software inventory	Remove or update the plugin; rotate tokens held by those developers
Command line binary installed by package manager or download	Software inventory and package manager records	Reinstall from a verified checksum; check for unexpected outbound connections

If a tampered component ran with developer credentials, follow the Compromised Developer Workstation Playbook for each affected machine.

Where identity fits

A secrets scanner is itself a non-human identity with some of the widest read access in engineering: often every repository in every organisation. Its tokens are frequently long-lived and owned by a person who has since changed role. The response is a chance to replace them with short-lived, app-based credentials scoped to the repositories that need scanning, and to make sure the scanner cannot write. See the Service Account Security Guide.

Eradication and rebuild

Rebuild self-hosted scanners from a clean image and a verified release; do not restore the findings database from a backup taken in the window without reviewing it.
Verify every scanner artefact used in CI and on workstations: binaries by checksum against the publisher, container images by digest, CI actions by commit SHA.
Restore rules from a reviewed baseline: compare rules, custom patterns, path exclusions and allowlists with the last approved version and remove anything added in the window.
Re-open suspicious dismissals: any finding dismissed during the window goes back to open for review.
Hunt in repositories: look for new deploy keys, webhooks, app installations and pushes made with the scanner's identity, and for changes to pipeline definitions.
Check the secrets manager: if the scanner could trigger rotation or read secrets, review that system's audit log for the window.

Recovery and reconnection

Reconnect one organisation or project with a new read-only app installation or token, scoped to selected repositories.
Run a full history scan and compare findings with the pre-incident export; new findings may be secrets the attacker introduced, or secrets the attacker's rule changes had hidden.
Re-add CI steps pinned to a commit SHA or image digest, with only the secrets the step needs.
Restore integrations with new webhook secrets and tokens; do not restore automatic rotation rights until reviewed.
Expand in rings to remaining organisations once the scan pattern and audit logs look normal.

Evidence to preserve and notification

Scanner records: audit log, export and API access history, rule and allowlist change history, findings with validity status.
Git hosting logs: audit log entries for the scanner's app or token, clones, and installation changes.
CI records: job logs, runner images and the exact scanner version or digest used in each run.
Provider logs for exposed secrets: cloud, SaaS and database access logs for each secret rotated, covering the window.
Self-hosted systems: disk and memory images before rebuild.

Notification follows from what the exposed secrets protected. If any gave access to personal data and there is evidence or a reasonable likelihood of access, data protection rules may apply; under GDPR Article 33 a controller notifies the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware. Check sector and national rules in the Cyber Incident Reporting Requirements Map.

Decision guidance

Situation	Choose	Trade-off
Vendor breach, findings store held only locations	Rotate scanner tokens and active findings; keep scanning on new credentials	Faster, but relies on the vendor's statement of scope
Findings store held full values	Rotate every finding, open or dismissed	Large effort; prioritise by validity and privilege
Scanner step in CI was tampered with	Treat as a CI/CD compromise and rotate all pipeline secrets	Significant disruption to delivery, but anything less leaves harvested secrets live
Small organisation, few repositories	Rotate everything the scanner could see	Simpler than triaging individual findings
Large organisation, thousands of findings	Automate revocation through provider APIs, starting with active secrets	Needs secret owners mapped before the incident

Detection and measurement

Time to revoke scanner access: from declaration to all installations and tokens revoked.
Active secrets rotated: percentage of validated-active findings rotated within 24 hours. The 24 hours is an NHI Mgmt Group recommendation.
Total rotation completeness: findings rotated or confirmed inert, out of all findings.
Unpinned scanner steps: number of pipelines using the scanner by tag rather than commit or digest, target zero.
Owner mapping: percentage of secret types with a named owner and documented rotation steps.
Standing alert: bulk findings exports, rule changes and mass dismissals alert the security team, tested at least yearly.

Framework mapping

Framework	Reference	Where it applies
NIST CSF 2.0	RS.MA-01, RS.AN-03, RS.MI-01, RS.MI-02, RC.RP-05	Coordinated response, root cause, containment, eradication, verified restoration
NIST SP 800-53 Rev. 5	IR-4, IR-6, IA-5, AC-6, SA-9, SI-7, AU-6	Incident handling and reporting, authenticators, least privilege, external services, integrity, log review
NIST SP 800-61 Rev. 3	CSF 2.0 Community Profile for incident response	Overall response structure
CIS Controls v8.1	Control 3, Control 5, Control 6, Control 16, Control 17	Data protection, accounts, access, application security, incident response
ISO/IEC 27001:2022 Annex A	5.17, 5.24 to 5.28, 8.28	Authentication information, incident management, secure coding
MITRE ATT&CK	T1552.001, T1528, T1213, T1195.002, T1685	Credentials in files, token theft, repository collection, supply chain, defence impairment

Common failure patterns

Rotating only open findings. Dismissed and allowlisted findings are readable too, and some are real secrets that were marked as test data.
Forgetting the pipeline environment. In the Codecov breach, a modified script in customers' CI sent the environment to an attacker, and Codecov advised customers to re-roll every credential in their CI environment variables, not just those a scanner had flagged.
Running scanner steps by moving tag. A changed tag silently delivers new code into every pipeline that uses it.
Keeping the old token for convenience. Reconnecting with the same organisation-wide token restores the attacker's route.
Trusting post-incident scan results blindly. If rules were weakened during the window, a clean scan can mean the scanner is blind, not that you are clean.

Practitioner checklist

Know whether your scanner stores full secret values, partial values or only locations.
Revoke repository installations, tokens and deploy keys used by the scanner.
Remove or pin scanner steps in CI and verify every artefact by checksum or digest.
Export findings with validity status and rotate active secrets first.
Rotate dismissed and allowlisted findings that are real.
Rotate all secrets in pipelines where a tampered scanner step ran.
Restore rules and allowlists from a reviewed baseline and re-open dismissals made in the window.
Keep interim scanning running on high-risk repositories.
Reconnect read only, scoped to selected repositories, in rings.
Preserve scanner, git hosting, CI and provider logs before retention expires.

If your secrets scanning tool is compromised: containment, credential rotation and rebuild playbook