GitHub Source Code Theft: A Developer’s Practical Checklist for Repo Lockdown

The headline is the part worth paying attention to: GitHub is reportedly investigating a major cyberattack, and the claim is that stolen source code was being sold. That is not the kind of story to just bookmark and move on. If you host repositories on GitHub, treat it as a reason to do a quick repo lockdown check.

I would not react with panic. I would assume one of the usual trust boundaries is weaker than you thought: an overprivileged maintainer, a stale deploy key, a workflow token with write access, or a runner that can reach code and secrets it should not.

What the GitHub source code theft report means for developers

Treat the report as a containment trigger, not just a news item

When a source-code theft story appears, the easy mistake is to focus on the alleged attacker and ignore your own exposure.

The questions that matter are straightforward:

• Could someone clone your private repos without you noticing?
• Could they alter code, tags, or release artifacts?
• Could they use your CI/CD path to reach signing keys, cloud credentials, or package registries?
• Could one compromised account spread into an organization-wide incident?

If the answer to any of those is “possibly,” this report is your cue to tighten things up before you need an incident report.

For developers, source code theft is not only an IP problem. It can also expose:

• secrets buried in history or workflow files,
• build logic that should stay private,
• release signing material,
• infrastructure details that make later exploitation easier.

An attacker does not need your whole environment to do damage. A readable repo, a weak automation token, or a forgotten machine account may be enough to turn code access into operational access.

Separate confirmed facts from unverified claims

The public reporting around this incident is still framed as an investigation and a claim. That distinction matters.

Keep the facts in separate buckets:

That split keeps you from chasing rumor while still doing useful work: tightening access, checking audit trails, and rotating the things that actually matter.

Build a fast inventory before you change anything

Map repositories, organizations, and privileged maintainers

Before you rotate a single secret, build a map.

Start with:

• every GitHub organization you control,
• every private repository,
• every repository admin,
• every organization owner,
• every security manager if you use that role,
• any service accounts that can approve or merge changes.

You want to know who can change what without guessing.

A basic inventory table is enough to start:

If this information is scattered across people’s heads, that is already a finding. I usually treat missing ownership as a security issue because it makes it hard to tell whether an access change is intentional or stale.

List CI/CD systems, deploy keys, machine users, and bot accounts

The next inventory is operational, not organizational.

Collect every integration that can reach your repos:

• GitHub Actions workflows
• self-hosted runners
• external CI systems
• deploy keys
• machine users
• bot accounts
• package publish tokens
• cloud deploy identities
• signing services

For each one, write down:

• where it lives,
• what scope it has,
• whether it is long-lived,
• what repo or org it can reach,
• how it is rotated.

A lot of real exposure comes from the gap between “human access” and “automation access.” Teams usually review admins and forget the bot that can push to a release branch at 2 a.m.

Identify which repos contain source, secrets, release tooling, or signing material

Not every repository deserves the same level of attention.

Prioritize the ones that contain:

• production source code,
• deployment automation,
• infrastructure-as-code,
• secret templates or .env.example files that reveal too much,
• release tooling,
• build scripts,
• package publishing workflows,
• signing or attestation material.

A repo with app source is bad enough. A repo with app source plus deployment automation is more interesting to an attacker. A repo with source, release signing, and credentials in history is a problem already in motion.

Lock down repository access paths first

Review org membership, outside collaborators, and team permissions

Start with access.

Check:

• who is in the organization,
• who is an outside collaborator,
• what teams have write or admin access,
• whether any team got broad access for convenience and never had it narrowed.

This is where old assumptions tend to linger. A contractor who left months ago, a merged team after an acquisition, or a temporary admin grant for a release can quietly become standing privilege.

If you need a quick review order, use:

1. owners,
2. admins,
3. write access,
4. outside collaborators,
5. integration accounts.

Remove stale admins and narrow write access to the smallest useful set

Least privilege is not a slogan here. It is what keeps one compromised account from becoming an org-wide event.

Ask of every admin:

• do they still need repo administration, or only merge rights?
• do they need write access to every repo, or just one?
• can team-based access replace direct assignment?

A good access pattern is usually boring:

• a small set of org owners,
• repo-specific maintainers,
• read-only by default,
• elevated access only when needed and only where needed.

If someone can merge, manage secrets, approve workflows, and edit branch protection, incident response just got harder.

Check whether SSO, MFA, and recovery controls are enforced

If GitHub accounts are the front door, SSO and MFA are the locks.

Verify:

• MFA is required for all human accounts,
• SSO is enforced for organization access,
• recovery methods are controlled,
• personal accounts are not carrying hidden operational access,
• legacy recovery paths are not a bypass.

Also check what happens when someone loses access. Recovery should not be so weak that an old email account or forgotten recovery code becomes the easiest way back into the org.

If you run critical repos, make sure the policy is enforced, not just written down.

Hunt for exposed secrets and abuse-ready credentials

Search for hardcoded tokens, private keys, and cloud credentials

Source theft gets worse fast when the repo contains usable secrets.

Search for:

