Source Code Leak Response Playbook: Contain secrets, takedowns and exposure after a repository leak

When source code leaks, every credential, internal hostname and design decision in its history leaks with it, and the copy cannot be recalled. When Lapsus$ published about 190GB of Samsung code in 2022, GitGuardian reported 6,695 secrets in it, including 2,408 RSA private keys and 80 AWS IAM keys. A leak can come from an outsider with a stolen token, an insider pushing code to a personal account, or a misconfigured Git server, and the response differs from a normal data breach: the code is the store of secrets, the takedown is a legal process, and the clock is set by how fast the copy spreads. This template is for security, engineering and legal teams handling a leak of proprietary repositories. Single exposed keys are handled in the Leaked Credential Response Playbook; this page covers the leak of code itself.

How to use this template

• Replace placeholders: [Organisation], [code host], [secret scanner], [legal counsel] and the bracketed thresholds with your own values.
• Two tracks in parallel: the technical track (scope, secrets, access) and the legal track (takedown, preservation, notification) start at the same time. Waiting for one to finish before starting the other loses days.
• Assume the secrets are burned: treat every credential found in the leaked code and its history as compromised, whether or not you see misuse.
• Link related playbooks: if an insider is suspected, coordinate with the Insider Data Theft Response Playbook; if the leak came through a compromised pipeline, use the CI/CD Pipeline Compromise Playbook as well.

1. Scope and triggers

This playbook applies to all [Organisation] proprietary source code, infrastructure as code, configuration repositories and build artefacts, wherever hosted. Invoke it on any of the following:

• Public copy found: [Organisation] code on a public code host, paste site, forum, torrent or leak site, reported by staff, a researcher, a monitoring service or the press.
• Extortion claim: a threat actor claims to hold [Organisation] repositories, with or without samples.
• Abnormal access: mass cloning or archive downloads from the [code host] by one identity, especially a token, an unfamiliar IP range or a departing employee (ATT&CK T1213.003 Code Repositories).
• Visibility change: a private repository made public, or a fork of a private repository into a personal or external organisation.
• Token compromise: a code host token, deploy key or CI credential with read access to repositories reported leaked or stolen.

2. Roles and contacts

3. Detection and triage

