Incident response after GitHub code exposure
A leak from internal repositories changes the shape of the incident fast. The first useful question is not who posted it, but what code sat in those repos, who could reach it, and what else the exposed access could still touch. In a GitHub internal repositories breach, the damage often sits in the boring corners: private code repositories, tokens, deployment credentials, and permission paths that nobody meant to leave open.
Contain the blast radius before you chase the story
Lock the exposed surface first. Freeze repository access changes, suspend suspicious accounts, and isolate any systems that touched the compromised developer environment. If the entry point came from an endpoint, treat that machine as hostile until it is rebuilt or proven clean.
Do not waste the first hour arguing about how public the leak looks. A repository can stay private and still be exposed to anyone who walked in through the wrong access boundary. The practical response is to stop further reads, stop new pushes, and stop lateral movement through connected accounts or automation.
If repository permissions are broad, assume the blast radius is broader than the repo list suggests. Read access, organisation-level roles, deploy keys, app tokens, and linked CI systems can all widen the damage. Tighten access controls before you start cataloguing the files.
Trace the access path through repository permissions and audit logging
Audit logging matters because it gives you the route, not the drama. Look for login events, token use, repository reads, permission changes, and unusual access from developer accounts or service identities. The point is to reconstruct what was reachable, not to rely on the number of repositories named in public claims.
Repository permissions tell a different story from repository counts. A private repository list can hide shared credentials, internal tooling, or code that mirrors other sensitive systems. If the same identity could reach multiple private code repositories, treat that as a single access boundary failure rather than a pile of separate incidents.
Check whether the exposure stayed inside private code repositories
Keep the scope test narrow and blunt. If the exposed material stayed inside private code repositories, the incident still matters, but the response stays anchored to code, tokens, and internal workflows. If the same access path reached customer-facing systems, package registries, or deployment infrastructure, the problem stops being a simple code leak.
Watch for evidence of copying, archiving, or sale attempts. Public forum claims are useful only when they line up with logs, missing artefacts, or access trails. A boast about thousands of repositories means very little until it matches what audit logging and inventory checks can prove.
Triage the repos, keys, and follow-on risk that actually matter
Start with the repositories that hold secrets, build logic, release tooling, and infrastructure code. Source code alone can be awkward; source code plus credentials is where incidents become noisy. Check for hard-coded tokens, CI variables, SSH material, cloud keys, package publish credentials, and anything that would let an attacker move from read access into write access.
The follow-on risk usually lives in things that look ordinary during development. Internal scripts, test fixtures, and deployment manifests often carry enough detail to help an attacker map production systems. If the exposed repos included release automation or infrastructure code, assume a higher chance of post-exposure probing.
Revoke tokens, rotate secrets, and watch for post-exposure access
Revoke anything that could survive a repository leak. That includes personal access tokens, OAuth grants, deploy keys, signing credentials, and API keys stored in code or passed through automation. Rotate secrets in the order that cuts off live access first, then the slower pieces.
Keep an eye on post-exposure activity for longer than the first cleanup window. Attackers who get code often come back for tokens, reused credentials, and stale access paths. Incident response should keep watching audit logging, package publishing, CI runs, and unusual repository access until the changed credentials settle and the noise drops away.
If there is one clean boundary, it is this: private code repositories are not private once the access path fails.
