PlaybooksPrivate data appears in a public repository
Datacritical40 minutes to prepare

Private data appears in a public repository

Customer information, credentials, internal documents, or private source code were pushed to a public repository.

01DetectConfirm the signal
02ContainStop more damage
03RecoverRestore control
04VerifyProve it works

Your preparation

0 of 0 safeguards ready
0%
Incident worksheet

Make the next decision with evidence

Remove public access, revoke every usable secret, preserve the exposure history, and determine what people, systems, and copies were affected.

EvidenceDecisionActionProof

Capture before evidence disappears

  • Record repository visibility changes, forks, clones, traffic, archive downloads, Actions artifacts, Pages deployments, releases, caches, and search-engine results.
  • Preserve the exact commits and files in restricted evidence with hashes. Do not keep sharing live repository links.
  • Classify each exposed item: credentials, customer records, source, contracts, backups, private keys, internal URLs, or regulated data.
  • Map secrets to issuers and data to people, customers, jurisdictions, contracts, retention rules, and likely automated scanners.

Decisions that change the response

QuestionAct whenAction
Make private or delete?Public access is active and preserving the platform object is not required for containment.Make it private immediately; coordinate deletion only after evidence, forks, Pages, and recovery needs are understood.
Rotate which secrets?A secret was usable at any time during exposure, including earlier Git history.Revoke every affected credential at its issuer, including derived and related credentials.
Notify affected parties?Personal, customer, partner, contractual, or security-sensitive information was reachable.Start legal and customer-impact review using the full reachable history, not only current files.

Proof that recovery worked

  • Signed-out requests to repository, raw files, Pages, artifacts, releases, archives, and known forks no longer expose controlled data.
  • Every exposed credential is listed, revoked at its issuer, replaced, and verified unusable.
  • The exposure timeline and reachable records are reconciled with platform, CDN, search, and provider logs.
  • Fresh scans of Git history, artifacts, issues, releases, and deployment output find no remaining sensitive values.

Controls to put in place

  • Enable secret scanning, push protection, repository visibility alerts, and policy checks for sensitive paths.
  • Use generated test data and keep exports, backups, environment files, and credentials outside repositories.
  • Restrict who can change visibility, create public repositories, publish Pages, or release artifacts.
  • Add pre-commit and CI classification checks without treating them as a substitute for server-side controls.
Tabletop drill

Place fake credentials and synthetic customer data in a private training repository, then simulate a visibility change. Contain every public surface, revoke the fake key, scope Git history, and draft a factual notice.

Escalate when

Use platform support, security responders, insurer, and qualified counsel when real customer data, authentication material, signing keys, source with exploitable secrets, or uncontrolled forks and caches are involved.

What this means

Assume public data was copied, even if the commit was visible for only a short time. Deleting the file or making one new commit does not remove it from Git history, forks, clones, pull requests, caches, or search indexes.

Credentials and customer data need different responses. Revoke credentials first. For personal data, determine exactly whose information was exposed and get legal advice about notification duties.

Warning signs

  • Secret scanning reports an API key, token, password, or private key.
  • A repository, branch, gist, release, artifact, or Pages site becomes public unexpectedly.
  • Search results show an internal filename or customer record.
  • A provider revokes a credential after detecting it on GitHub.
  • Audit logs show an unexplained visibility change or push.

Recover now

First 15 minutes

  1. Record the exposure. Save the repository, commit, file path, first public time, discovery time, forks, pull requests, and suspected data types.
  2. Revoke every exposed credential at its provider. Do this before cleaning Git history. Creating a replacement without revoking the old value is not enough.
  3. Restrict further access. Make the repository private when possible, disable Pages or public artifacts, and pause workflows that use exposed credentials.
  4. Preserve audit evidence. Export repository, organization, cloud, application, and credential-use logs.
  5. Escalate customer-data exposure. Contact security and legal help if personal, financial, authentication, health, or regulated data is involved.

Today

  1. Identify all branches, tags, pull requests, forks, releases, Actions artifacts, caches, and clones containing the data.
  2. Search provider logs for use of exposed secrets from the first public moment onward.
  3. Rewrite history using GitHub’s documented sensitive-data process, then coordinate cleanup with collaborators.
  4. Ask GitHub Support to remove cached views or affected pull-request references when the documented process requires it.
  5. Replace the data or secret everywhere it was used: production, CI/CD, local environments, integrations, and documentation.
  6. Determine affected customers and notification requirements from evidence, not assumptions.

Verify recovery

  • Old credentials fail at the issuing provider.
  • The sensitive content is absent from branches, tags, pull requests, releases, Pages, and reachable history.
  • Public search and direct commit links no longer expose the data where removal is possible.
  • Cloud and application logs show no unexplained use during the exposure window.
  • Collaborators have cleaned or replaced affected clones.
  • Required customer, regulator, insurer, and provider notices are complete.

Prepare now

Prevention

  • Secrets are injected from a secret manager or environment, never stored in source.
  • GitHub secret scanning and push protection are enabled where available.
  • Public-repository creation and visibility changes are limited and logged.
  • Test and sample files contain generated data, not copied customer records.
  • Sensitive exports are stored outside source-control folders.

Response

  • Every production secret has a documented owner and revocation location.
  • Organization audit logs are retained long enough to investigate an exposure.
  • The team knows who handles security, legal, and customer communication.

Practice

  • A drill has revoked a test credential, replaced it in CI/CD, and verified the old value fails.

Common mistakes

  • Deleting only the latest file. The data remains in Git history.
  • Cleaning history before revoking secrets. Attackers can use the credential while cleanup takes place.
  • Assuming a short exposure was unseen. Public repositories are indexed and cloned quickly.
  • Force-pushing without coordination. An old clone can merge the sensitive history back.
  • Saying no data was accessed without logs. Absence of a visible fork is not proof.

Sources

Last reviewed July 19, 2026Guidance changes. Confirm provider-specific actions in the linked official sources.