• API tokens,
• private keys,
• SSH keys,
• cloud credentials,
• signing certificates,
• webhook secrets,
• .npmrc, .pypirc, or similar publish credentials,
• .env files that were committed by mistake.

Do not trust “we removed it from the latest branch” as a defense. A secret can still survive in:

• git history,
• tags,
• forks,
• CI logs,
• build caches,
• issue attachments,
• release artifacts.

A real scan should include history, not just HEAD. For GitHub-hosted repos, use your normal secret scanning tools plus a history-aware pass.

Rotate secrets used by GitHub Actions, deploy pipelines, and release jobs

If a secret can deploy, publish, or sign, assume it needs rotation after any meaningful access event.

Start with:

• GitHub Actions secrets,
• environment secrets tied to deployments,
• registry tokens,
• cloud API keys,
• signing keys,
• webhook secrets consumed by production systems.

The common mistake is partial rotation. If you rotate the main deploy token but forget the staging token, the old path may still be enough to reach production through a lateral step.

A simple rule helps:

• if the secret can write, deploy, or sign, rotate it,
• if the secret exists in more than one place, rotate all copies,
• if the secret was ever printed, logged, or shared in chat, assume it is already compromised.

Revoke long-lived PATs and replace them with tighter-scoped alternatives

Personal access tokens are often the quietest weakness in the whole setup.

Review:

• classic PATs,
• fine-grained PATs,
• OAuth app grants,
• app installation tokens,
• machine-user tokens.

Revoke anything unused. Replace anything too broad. Avoid tokens that outlive the person or task that needed them.

A better pattern is:

• short-lived credentials where possible,
• GitHub App permissions instead of personal tokens,
• repo-scoped tokens instead of org-wide tokens,
• automation credentials separated by environment.

Long-lived tokens are useful to attackers because they are useful to you.

Audit CI/CD workflows for supply-chain abuse

Inspect workflow permissions, triggers, and reusable action dependencies

GitHub Actions is often where code theft turns into code execution.

Review each workflow for:

• trigger scope,
• default token permissions,
• use of pull_request_target,
• reusable workflow trust,
• dependence on external actions,
• scripts that run with write access.

The usual problem is not one dramatic flaw. It is a chain of small defaults:

• workflow runs on too many events,
• token has more permissions than needed,
• action is pulled by a floating reference,
• runner can reach internal resources.

That chain gives a code thief a route from repo access to build-time abuse.

Reduce default token scope and block unnecessary write access

For every workflow, ask: does it truly need write access?

Most of the time, the answer is no.

A safe baseline is:

• read-only token unless a job must write,
• job-level permissions instead of workflow-wide privilege,
• separate workflows for build and publish,
• explicit approval for release jobs.

Here is the kind of permission block I prefer to see:

permissions:
  contents: read
  pull-requests: read

If a workflow needs to publish, isolate that job and make the privilege obvious. Hidden write access is how incidents become hard to reason about.

Pin third-party actions and review self-hosted runner exposure

Third-party actions are part of your supply chain.

Make sure external actions are pinned to a commit SHA, not just a branch or tag. Tags can move. Branches absolutely can move. That is convenient for maintainers and annoying for defenders.

Also review self-hosted runners carefully:

• are they isolated per trust boundary?
• can untrusted pull requests reach them?
• do they hold credentials that matter outside CI?
• can a workflow write to disk and persist between jobs?

If a runner can access internal resources, treat it like a server, not a disposable build box.

Harden branch protection and release controls

Require reviews, status checks, and signed commits where they fit

Branch protection should do real work, not just look tidy.

For important branches, require:

• pull request review,
• status checks,
• no direct pushes,
• no force pushes,
• signed commits if your workflow supports them.

Signed commits are not a universal fix, but they do raise the cost of silent tampering. Status checks and reviews help only if the checks mean something and the reviewers are independent enough to catch bad changes.

Protect release branches and tag creation from direct modification

Release branches and tags deserve extra care.

Protect:

• main,
• release branches,
• deployment branches,
• tag creation,
• version bump workflows.

If a release branch can be rewritten, the history you trust may not be the history that shipped. If tags can be moved, a package release can look legitimate while pointing to a different commit than expected.

You want the release path narrow enough that every change is visible and attributable.

Separate build, approval, and publish steps so one compromise cannot ship code

This is one of the highest-value architecture changes you can make.

A safer release flow looks like this:

Do not let the same workflow both build from untrusted input and publish with broad credentials. If one step is compromised, the others should still hold.

That separation limits the damage from stolen repo access, stolen workflow tokens, or a malicious contribution.

Use GitHub audit logs and alerts to spot suspicious activity

Look for new tokens, permission changes, repo transfers, and runner registration

The audit log is where you stop guessing.

Search for:

• new PATs,
• app installs,
• permission changes,
• org role changes,
• repo transfers,
• new runners,
• runner registration changes,
• secret access policy changes.

The exact event names vary by plan and feature set, but the pattern is the same: look for administrative changes around the time you suspect access drift.

