How to secure your GitHub organization and enterprise account

Rome wasn’t built in a day, and neither is enterprise software. While the amount of time it takes to complete a software project can vary (Soltech estimates it typically ranges from four to nine months), many aspects of the process are constant. Whether it is the exceedingly vague requirements (heads up, those just changed again), the legacy code written in Gibberish++, or accidentally drinking decaf, development comes with many challenges.

If your inadvertent caffeine deprivation wasn’t bad enough, imagine how bad your day would be if the code your team had been working on for months was leaked, deleted, or stolen. We understand how much hard work goes into development, and we want developers to be able to focus on what truly matters to them—their code. With GitHub Enterprise, you can easily add secure software development best practices to your organization with features that control who has access to your code, as well as what they can do with that access.

SSO

Secure software development begins at login, and as is the case with most enterprises, this means starting your day within an identity provider (IdP) like Azure AD, Okta, or Onelogin. GitHub Enterprise’s SAML integration accommodates the different structures and workflows established on GitHub, as admins can set up their SSO flow at the enterprise account level, or more granularly at the organization level.

Configuring authentication is just step one. You can leverage additional features such as team sync and SCIM provisioning with selected providers to improve the experience and security of team management.

Another key benefit of integrating with your enterprise’s IdP is the fact that you can leverage their access controls and sign on policies, which then have a downstream impact on GitHub. For example with Azure AD, you can establish conditional access requirements based on IP and/or multi-factor authentication requirements.

Additional authentication

If you would prefer to avoid changing access controls and policies within your IdP, GitHub has natively built in solutions for those added access controls.

With GitHub’s IP allow list, org admins can restrict access to your organization’s assets by configuring a list of approved IP ranges. This way, you can limit unwanted exposure and ensure that users are on specific portions of the network or connecting through a VPN.

Another important access control that GitHub supports is two-factor authentication (2FA). (For those who are unfamiliar with this, there is another blog post—from a great author—that dives a bit deeper into it here). The set up process is relatively painless, but the added protection is significant. One important caveat to note is that this will kick out organization members and collaborators who do not have 2FA enabled, so we highly recommend admins do this carefully and reach out to their GitHub team prior to doing this.

Specific policies for minimizing data loss

In addition to establishing proper authentication mechanisms, defining appropriate permissions is another essential step to secure your GitHub organization. GitHub Enterprise offers easy to apply policies, configurable at both the enterprise account or organization levels, to ensure administrators  can take a proactive approach to defend against possible data leaks.

Some of the most important settings we suggest reviewing to ensure proper access controls are in place based on your organization are:

Repository creation

Repository forking

Repository visibility changes

Repository deletion and repository transfer

As important as these integrations, policies, and access controls are, it’s just as important to keep improving the security posture of our platform while continuing to empower developers.

One example of a recent improvement in the repository creation flow is setting default repository visibility. While configuring appropriate policies is paramount in preventing accidental data leakage, organizations were still finding that developers would accidentally create public repositories when they should have been private. (If this sounds familiar, trust me, it happens to everyone, because aggressive deadlines happen to everyone.) Developers still have the option to choose their repository visibility, but now, if they have an active SAML SSO session, the default is set to private instead of public.

GitHub knows that platform security is a must. We are considerate of both the big and small use cases, whether it’s integrations with SAML 2.0 providers or improving the user flow when creating a new repository with a default visibility. GitHub makes it a priority to ensure these integration and workflows are seamless with both the developer and admin experience in mind.

Looking to learn more?

Come see best practices for securing your GitHub organization at our next GitHub Demo Day on July 31, 2020 at 11am PT hosted by myself, and Sarah Khalife of our Enterprise Solutions Engineering Team. Sarah and I will be digging deeper into the benefits of setting up SAML/SCIM integrations, enforcing policies to protect from code leakage, platform security, and more.

Want to start using GitHub to better secure your code?

Contact your account management team or the GitHub Sales Team to see how GitHub can help your engineering team build better, more secure software together.

Written by

Niels Pineda

@nielspineda