If you’re reading this, there’s a decent chance you clicked through from somewhere like LinkedIn and have no idea what GitSnitch is yet. Fair enough. Here’s the plain version.

The problem

Most security incidents on GitHub aren’t dramatic. Nobody breaks in through some clever exploit. What actually happens is much more boring:

  • A developer accidentally commits an API key or a database password.
  • A contractor gets added as an org admin for a one-off task, and six months later they still have full access.
  • Someone turns off branch protection on main to push a hotfix and forgets to turn it back on.
  • A force push quietly rewrites history on a protected branch.
  • An admin account that hasn’t logged in for four months suddenly starts making changes at 2am.

None of these require a sophisticated attacker. Most of them just require one person, careless or malicious, with the right access and nobody watching.

Here’s the part that surprises people: GitHub doesn’t proactively tell you when most of this happens. The information exists in your audit log, but you have to know to go looking for it, and by the time you do, whatever happened has usually already happened.

What GitSnitch does

GitSnitch installs as a GitHub App on your organization. Once it’s connected, it listens to GitHub’s webhook events in real time and watches for the specific things that tend to matter, including:

  • New admins. Someone gets elevated to admin on a repo or the org. You get told immediately, not when you happen to review permissions next quarter.
  • Branch protection changes. A protection rule gets created, weakened, or removed entirely. We tell you who did it, where, and exactly what changed.
  • Force pushes. History gets rewritten on a branch. You find out right away instead of noticing weeks later that a commit you remember isn’t there anymore.
  • Dormant admin activity. An admin account that’s been inactive suddenly starts doing things. This is one of the clearest signals of a compromised account there is.
  • Exposed secrets. We scan for credentials and API keys that made it into a commit, so you can rotate them before someone finds them first.
  • After hours commits. Activity on sensitive repos outside normal working hours, which is worth a second look more often than not.
  • Security advisories. GitHub security advisories affecting your repos, surfaced without you having to go check yourself.
  • Pull request merges on repos you’ve marked as sensitive, so nothing lands on a critical branch without you knowing.

Every one of these shows up on your dashboard the moment it happens, and you can route the important ones to email or Slack.

Why it’s worth having, even if nothing has gone wrong

The honest pitch is that this is cheap insurance. You’re one GitHub App install away from knowing about the things that would otherwise sit in an audit log nobody reads until after the damage is done. Setup takes under a minute, and access is read-only. GitSnitch never writes to your repos, never modifies your settings, and doesn’t store your source code. Secret scanning clones get deleted the moment the scan finishes.

If you’re a small team, this is the security monitoring you’d otherwise have to build yourself with a pile of webhook code and a cron job, minus the maintenance burden. If you’re a bigger team, it’s the layer that catches what your other tools weren’t built to watch for, since most security tooling is aimed at your code and your infrastructure, not the GitHub organization settings sitting underneath both.

There’s a free plan if you want to see it running on your own org before committing to anything. Take a look and connect it to a repo. It takes less time than reading the rest of this blog.