At the company I'm working at, we have various repositories, with different configuration (branch protection rules, dependabot, repo setttings, ...). It does not help that every org memeber is able to create repos. Is there a way to run some checks (e.g. are branch protection rules correctly setup? is everybody using `main` as their master branch?)? Might build something like this based on OPA... But I cannot imagine something like this not already existing. Or is this just not needed?
Not all your expected checks, but some of them compliance monitoring solutions (e.g. Vanta) can provide. They allow you to monitor whether branch protection rules are set, whether all GitHub users have mapped to employees from the HR system, etc.<p>You also want to learn about GitHub "rulesets" (if your GitHub plan offers it) because they enable central management of branch protection rules across all repositories. Using them, you can specify once at a level that branch protection rules are to be enabled, and then only add exceptions to this rule if needed, so you have security by default.
I think it isn't necessary as this can be accomplished by using the Github API, and organizations that are that big to be concerned with many repositories, have an infrastructure/platform team that will likely fiddle around with it.<p>Another downside about a product like this, is that every organization will need a different setup, tailoring to all their needs is hell, and if you count in that the users of that will be developers, it makes it a bit senseless tbh.
I am building something like that, but currently only targeting public/private repos and releases. Would be possible to pull more settings from the api, more difficult for private repos though. Hit me up at hello@ambersignals.com
I think your needs are specific enough that you should build your own. To enforce the rules you could include a GitHub bot that runs on all repos and does the checks as part of normal GitHub checks.
Here are two different approaches you could take:<p>(1/2) Migrate to a new way of managing github repo configuration where some system governs what repos are allowed to exist, and ensures they are configured correctly per your company's engineering standards. One way to do this is a "git-ops" configuration-as-code approach where you declare the repos and their configuration in terraform and use the github terraform provider to manage this state via the github API. These terraform files describing the desired state of your repo resources would of course also be version controlled in some github repo.<p>With this approach, github org members are no longer allowed to manually create and configure repos with arbitrary configuration via the easy and familiar click-ops route through the github UI. You could require that all existing and new repos adhere to some standard policy for configuring branch protection, or enforce mandatory code review to terraform changes that propose adding new repos or adjusting the configuration of existing repos. See the github terraform provider: <a href="https://registry.terraform.io/providers/integrations/github/latest/docs/resources/repository" rel="nofollow">https://registry.terraform.io/providers/integrations/github/...</a><p>(2/2) Github exposes APIs you can use to enumerate all repos owned by an org and interrogate their configuration, such as how branches are named, branch protection rules, if reviews are required or tests must pass before merge, etc. You can use these APIs to build a custom repo audit compliance app. It might be a day or three of effort from one competent & motivated engineer to get a basic proof of concept app running that can be pointed at your github org to dump a giant compliance CSV report, provided the engineer is supported by an org admin who can grant the app the appropriate permissions.<p>I worked in a large enterprise with many github repos and saw both (!) of these approaches successfully applied by different teams at different times.<p>I reckon the first approach (switching to a git-ops approach to manage repo using terraform) is the superior solution, but would require changing what is responsible for governing your company's repos, and a corresponding change in engineering culture from "anyone can just create a repo" to "repos are created/modified by a controlled process" so you might need to build some support and buy-in for this kind of change. It would also need work to figure out how to reconfigure all the existing arbitrarily-configured github repos and wrestle them into standardised configuration without disrupting your company's ability to ship and support software.<p>The second approach doesn't require anyone else to change how they're working so there's less friction to rolling it out. This approach doesn't ensure repos are configured correctly but you can periodically run your custom github repo audit app to generate a non-compliance report and then chase up teams to fix their branch protection settings. I worked in a small team that built and delivered a custom internal github app to do this kind of repo audit in a fiefdom of the company that owned a few hundred randomly configured github repos that needed to be audited and configured for compliance purposes. Alas, this github app audit tool wasn't open sourced.