If you manage more than one org, compare baselines. A strange event in one org may be normal in another. The same strange event across all orgs is more interesting.

Correlate clone spikes, branch rewrites, and secret access with admin actions

If you think code was stolen, the useful question is not only “what changed?” It is “what changed first?”

Correlate:

• clone activity,
• force pushes,
• branch deletions,
• tag changes,
• secret reads,
• runner registration,
• admin account logins.

A pattern like “new admin token, then runner registration, then secret access” tells a much clearer story than any single event on its own.

If you have SIEM coverage, push GitHub audit events into it. If you do not, export what you can and preserve the timeline somewhere controlled.

Set up alerts for new collaborators and changes to security settings

At minimum, alert on:

• new outside collaborators,
• org owner changes,
• branch protection changes,
• secret updates,
• runner additions,
• app installations,
• changes to repository visibility.

The goal is not to wake people up for every routine edit. The goal is to make security-sensitive actions noisy enough that they do not disappear into normal development traffic.

Contain and recover if you suspect theft already happened

Freeze risky changes and preserve evidence before rotating everything

If you suspect theft, do not immediately delete history and rotate every credential in sight.

First:

• preserve logs,
• snapshot audit exports,
• record active sessions,
• note which repos and accounts were involved,
• freeze high-risk changes,
• block unreviewed merges.

You want enough evidence to answer later questions:

• when did access begin,
• what was taken,
• which systems were touched,
• which credentials may be exposed.

If you wipe everything instantly, you may also wipe the trail that explains the incident.

Revoke sessions, rotate credentials, and reissue any compromised signing material

After evidence is preserved, move to revocation.

Prioritize:

• active sessions for affected users,
• API tokens,
• deploy keys,
• CI secrets,
• registry credentials,
• cloud credentials,
• signing certificates or keys if there is any chance they were exposed.

If a signing key is involved, do not treat it like an ordinary secret. You may need to revoke trust in artifacts already published and reissue from a clean chain.

That is painful, but it is better than trusting a compromised signature.

Rebuild trust by validating clean branches, clean runners, and clean deployments

Recovery is not finished when secrets are rotated.

You also need to verify:

• branch history is clean,
• protected branches were not rewritten,
• release tags point where they should,
• self-hosted runners are rebuilt or reimaged,
• deployment targets are using fresh credentials,
• package registries are publishing from a known-good pipeline.

This is where many teams stop too early. They fix access, but not provenance. The result is a system that looks healthy and may still ship bad builds.

A practical lockdown checklist for the next 30 minutes, 24 hours, and week

Immediate actions for the first 30 minutes

1. Confirm whether you actually have exposure in GitHub.
2. Identify the highest-value repos and owners.
3. Freeze unnecessary merges and release activity.
4. Preserve audit logs and security events.
5. Revoke any obviously stale or suspicious sessions.
6. Start an access inventory if you do not already have one.

Verification steps for the next 24 hours

1. Review org owners, admins, and outside collaborators.
2. Audit GitHub Actions permissions and runner exposure.
3. Search for secrets in code, history, and workflow files.
4. Rotate deploy, publish, and signing credentials.
5. Check for new tokens, new apps, and permission changes.
6. Verify branch protection and tag protection on release paths.

Longer-term hardening tasks for the next week

1. Replace broad PAT use with tighter-scoped alternatives.
2. Narrow repo and org permissions to the minimum useful set.
3. Separate build, approval, and publish jobs.
4. Pin third-party actions to immutable references.
5. Improve audit-log alerting and retention.
6. Document recovery procedures for source theft and credential theft.

Common mistakes that turn a theft into a bigger incident

Rotating secrets without checking where they are still stored

If a secret lives in three places and you rotate only one, you have not closed the exposure. You have just created confusion.

Check:

• repo secrets,
• environment secrets,
• CI variables,
• local developer config,
• release tooling,
• documentation snippets,
• old forks and mirrors.

Trusting repo history without reviewing workflow provenance

A clean-looking branch is not enough if the workflow that built it was compromised.

Always ask:

• who ran the workflow,
• what token it had,
• which action versions it used,
• whether the runner was trusted,
• whether the artifact came from a known-good commit.

Leaving old forks, mirrors, or build artifacts exposed

Code theft often gets amplified by secondary copies.

Review:

• public forks,
• internal mirrors,
• archived artifacts,
• package tarballs,
• release downloads,
• cached build outputs.

If sensitive source or build material was replicated outside the main repo, the attacker may not need GitHub anymore.

Conclusion: make GitHub part of your incident response plan

The useful lesson from this report is not “GitHub is unsafe.” The useful lesson is that GitHub is part of your attack surface, and it should be treated that way.

For most teams, the real issue is not one catastrophic failure. It is the mix of:

• too many people with access,
• too many tokens with broad scope,
• too much trust in automation,
• too little visibility into audit trails.

If you already have a repo inventory, access review process, secret rotation plan, and CI hardening baseline, an event like this becomes a routine validation exercise instead of a scramble.

If you do not have those things, start now. The next incident will not wait for sprint planning.