Hosting your code in GitHub can be incredibly convenient for your Engineering team, but it also comes with the possible risk of code leakage, either through lack of visibility, misconfiguration or through contractor error. This guide covers some of the basic measures you can put into place with UpGuard Core to make sure our DataLeaks team doesn't find anything.

Overview

Our DataLeaks team routinely finds code and credentials stored in GitHub accounts that have been intentionally or unintentionally exposed. The fault usually comes down to either:

  • the repository being accidentally set to public instead of private
  • a non-authorized user being added as a collaborator to a private repository, accidentally
  • the private repository being forked by a contractor and that fork being left public
  • a valid user's account is compromised and that account does not have MFA/2FA enabled

While the UpGuard DataLeaks product can be used to routinely check if code or credentials have leaked outside of the GitHub repositories you control, you can also use UpGuard Core to monitor your own repositories. This guide talks about some of the basic checks you can include in Core to monitor your GitHub account and repositories.

GitHub Account

A GitHub Organization node type scans the configuration of your GitHub Account on a daily basis and records items such as your public profile, your subscription information and the users and teams defined under your account. For more information on how to start monitoring your GitHub Account, please visit our guide on Adding GitHub Nodes.

Once you have your GitHub Account being monitored on a daily basis you can import some of our GitHub best practice policies from our Policy Library.

In particular, the GitHub Users MFA Check policy validates that all members allowed access to your GitHub account and repositories have MFA enabled. This helps to protect access to the user accounts that have direct access to your code.

Another recommended policy is the GitHub User Identity Check policy which enforces that every user allowed access to your account has their proper full name set in their profile. It is common practice in some Engineering teams to allow users to use their personal GitHub accounts for work repository access as not everyone’s full name is available as a GitHub username. Enforcing a user’s full name to be set in their profile allows you to put real identity to the username happyCoder345, for example. Since scans occur on a daily basis you are then able to keep an audit trail of who has access to your account and when.

GitHub Repositories

The GitHub Repository node type scans the configuration of each repository in your GitHub account on a daily basis. The scan includes the users and teams that have access to that particular repository, as well as the type of access they have. These types of configuration items can sometimes change often as you hire new Engineers or move Engineers between different projects, so it’s recommended to be alerted when these things change as opposed to enforcing particular settings using a policy.

For example, it may be enough to post in your open Engineering slack channel when a particular user or team assigned to a repository changes. Here you would create a new Event View with the query

type=Node Changed AND variables.node=The Name of My GitHub Repo Node

and attach the appropriate Slack notification action to this event view. For more information on creating event views, please refer to your guide on Filtering Events and Creating Views. For more information on how to attach an action to an event view, please visit our guide on Event Actions.

The GitHub Repository scan also contains general configuration information about the repository itself. In particular, to keep track of some basic security settings, we recommend importing the GitHub Repository is Private and GitHub Repository is not Forked policies from our Policy Library. These policies help you confirm that all of your GitHub repositories are private (and not public) and that they haven’t been forked (for example, by a lazy contractor), respectively.

What Next?

If you are interested in other Basic Best Practice articles, please visit our guide on Setting up SSL Certificate Expiry Alerting.

If you would like more information about the UpGuard DataLeaks product, please contact your Technical Account Manager to set up a free demo.

Tags: policies