1. Capture the evidence first. Record URLs, screenshots, repository names, commit hashes, uploader account names and timestamps. Hash and store a copy of the leaked material in a restricted evidence location; do not clone it onto developer laptops.
2. Confirm it is yours. Match commit hashes or unique files against your repositories. A fabricated or recycled leak is common in extortion claims.
3. Identify which repositories and which point in time. The latest commit date in the leak bounds when the copy was taken; the list of repositories points to the access path (one team's repositories suggests a user; everything suggests an admin or broad token).
4. Find the access path. Query the [code host] audit log for clones, archive downloads, visibility changes and token use over the relevant window. Note that audit history is limited (GitHub documents 180 days for the organisation audit log), so export it immediately.
5. Rate severity:

4. Containment

• Close the access path: revoke the token, OAuth app, SSH or deploy key used; suspend the account; force re-authentication for code host users if the path is unclear. In the New York Times case reported in 2024, an exposed GitHub token reached about 5,000 repositories; see the New York Times GitHub Breach 2024.
• Scan the leaked copy for secrets across the full history, not only the latest commit (T1552.001 Credentials In Files). Use [secret scanner]; tools such as TruffleHog can mark findings as verified by testing them against the issuing service, which helps prioritise.
• Rotate in priority order: verified live secrets, then cloud and code host credentials, then signing keys, then everything else found. Use the Secrets Rotation Runbook Template.
• Request takedown: legal files notices with each host. For GitHub, a DMCA notice must identify the copyrighted work and each infringing URL, include contact details, a good-faith statement and a statement under penalty of perjury, and be signed. GitHub states that disabling a parent repository does not disable its forks: name each fork, or, for a network over 100 repositories, state that all or most forks infringe to the same extent.
• Preserve evidence at the host: ask the platform to preserve logs and account data for the uploader. In 2023 Twitter obtained a DMCA takedown and sought a court subpoena to identify the uploader of its code; see the Twitter Source Code Leak 2023.
• Do not engage the leaker or pay for deletion without legal and executive approval; deletion promises cannot be verified.

Decision: takedowns work well on mainstream code hosts and paste sites, which have published processes, but have little effect on torrents and leak sites run by extortion groups. The incident commander and legal decide where to file based on reach: file fast on any host that indexes code for search, because that is where opportunists find secrets, and record the decision not to pursue hosts where a notice would only publicise the leak. Smaller organisations without in-house counsel should agree a retained firm and a notice template in advance; larger organisations should name one owner for all takedowns so notices stay consistent and the fork list is complete. Whatever the takedown outcome, rotation proceeds: removal reduces spread, it never makes the secrets safe again.

5. Eradication

• Remove secrets from your own repositories: rewriting history does not undo the leak, but it stops the secrets spreading through future clones and forks. Rotation, not deletion, is the fix.
• Close the root cause: scope down or replace broad personal access tokens with fine-grained or short-lived credentials (see the GitHub Personal Access Tokens Security Guide), require SSO for organisation access, and remove stale outside collaborators.
• Review what the code reveals: engineering owners list vulnerabilities, hardcoded endpoints and weak authentication logic visible in the leak, and fix them in priority order, as an attacker can now read the code at leisure.
• Turn on scanning and push protection across the [code host]. GitHub secret scanning covers the full Git history on all branches as well as issues, pull requests, discussions and wikis, and optional validity checks show which detected secrets are still active.

6. Recovery

1. Confirm rotation is complete: every secret found has an owner, a rotation date and a test showing the old value no longer works.
2. Monitor for use of leaked material: alert on any attempt to use rotated credentials, and watch for new forks, mirrors and leak site posts for [90] days.
3. Re-issue signing material if signing keys leaked, and plan customer communication for revoked certificates. See the Code Signing Security Guide.
4. Track counter-notices: GitHub restores content 10 to 14 days after a valid counter-notice unless you tell it you have started legal action, so legal must calendar that window.

Where identity fits

Most code leaks are identity incidents: a personal access token, a CI service account, an OAuth app or a departing employee's account with more repository access than it needed. And the leaked code is itself full of non-human identity credentials. Inventory every token and key that can read repositories, give each an owner and an expiry, and alert on bulk clone activity by any of them. See the Git Secret Scanning Guide.

7. Communication and notification

• Internal: tell engineering what leaked and which secrets are being rotated, and instruct staff not to download or share the leaked copy.
• Customers: if leaked code exposes customer data, customer-specific configuration or a vulnerability in a product they run, legal and product security decide on advisories.
• Regulators: personal data in the repository (test fixtures, database dumps, logs) can make it a personal data breach; legal assesses [GDPR Article 33 / other regimes].
• Press and leak sites: prepare a holding statement; say what is known, do not speculate about the leaker.
• Law enforcement: report extortion and theft of trade secrets through [national cyber crime reporting route] as advised by legal.

8. Post-incident review

• Timeline: access gained, code copied, leak published, detection, takedown, rotation complete.
• Secrets debt: how many live secrets were in code, how long they had been there, and why scanning and push protection did not stop them. The Samsung case showed source code is also a credential store; see the Samsung Source Code Leak 2022.
• Access hygiene: token scopes, offboarding speed, outside collaborators and repository visibility defaults.
• Detection: did bulk clone alerts exist, and were code host logs streamed to the SIEM before the incident?

Implementation guidance

1. Stream code host audit logs to the SIEM so history outlives the platform's retention window, and alert on bulk clones, archive downloads and visibility changes.
2. Keep a repository register with owner, sensitivity and the secrets classes it touches, so triage can rate a leak in minutes.
3. Pre-draft the takedown notice with legal, including the sworn statement wording the main hosts require.
4. Run a quarterly full-history secret scan of all repositories and fix verified findings first.
5. Exercise yearly: a tabletop where a repository appears on a public host on a Friday evening.

Framework mapping

Standards and references

• NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• GitHub Docs: Guide to submitting a DMCA takedown notice
• GitHub Docs: About secret scanning
• GitHub Docs: Reviewing the audit log for your organization
• TruffleHog: project documentation
• MITRE ATT&CK: Code Repositories
• MITRE ATT&CK: Credentials In Files

Related NHI Mgmt Group resources: Leaked Credential Response Playbook · Insider Data Theft Guide · GitHub and GitHub Actions Security Guide · Private Keys in Repositories Guide