Security best practices for GitHub Enterprise Server

Whether it’s at the network, transport, application layer, or any of the other layers, security has become the top priority for many organizations. With this in mind, we’re focused on expanding Enterprise Server security features to promote secure collaboration, while freeing up your admin’s time.

As important as it is, security is rarely the primary focus of developers and other contributors. By following certain practices and using advanced features with limited setup, GitHub Enterprise admins can easily set up a secure development environment without inhibiting collaboration. And by working alongside our services team, your organization can make sure you are maximizing the security of your GitHub Enterprise Server instance.

Password practices

Like many things in technology, security begins at log in. Weak passwords are the equivalent of cheap locks protecting your team’s most important assets. Enforcing password guidelines can be difficult for admins, but we can help. With GitHub, certain password conditions must be met, and we also put together a quick guide on password best practices.  

Our first recommendation is to use a password manager, like LastPass or 1Password, to generate and store your passwords. Both applications provide functionality to help with our second suggestion, which is generating a unique password with a combination of characters, numbers, and symbols. It may not seem like it needs to be stated, but once you’ve created your password never share it with others, even if they’re potential collaborators.

Two-factor authentication

Ideally, everyone follows the same guidelines for password creation and storage, but unfortunately, outside of GitHub’s minimum password requirements, Enterprise admins may have little control over this. This is why we highly recommend that admins require two-factor authentication (2FA) for your organizations. 

 Two-factor authentication adds a second step to the standard sign-in process. It’s often referred to as using “something you know” and “something you have.” Initially, you begin by first entering your password—something you know—followed by an additional key or pin that’s generated by something that you have, which is most likely to be your phone.

While services can differ in their mechanism for “something you have”, many services, including GitHub, use a time-based one-time password (TOTP). The initial setup for TOTP is straightforward, requiring a TOTP app like 1Password, Authy, or LassPass Authenticator. We also highly recommend setting up recovery methods for 2FA, in the event that you lose access to your 2FA credentials. Even though adding 2FA to the login process seems minor, it’s a very significant upgrade when it comes to securing accounts.

Additional methods of authentication using SAML, CAS, or LDAP

Our next best practice is becoming more and more common with GitHub Enterprise admins: integrating a GHE-S deployment with SAML, CAS, or LDAP. These integrations allow GitHub Enterprise admins to fine-tune control of GitHub Enterprise, provision user accounts and access, and add another important layer of security to GitHub authentication.

Along with securing your instance, these tools provide GitHub Enterprise admins the ability to manage the number of licensed seats in use at any given time. Encouraging secure collaboration, admins can leverage Enterprise Server’s built-in authentication for users outside your identity provider. If you have contractors or machine accounts who don’t have access to your identity provider that uses LDAP, SAML, or CAS (they shouldn’t!), you can configure built-in authentication to confirm access for these users and enforce 2FA.

Access control

For GitHub Enterprise Server, access control doesn’t stop at the integrations with any Active Directory and identity provider. Once users are granted access to your GitHub instance, it’s important for them to have the correct permission levels to access any appropriate teams, repositories, and organizations. This is why we often advise that Enterprise admins employ a least privilege model. In this approach, GitHub Enterprise admins initially give only the necessary permissions to their users and extend or restrict their access as needed. This design helps make sure that information is shared with only the appropriate teams, which limits the risk for improper exposure. We highly advise you to comb through your user base and make sure only the necessary read, write, and admin permissions are assigned.

GitHub offers several options in settings that all GitHub Enterprise admins should look through and carefully provision:

• Restricting repository creation is vital to prevent users from exposing information in a public repository
• Branch protections and status checks can be enabled in various forms to make sure that users can efficiently and safely merge commits and manipulate branches
• The ability (or inability) to fork private repositories is a setting we encourage Enterprise admins to check as another potential way that users may inadvertently expose or share code with unauthorized parties and accounts

Enable security alerts for vulnerable dependencies

The admin-based pieces of security are essential in securing your Enterprise Server instance, but making sure that your developers can code efficiently and securely is just as important. Dependency tracking becomes exponentially more difficult as the number of dependencies and projects grow. And while we want to continue to empower the developer community to use various open source libraries, we also want to make sure they’re safe. GitHub helps you accomplish this through enabling security alerts for vulnerable dependencies. 

By connecting your Enterprise Server to Enterprise Cloud, you can sync vulnerability data to your server instance every hour or manually to run on your schedule. This knowledge-base of vulnerabilities supports multiple languages, and it incorporates the National Vulnerability Database, maintainer security advisories on GitHub, and a combination of machine learning and human review to detect vulnerabilities in public commits on GitHub. Leveraging these sources, GitHub automatically identifies repositories in your instance that use potentially vulnerable versions of your dependencies.

GitHub Enterprise admins can then determine and set up the proper delivery method for these notifications, making sure that this information is sent in the proper form. The cadence and format are entirely up to each organization’s workflows, but the most important factor is to ensure alerts are escalated for people to properly review and remediate any concerning vulnerabilities.

Logging and auditing

If your organization is using a log aggregation tool capable of ingesting logs via syslog, GitHub Enterprise uses syslog-ng to forward system and application logs to these systems. This allows admins to monitor deployments proactively through their log aggregator tools like Splunk and Logstash.

It’s important to use some of these key features from the start, but periodic checkups of your instance are also beneficial for a secure and efficient deployment. The audit log dashboard enables admins to oversee actions performed by users and organizations across their deployments within 90 days. Searches can range from actions performed in repositories, to what country, date, and time actions occurred. Although this may not be a regular practice, it’s important to understand how this dashboard can be used to investigate any concerning changes made to a deployment.

Another important aspect of server security is the proper auditing and management of users and SSH keys. We recommend that admins set their dormancy threshold in user settings (with the option of 30, 60, 90, or 120 days). They should also periodically look through dormant users to suspend or remove their account, which frees up a user license and ensures that unauthorized users aren’t left lurking. Similarly, admins should occasionally run instance-wide audits of SSH keys. This prompts users to approve or reject any existing SSH keys before they’re able to take action on any repositories, providing a quick safeguard for internal resources from being accessed by SSH keys that should be potentially revoked.

Bringing it all together

Taking advantage of native features, integrating with additional tools, and auditing logs are all practices that strengthen the security of your GitHub Enterprise Server, but with any product, maintenance and checkups are essential.

Need help with setup or maintenance of GitHub Enterprise Server? The GitHub Professional Services Team provides many offerings focused on complementing and enhancing your organization’s secure workflows and management. You can get help with admin training, API integrations, data configuration, and insights consultations. These insights aim to give your team a comprehensive review, analysis, and report of your organization’s security and software development practices. Reach out if your team has any questions.

Learn more about GitHub Professional Services

Written by

Niels Pineda

@nielspineda