When your SAST, SCA or code scanning tool is compromised, the attacker gains read access to your source code, a ranked list of its unfixed weaknesses, every secret the tool has found, and often a token that can write to repositories or pipelines. The incident can start in your tenant of the tool (a stolen admin login, a leaked API token, a rogue integration), on a scan runner you host, in the scanner's own package or container image, or at the vendor. This playbook is for application security engineers, platform teams and incident responders. It is vendor-neutral: the containment points named below sit in your source control platform and CI system, where the tool's access actually lives, so confirm exact setting names in your own platforms' documentation. Hardening before an incident is covered in Securing the SAST, SCA and code scanning tool itself and is not repeated here.
Key takeaways
- Cut the source control side first. The tool's power is an app installation, an OAuth grant or a token in your source control platform; suspend or revoke that and the attacker loses code access even if the tool console is still theirs.
- Treat open findings as a target list. Unfixed critical vulnerabilities and reachable vulnerable dependencies are exactly what an attacker wants; fix the exploitable ones during the incident.
- Every detected secret is now exposed. Hardcoded credentials the scanner reported, and any it stored in finding snippets, must be rotated at source, whether or not they were already marked as false positives.
- A scanner inside CI is a supply chain foothold. A tampered scanner step runs with the pipeline's secrets and token, so check builds and releases produced while it was compromised.
- Rebuild narrower than before. Reconnect with read only repository scope, short-lived federated credentials in CI and write permissions only where a named feature needs them.
What the tool holds and why it matters
Scope the incident by what the tool can reach, not by what was stolen first. This is our view of the common components and what each gives an attacker.
| Component | What an attacker gains | First containment action |
|---|---|---|
| Source control app installation or OAuth grant | Clone access to every repository in scope (ATT&CK T1213.003 Code Repositories); sometimes write access to pull requests, checks or contents | Suspend the installation or revoke the grant; remove repository access |
| Personal or project access tokens used by the tool | Whatever the token owner can do, often far more than scanning needs | Revoke the token; check the owner account for other tokens |
| CI plugin, pipeline step or scan runner | Pipeline secrets, the job token, build artefacts and the ability to alter builds | Disable the step or runner; rotate pipeline secrets |
| Findings database | Exploitable weaknesses by file and line, dependency inventory, reachable vulnerable functions | Export current findings; fix the internet-facing critical ones first |
| Secret detection results | Hardcoded keys, passwords and tokens, sometimes with the value in the snippet | Rotate every reported secret at source |
| Ticketing, chat and SIEM integrations | Webhook secrets and a trusted channel to post misleading messages | Rotate webhook secrets and API keys |
| Private package registry credentials (SCA) | Read, and sometimes publish, access to internal packages | Revoke and reissue read only credentials; check for new package versions |
| Tool admin accounts, SSO and API tokens | Control of policies, suppressions, quality gates and every integration above | Disable accounts, revoke tokens, reset SSO trust |
How the compromise shows up
| Signal | Where you see it | What it can mean |
|---|---|---|
| Clone or API activity by the tool's app or token outside scan schedules, from new IP ranges, or across repositories it does not normally scan | Source control audit and git access logs | Connector credentials used outside the normal scanning path |
| New webhooks, deploy keys, app installations or OAuth authorisations | Source control audit log (webhook, app installation and OAuth application events) | Persistence in the source control platform |
| Commits, pull requests, check results or comments posted by the tool's identity that nobody expected | Repository history, pull request timelines | Write scope being abused to alter code or approve changes |
| Quality gates disabled, rules turned off, findings bulk suppressed or marked false positive | The tool's own audit log | Hiding a planted weakness, in line with ATT&CK T1685 Disable or Modify Tools |
| Scanner step makes outbound connections to unknown hosts, or its version or image digest changes unexpectedly | CI job logs, egress logs, runner telemetry | Tampered scanner package or image (ATT&CK T1195.002 Compromise Software Supply Chain) |
| A vendor security notice asking customers to rotate tokens | Vendor status page, trust centre, account team | Possible exposure of integration secrets held by the vendor |
Pull logs early. On at least one major hosted platform the organisation audit log covers only the last 180 days; export and streaming options depend on your plan. Copy what you need before retention removes it.
Triage: the first hour
- Where did it start? Your tenant of the tool, a self-hosted server or runner, the scanner's published package or image, or the vendor's shared service.
- Which integrations exist? List every source control organisation, CI system, registry, ticketing and chat connection and the identity each uses.
- Which identities can write? Pull request decoration, automatic fix pull requests, commit status checks and dependency update features usually need write scope; these come first.
- Does the scanner run inside CI? If yes, list the pipelines and the secrets available to those jobs; the incident now includes them.
- What did the attacker see? Export findings, secret detection results and the dependency inventory as they stood; this becomes your fix list.
- Is it ongoing? Recent activity from unknown sources means containment starts now, before the investigation finishes.
Containment by priority
- Remove write access. Revoke tokens and app permissions that can push, merge, approve, or post statuses. Branch protection that requires human review limits damage while you work.
- Cut code access. Suspend the tool's app installation: platform documentation describes suspension as temporarily blocking an app from resources owned by the installing account, with suspected leaked credentials as the example case. Unsuspending must be done the same way it was suspended, so record who did it. Revoke OAuth authorisations and personal or project access tokens; platform documentation notes that revoking a project access token invalidates it immediately and cannot be undone.
- Kill live installation tokens. If you own the app, use the platform's installation token revocation endpoint, which revokes the installation token used to call it, so new tokens must be issued afterwards.
- Stop the scanner in CI. Disable the scan step or pin it to a known good version by full commit SHA or image digest; take self-hosted runners offline. Platform hardening guidance warns that a compromise of a single action in a workflow can be very significant because it may reach all repository secrets and use the job token to write to the repository.
- Lock the tool tenant. Disable compromised admins, revoke API tokens, reverse unknown SSO, SCIM and integration changes. If the vendor is compromised, follow its instructions and keep your own containment in place regardless.
- Fix what the attacker saw. Prioritise exploitable, internet-facing critical findings and known exploited vulnerabilities in dependencies.
Rollback: record every installation, token, permission and pipeline change with its previous state, so scanning is restored deliberately and the coverage gap is short. Use compensating checks, such as platform-native secret scanning or a second scanner on critical repositories, while the tool is off.
Credential rotation
| Credential | Rotation action | Check afterwards |
|---|---|---|
| App private key and client secret (self-hosted app you own) | Generate new keys, then delete the old ones | Only the new key ID mints installation tokens |
| Personal and project access tokens | Revoke, reissue with minimum scope and an expiry; replace personal tokens with a bot or app identity | No API calls with old token IDs |
| CI secrets in pipelines that ran the scanner | Rotate cloud keys, registry and signing credentials; move to OIDC federation where supported | Old secrets fail; jobs use short-lived tokens |
| Secrets found by the scanner | Rotate at source, highest privilege first, including ones marked false positive or accepted risk | Re-scan shows no live old values |
| Registry and package feed credentials | Reissue read only for scanning; separate publish credentials | No package versions published in the window |
| Webhook secrets and integration API keys | Rotate on both ends | Signature validation fails for old secrets |
CI hardening guidance favours OIDC so that workflows stop storing credentials as long-lived secrets and use short-lived, well-scoped tokens per run instead. For incidents that spread into pipelines, follow the CI/CD Pipeline Compromise Playbook, and for secret clean-up the Secrets Manager Compromise Playbook covers ordering at scale.
Eradication and rebuild
- Source control persistence: search for new deploy keys, webhooks, app installations, OAuth apps, outside collaborators and branch protection changes made during the window.
- Code integrity: review commits, merged pull requests and tags authored or approved by the tool's identity, and any change to workflow files, build scripts and dependency manifests.
- Build outputs: identify artefacts and releases built by pipelines that ran a tampered scanner; rebuild them from verified sources and revoke or re-sign where needed.
- Suppressions and policy: undo suppressions, exceptions and rule changes made in the window, and re-run full scans with a known good policy set.
- Self-hosted components: rebuild servers and runners from clean images; do not clean in place. Verify scanner packages and images by hash or signature against the publisher.
Recovery and reconnection
- Pilot. Reconnect a small set of non-critical repositories with a new app installation limited to selected repositories and read only contents.
- Verify behaviour. Watch a full scan cycle: source addresses, API mix and clone volume should match the documented pattern.
- Expand in rings. Critical repositories next, then the organisation, once the pattern holds.
- Add write features last. Pull request comments, status checks and automatic fix pull requests only after review, with branch protection requiring human approval.
- Restore CI. Re-enable the scan step pinned by SHA or digest, with the job token set to read only by default as platform hardening guidance recommends.
Evidence to preserve and notification
- Source control logs: audit log exports and git access events for the window.
- Tool audit trail: logins, token creation, policy, suppression and integration history.
- CI evidence: job logs, runner images, scanner versions and digests used.
- Findings snapshot: the exported findings and secret results, stored with restricted access.
- Vendor communications: notices, case numbers and the vendor's scope statement.
Source code rarely contains personal data, but secrets found by the scanner may unlock systems that do. If those systems were accessed, data protection breach 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 rules in the Cyber Incident Reporting Requirements Map. If you ship software to customers and builds were affected, your customer contracts may also require notice.
Decision guidance
| Situation | Choose | Trade-off |
|---|---|---|
| Vendor-side breach, no sign of use against your repositories | Rotate all integration credentials and reported secrets; keep scanning on new credentials | Short gap versus trusting the vendor's scope statement |
| Signs of clone or API activity outside the baseline | Full disconnect, investigation and staged reconnection | Days without scanning; use compensating checks |
| Tampered scanner ran inside CI | Treat as a pipeline compromise: rotate pipeline secrets, rebuild releases | Large effort, but the scanner had the pipeline's privileges |
| Small organisation, a few repositories | Manual review per repository and token | Quick, easy to miss a token without a written list |
| Large organisation, thousands of repositories | Organisation-level suspension, scripted token and webhook inventory | Needs automation and owners prepared before the incident |
Detection and measurement
- Time to cut code access: minutes from declaration to the tool's installation suspended and tokens revoked.
- Reported secret rotation: percentage of secrets the scanner had reported that are rotated, tracked to 100%.
- Write scope in use: number of scanner integrations with write permissions, aiming for only those a named feature needs.
- Pinned scanners: percentage of pipelines running the scanner pinned by SHA or digest.
- Baseline alerting: alerts for the tool's identity acting outside scan schedules or source ranges, 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 with the vendor, root cause, containment, eradication, verified restore |
| NIST SP 800-53 Rev. 5 | IR-4, IR-6, IA-5, AC-6, SA-9, SA-15, SI-7, SR-3 | Incident handling, authenticators, least privilege, external services, development tools, integrity, supply chain |
| NIST SP 800-218 (SSDF 1.1) | PO.5, PS.1 | Secure development environments; protecting code from unauthorised access and tampering |
| CIS Controls v8.1 | Control 6, Control 15, Control 16, Control 17 | Access, service providers, application software security, incident response |
| ISO/IEC 27001:2022 Annex A | 5.19, 5.24 to 5.28, 8.4, 8.25 | Supplier security, incident management, access to source code, secure development |
| MITRE ATT&CK | T1199, T1213.003, T1528, T1552.001, T1195.002, T1685 | Trusted relationship, code collection, token theft, credentials in files, supply chain, defence impairment |
Common failure patterns
- Rotating the tool's token and not the secrets it found. The scanner's results are a credential list; leaving them live hands the attacker the next step.
- Ignoring the scanner's own supply chain. The LiteLLM PyPI package breach showed a poisoned security scanner in CI leaking a publishing token, which then reached downstream users.
- Trusting scripts pulled at build time. In the Codecov breach a modified CI script harvested environment secrets from customer pipelines for months.
- Personal tokens as integration credentials. A token tied to an engineer carries all their access and survives role changes; replace it with an app or bot identity.
- Restoring write scope by default. Reinstalling with the same permissions recreates the path the attacker used.
- Leaving window suppressions in place. Findings suppressed during the incident can hide a planted weakness long after closure.
Practitioner checklist
- Keep a current list of the tool's integrations, identities, scopes and owners.
- Remove write scope first, then suspend the installation and revoke tokens.
- Disable or pin the scanner step in every pipeline and isolate self-hosted runners.
- Rotate every secret the scanner reported, including suppressed ones.
- Rotate pipeline secrets where the scanner ran in CI, moving to OIDC where possible.
- Hunt for new deploy keys, webhooks, apps and branch protection changes.
- Review commits, pull requests and releases touched by the tool's identity.
- Undo suppressions and policy changes made in the window.
- Reconnect in rings, read only first.
- Export source control, CI and tool logs before retention expires.
Standards and references
- NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- NIST: SP 800-218, Secure Software Development Framework (SSDF) Version 1.1
- GitHub Docs: Suspending a GitHub App installation
- GitHub Docs: REST API endpoints for GitHub App installations
- GitHub Docs: Security hardening for GitHub Actions
- GitHub Docs: Reviewing the audit log for your organization
- GitLab Docs: Project access tokens
- MITRE ATT&CK: Data from Information Repositories: Code Repositories
Related NHI Mgmt Group resources: Securing the SAST, SCA and code scanning tool itself · SAST, SCA and code scanning tool integration security guide · GitHub Organisation Compromise Playbook · CI/CD Pipeline Compromise Playbook · Software Composition Analysis (SCA) Guide