Posted 30th of September, 2022

Securing Github with Allstar

Securing Github with Allstar
Securing the CI/CD pipeline - The good stuff

This is the second post in a series called Securing the CI/CD pipeline - The good stuff co-authored by Mark Curphey and Mike DeLibero. 

Source control management is the most critical developer tool if you work at any company that creates software. Git is the distributed source code management system created by Linus Torvalds to manage the Linux kernel and Github is the most famous platform built on and around Git. Your source code management holds the code for all of the software created in your organization, the crown jewels of intellectual property and a blueprint of your software to hackers and so securing it is not just important but absolutely critical. There have been some high-profile cases of source code being stolen including companies like LastPass, EA Games, Microsoft, and NVidia. 


In this post we will focus on using Allstar, an open-source tool created by Google to automatically check security controls in Github. Allstar was recently transferred to the Open Source Security Foundation, where it is now actively developed and maintained. We chose Allstar as the focus of this post because it is generally considered the “go to” tool for Github security, however it has some weaknesses and gaps if you look under the hood that we are shedding light on here with  tips and gotchas as with the other posts in the series. 

The code for Allstar can be found here

These tips and gotchas are far from a complete list but what we consider important and interesting ones to understand. 


  • Allstar is Not a Complete Security Configuration Tool for Github. You Need More. 
  • Be Aware of Sending Your Vulnerabilities to the OSSF
  • Be Careful Not to Security Shock Developers When Turning On Allstar
  • Don’t use Auto:fix
  • Applying a Security Policy Across Multiple Github Orgs is Easy


Allstar is Not a Complete Security Configuration Tool for Github. You Need More.

The first and perhaps one of the most important things to understand is what Allstar does and does not do. Allstar is a tool to check and optionally enforce a configuration policy on Github.

Allstar does look at controls such as

  • branch protection is enabled
  • no binary artefacts are checked in
  • limit outside collaborators' access
  • presence of a file

All of the current rules Allstar ships with can be found here -

Allstar does NOT however look at your organisation-level security for important controls such as 

  • is multi factor authentication (mfa) required
  • do you have an excessive number of organisation owners 
  • do you have inactive or permissive permissioned GitHub apps installed
  • is dependabot enabled

We are not aware of a really good public list of security controls for Github and therefore unable to create a list showing all the gaps but as you can see from the examples above these are core security controls. 

From the Allstar repo and issues list you can see that there are updates happening such as checking to make sure dependencies are pinned and an interface to create more rules but it is surprising additional policies aren’t available from the community on Github. 

The summary here is that Allstar is very useful but you still need to check a lot more things. Allstar is not a complete security configuration tool for Github. It never claimed to be and you need more. 

Note : When compiling this section we realised that there is a need for a free open source tool to check for additional security controls in Github and a place to capture and document all the security controls that are available. Most of the controls in our opinion would be very hard to add to Allstar given its architecture and so we will be releasing a simple but valuable open source tool written in Go next week.

Be Aware of Sending Your Vulnerabilities to the OSSF

Allstar is an application that uses the Github API to make its checks. The readme explains there are two options to install but in our opinion should do a better job of making it clear that if you select the Quick Start option then you are using a hosted version of the app, hosted by the Open Source Security Foundation that will not only have access to your Github organisation but where you will be likely sending security vulnerabilities about your GitHub setup to.


The installer screen does not clearly show where the app is hosted and what data from your org could be getting sent. Credit where credit is due, Github does an excellent job of showing you what access is being requested. 



We love and trust OSSF but you may not. Be aware and if in any doubt host it yourself. 

Note : We will be submitting a PR to Allstar in the coming weeks to improve this. 

Be Careful Not to “Security Shock” Developers When Turning On Allstar

When the readme of a project calls out how to disable unwanted issues before the getting started page you need to sit back and think. 


The first element of the configuration file in the quick-start is <code>security.yaml</code> defining an inclusion strategy.

<code>optOutStrategy: true</code> means that all repos will automatically subscribe to the policy. Allstar defaults to using  <code>action: log</code> if no action is specified which sends all findings to the Allstar app log (yes OSSF if you used the hosted quick start, see above). Most people manage their issues in GitHub and not a log file and want to be transparent with developers encouraging them to know about and fix their own issues. The initial configuration typically looks like the one below. 



  optOutStrategy: true

action: issue



The result however is that once deployed, Allstar will create one issue for each policy violation in each repo. Yes, hundreds if not thousands of issues across your org. If you are a developer subscribed to notifications on just a handful of repos you will get “security shock” and to make it worse most of the issues will likely be repetitive across each repo. There is nothing worse than automatically sending loud security noise and putting what is likely going to be considered appsec busy work on a developer. 

On top of this if an Allstar issue has not been fixed in 24-hours Allstar will then 'ping' the ticket which in turns leads to developers getting an email every day until it is fixed. Currently there is no way to configure this to change the time window or to turn it off. This usually results in email filters created by developers to blanket ignore Allstar findings. 

So how do you make security visible and transparent without creating noise? One option is to use <code>issueLabel</code> and <code>issueFooter</code> to ensure that all issues are tagged to be clear what they are in order to ensure that the text injected into the issue footer is very clear about who has enabled these checks and what the expectations of dealing with the issues is. 

You can set a single repo where all of the issues from all repos are sent using <code>issueRepo</code> and you could also of course tag issues as “Allstar Informational - No Action Needed ”, making them visible to developers and use the GH api to pull org wide issues back to the central view or use a Github project (projects now support multiple repos), if you plan to remediate yourself. 

Don’t Use Auto:fix

You may be tempted to set your action when you find a policy violation to <code>options:fix</code>. I mean who doesn't want self-healing configurations right? Putting aside the fact developers get freaked out when settings change, it turns out that not much in a policy can be fixed for example a missing A quick fix for this is to setup an organisation wide detailed here

Allstar can only have either issues, log or fix enabled but not more than one at a time so if you enable fix and it doesn't happen there will be no record of it (ie it wont log) and therefore no record if there is a policy violation. It also turns out that the only policy that can automatically fix itself is branch protection which means only one out of the six main policies in a default deployment will actually be effective if you set all policies to <code>options: fix</code>.

We recommend you don’t use Auto:fix. 

Applying a Security Policy Across Multiple Github Orgs is Easy

When you need to install Allstar under each GitHub org that you want to be monitored, you can set a base configuration in one organisation and use it throughout the other organisations. To do this, create your main .allstar repo in the GitHub organisation that will be the primary policy. For every other GitHub organisation, you create a new .allstar repository with a single “allstar.yaml” file with the following code.





You will need to make sure that the .allstar repository that is holding the base configuration is public so that it is accessible by all of the other GitHub organisations.

Next up in the series we will talk about pre-commit hooks and github actions.