Recently, a major finding in the cybersecurity world caught my attention — and it’s something every IT team, especially at SMBs and enterprise companies, needs to hear.

Security researcher Sharon Brizinov uncovered hundreds of leaked API keys, tokens, and credentials hiding in public GitHub repositories. What’s alarming is that these secrets were buried inside deleted files — files developers thought were gone.

Brizinov’s work earned him $64,000 in bug bounties, but the bigger story here is the real risk that’s often overlooked: deleted doesn’t mean secure.

Why This Matters for Your Business

Even if developers remove sensitive files from a repository’s working directory, Git’s design means those files still live on inside the repo’s history. Unless someone takes very specific steps to rewrite Git history and run a garbage collection, those secrets remain recoverable.

Here’s the breakdown of why this is happening:

• Git’s architecture stores complete snapshots of every change ever made.
• Deleted files aren’t immediately removed from the .git/objects folder.
• Full removal requires advanced actions like using git filter-branch or git-filter-repo, not just deleting files.
• Public repositories make this risk even bigger because copies and clones may exist elsewhere, permanently.

Brizinov built an automated tool to dig into all commits, resurrect deleted files, and scan for sensitive data. His focus? Repositories from companies with active bug bounty programs and those with 5,000+ stars on GitHub.

The results were startling: he found hundreds of active secrets including credentials for AWS, GCP, Slack, GitHub, HuggingFace, OpenAPI, and Algolia — most buried in binary or hidden files.

The Root Causes Behind the Leaks

After analyzing dozens of real-world incidents, Brizinov pinned it down to three main issues:

• Lack of Git knowledge — many developers don’t realize how persistent Git’s snapshots are.
• Overlooked hidden or binary files — secrets were committed unintentionally.
• Blind trust in history-rewrite tools — assuming tools fully erase sensitive data without manual verification.

In short, it’s a mix of technical complexity and human oversight. A combination we know all too well can lead to serious security incidents.

Practical Steps You Should Take

If your organization uses GitHub (or Git-based systems), here’s what I recommend we focus on:

• Audit your repositories regularly — not just the latest branch, but full commit histories.
• Train developers about Git’s storage model and the real risks of leaked secrets.
• Use Git history-rewriting tools carefully — and verify with manual checks.
• Immediately rotate secrets if any sensitive information has been committed, even if it’s later deleted.

Secrets management isn’t a one-time fix. It’s about building habits that treat every code commit with the same rigor we expect from firewall configurations or access controls.

This story isn’t just about GitHub. It’s a reminder that in cybersecurity, what’s out of sight isn’t always out of reach. We need to rethink how we handle source control, secrets, and history — not just at the moment of discovery, but proactively as part of our development pipelines.

If you want, I can also share a practical checklist we’re using to strengthen our GitHub security practices. Just let me know.