Originally posted at https://tech.labs.oliverwyman.com/blog/2016/05/08/scrutiny-github-permissions-audit-and-backup-tool/
These days we’ve all got an awful lot of our code in Github, and so we really need both a backup (so we can cope with them having a catastrophic failure) and a permissions auditing mechanism (so we know who’s getting access). For the latter, some of you may be saying “just use the audit log” – except you can’t get to it via the API, so you’re having to do this manually, which is never a good idea. I’d been thinking about this, and eventually realised there’s only in fact 3 levels of permissions to a repository (Admin, Write and Read, and the higher ones give you all the earlier permissions) and 3 ways to get it (Team member, Collaborator or Owner), which is a small enough number that we could just enumerate the entire set and diff it to an earlier set of information…
Meet Scrutiny, a tool for permissions audit and backup of Github organisations. It uses an Owner user to list all your repositories and their current permissions, compares that list to the last list it had and emails you the differences. It then uses a user with lower permissions to backup everything that’s changed since the last backup (assuming that you’ve got an “All developers” team with at least read-only access to all your repositories that this user is in), based on the list of repositories from the Owner user. Under the hood it uses github-backup to do most of the backup, but it can use it’s list of repositories to guide where to go, which lets us make sure the “All developers” team has been added to your new shiny repository (which we found people often forget to do).
Of course, this doesn’t get you everything the audit log does, but knowing who’s got access is a good first step until Github fix the lack of audit log API.