The following is an explanation how human behaviour leads to leak of private GitHub repos information, or in the worst case scenario, total leak of the source code. To fight this issue, the author provides some tips when working with private repos.

https://tylercipriani.com/blog/2023/03/31/private-ish-github-repos/

GitHub private repos lull us into lazy thinking.

We cram our secrets into git, then shove it off to the most expansive code forge in the history of humanity, and most of the time: everything’s fine.

But GitHub’s ssh host key leak last week demonstrates that private repos are, at best, private-ish.

Secrets get out. 🦖 Life finds a way.

How repos become public 💀

There are oodles of trivial ways you can spill your git secrets to the world.

• 📢 Publish your .git directory – Exposing the entire history of your code through server misconfiguration or deployment mistakes is alarmingly. common.
• 🎣 Get phished – Even cool kids can have their passwords stolen. Examples in the wild:
  • Slack
  • Dropbox.
• 🥄 Bad fork – Especially true with the GitHub/GitLab model—a developer forks a private repo and makes it public. Examples in the wild:
  • Uber’s “$57M” data breach
  • Equifax incident
  • Starbucks
• 🖱️ Click the wrong button – You’re a handful of button clicks away from making a private repo public—miscommunication or confusing UI can leave you exposed.

Move fast, leak things 🚰

Most of the people at GitHub and GitLab are humans. And humans make mistakes (especially when they’re on a deadline).

Back in 2016, GitHub had an incident where private repos exposed to unauthorized users.

And GitLab has had at least three incidents matching the search “GitLab+Private repos” in the Common Vulnerabilities and Exposures (CVE) database (1, 2, 3).

Mitigations 🛠️

In the spirit of blame-aware postmortems—what can we do to fix this?

Easy fixes

• Keep your .git directory to yourself. Avoid deploying it. Configure your webserver to deny access to it if you do.
• Setup two-factor authentication, like, Right. Now. Bonus points if your second factor is a hardware key.
• Audit your access control on your forge of choice.

Impossible fixes

It’s impossible to prevent a zero-day that exposes your private repo.

So, if you’re worried about it: stop putting sensitive data into private repositories.

Especially the kind that would damage your reputation if it got out:

• Passwords/production credentials
• Personally identifying information (PII) of users
• Any code, data, or metadata you expect to be permanently private

You can set a policy and ensure developers use secret scanners as pre-commit git hooks. Inject secrets into your application at runtime.

Beyond runtime secrets? Keep that junk out of git.