I scanned all of GitHub's "oops commits" for leaked secrets

Original Article ↗ Hacker News Discussion ↗

Scope and “$25k” feasibility

  • Some readers doubt the revenue figure, noting that companies already scan GitHub commits for secrets.
  • Others point out the novelty: focusing on deleted / force-pushed (“oops”) commits and dangling refs, which many scanners may miss, and that a large fraction of leaked secrets reportedly remain valid for years.
  • A few commenters say similar “GitHub dorking” and key hunting has been profitable for them, so the amount seems plausible.

Git, GitHub, and “git never forgets”

  • Debate over whether “git never forgets”:
    • Git has garbage collection and history rewriting, so locally it can forget.
    • But Git is decentralized; you cannot force all peers (including GitHub and third‑party mirrors) to delete old data. In that practical sense, history is persistent “by design.”
  • GitHub keeps dangling commits and reflogs far longer than many expect, and can’t just run vanilla git gc due to forks and cross‑repo merges.
  • Contacting GitHub support to run a GC pass can remove dangling objects server‑side, but this is not exposed as a self‑service “danger zone” button, and some argue you should assume anything pushed may be archived elsewhere anyway.

Threat model: speed and breadth of exploitation

  • Commenters note there are already many real‑time scanners that immediately exploit exposed keys (especially cloud and crypto keys), sometimes within minutes.
  • Some secrets are auto‑revoked (one example: cloud provider keys), but most advice is still to assume compromise and rotate credentials.
  • Oops/force‑push commits form a special high‑signal subset: they often indicate “this should not have been published,” even when generic scanners don’t flag the content.

Mitigations and best practices

  • Consensus points:
    • Any secret ever pushed must be treated as leaked; rotation is mandatory and urgent.
    • History rewriting and tools like BFG or filter‑repo help reduce future exposure and false positives, but are not sufficient on their own.
  • Additional mitigations discussed:
    • Use pre‑commit or pre‑push hooks (e.g., trufflehog) while keeping them very fast; mirror checks in CI.
    • Prefer environment variables and secret managers (Vault, cloud param stores) over hard‑coding or committing .env files.
    • Avoid committing secrets even to private repos; repos can later become public, be breached, or expose data to hosting providers and governments.

Tools, UX, and data/privacy concerns

  • GitHub’s “Activity” tab exposes force‑pushed and past states many weren’t aware of; history there appears to go back only a couple of years.
  • Some dislike that downloading the study’s SQLite dataset is gated behind a Google account and worry it might be used for marketing.