GitHub is a tool central to many developers’ workflows, especially those who work in teams and large organizations. It allows developers to collaborate and work together, always ensuring their code is up to date, even if they’re working halfway across the world from each other.
However, when so much of a team’s productivity and performance is riding on one tool, it’s important that only the intended team members have access to it. All the developers on the project need to be able to quickly and easily commit new code, without anyone who’s not a part of the team being able to do the same. This code needs to be secured from the moment it’s written all the way until it makes it into production.
GitHub is used by some of the largest organizations in the world and there are numerous security measures in place to allow for secure workflows. In this article, we’ll look at how to manage access control, create a security policy for your project, make sure your repository and metadata are backed up, and implement a recovery plan in the event that access is compromised.
Access Control
For a particular repository, on the Settings screen, you’ll find a tab called Manage access. This is where you’re able to manage the various levels of access to your repository. If the repository is part of a larger organization, you’ll find information here about who in the organization can access this repo based on the organization’s settings. This is where you can change a repository from public to private or vice versa.
But this is also where you can set specific permissions for contributors to the repository, which is a very important thing to do properly, especially if you’re working with contractors or other developers outside your immediate team.
There are five levels of access you can give to contributors:
- Admin: As the name implies, this role gives a contributor basically full access to the repository. They can add and remove contributors, open and manage issues and pull requests, as well as higher-level actions like deleting the repository or making it public. Generally, you want this capability assigned to only one or two people.
- Maintain: This level can push and pull code to the repository as well as manage issues and pull requests. It has some repository-level settings but restricts the most potentially destructive ones. This is great for someone who shouldn’t be able to perform higher-order repository functions like adding contributors or deleting the repo entirely, but who still needs relatively broad access to be able to do their job effectively. Project managers could fall under this role, as could open-source maintainers (hence the name of the role).
- Write: Users with this role can push and pull code as well as manage issues and pull requests. They have no access to repository-level settings but can still function fully as a developer with the permissions included in this role. This is the access that most developers should have.
- Triage: This level gives a user read-only access to the code as well as the ability to manage issues and pull requests. It’s great for a project manager or other position that won’t be writing code but can still benefit from access to the repo and specifically access to issues.
- Read: This lowest permission level allows a user to read and clone the code, as well as create issues and pull requests but not manage them. This is perfect for truly outside contributors who should only contribute code via pull request. This is also the default permission level that anyone has on an open-source repository that’s not their own.
Assigning roles to users accurately is a very important part of your GitHub workflow. Insufficient permissions could create a bottleneck where legitimate users have to ask a higher level user to perform some action they should be able to do themselves. On the other hand, giving users overly broad access opens up the repository to attacks if a particular user’s account is compromised.
Just as important as giving users the correct permissions when they’re joining a project is making sure they’re removed from a project when they leave. By keeping a close eye on your user permissions list, you can ensure that only the people who should have access to a given project do actually have that access. Companies with strong security policies implement automatic off-boarding of all user permissions when an employee leaves the company. This goes a long way toward keeping your project secure.
Security Policies
GitHub now supports adding security policies to any repository. When you add a security policy to a repo, you’re letting users know how to properly disclose security issues and defining a process by which you’ll fix them.
Under the Security tab of your repository, you’ll find Security policy in the sidebar. This will walk you through how to draft a security.md file that will be included in the root of your repository. This will provide information to users about how to disclose vulnerabilities and detail the process that you’ll go through to address them.
Once this file is in place, it will also be mentioned any time a user opens an issue. This ensures that security vulnerabilities aren’t disclosed in the public issue tracker (where they can be exploited) but are reported in a responsible way so they can be fixed before being reported to the community at large.
These security policies can be relatively simple, but should at the very least define what versions of the software are supported, what versions are receiving security updates, and what versions have been declared “end of life.” In addition, there should be information about the best way to disclose a vulnerability, whether that’s a dedicated email, a tool like HackerOne, or some other method.
Backups
Even the most security-conscious team needs to have a solution for events that might be out of their control. To this end, ensuring you have backups of all your code and other data associated with your repository is crucial. While there are many solutions such as taking a local backup or cloning down the project to an offsite backup solution or cloud storage, a good backup solution needs to exist on its own, or it’s not really a backup.
By using a third-party backup service like BackHub (now part of Rewind) you get the convenience of knowing these sorts of backups are taken care of for you and the security of knowing you can get your backups restored and get back to work quickly in the event of anything going wrong with your repository. You never want to wonder whether your backups are actually working or whether you’ll be able to restore from them.
One way or another, you need a recurring backup solution to make sure that in the event of a failure all your hard work isn’t going to waste. However, taking backups isn’t worth much if you don’t have a recovery and restoration plan to put those backups to work if they’re needed.
How many GitHub users are in your organization?
Recovery Plans
If you’re saving regular backups of your repository, you’ve won half the battle. The other half is being able to restore these backups in case of a failure or security breach of your repository. It’s important to have a recovery plan in place so you’re not trying to decide what to do when there’s already been a failure.
Some key points to include in this recovery plan are:
- Who is in charge of getting the latest backup and actually doing the restoration?
- How will the fact that there’s been an outage be communicated to all the necessary stakeholders? (Executive team, project managers, developers who contribute to the repo, etc.)
- How are backups tested and how frequently are these tests run?
It’s important to frequently test your backups by running failover tests. This basically entails taking a recent backup and making sure members of the team can use that backup to create a working version of the environment that the code usually runs in, as well as contribute to that version of the repository. As closely as possible, this simulates what the team would have to go through in the event of an actual outage, so that everyone is well-prepared.
Good Security is Multifaceted
A proper security plan includes many different aspects of security. However, by putting all of these layers together, you can ensure that you and your team can work effectively using GitHub while still making sure your codebase is secure and safe from attackers.
Integrating the first-party security tooling that GitHub provides directly with the increased functionality of a tool like BackHub, you can be sure that no matter what the world throws at you, your project will be safe and secure when the worst happens.
Discover the easiest way to automate the data security of your GitHub repos with a free trial.
Keanan Koppenhaver">
