Threat model for GitHub repositories

This document focuses simply on the threats to a repository on GitHub, given that the decision has already been made to host the repository on GitHub. The focus is on vectors which can be influenced by a GitHub organization owner or repository administrator.

The following assumptions are made:

• The integrity of the GitHub platform itself is assumed to be safe and secure.
• There are no malicious acts taken by insiders.
• Third party extensions (i.e. applications) do not contain malicious code.

Given those assumptions, the remaining path is using compromised credentials to gain unauthorized access to a repository's resources. GitHub does not have a very fine grained permissions model for humans, basically read, write, & delete (administrator) access.

Of course, if the user's password is leaked, stolen, or otherwise compromised, the attacker can impersonate the user fully.

In addition to credential compromise, GitHub allows users to grant access to agents in several ways:

• Via a Personal Access Token (PAT) generated by the user. A PAT can be limited to a subset of permissions. The PAT can not be restricted to a subset of resources.
• Via authorizing the creation of a token via an OAuth exchange. During the OAuth exchange, the token requests a set of permissions. That set is either accepted or rejected by the user. The OAuth token can not be restricted to a subset of resources.
• Via addition of an SSH Public Key to the list of SSH keys authorized to identify the user during a git operation. The SSH key has the same rights and scope as the user, but is limited to git operations.

In general, the repository administrator has no visibility into any of the actions that could cause the creation of unauthorized tokens. (See possible attacks for details.) However, there are some steps that can be taken to mitigate or detect the use of unauthorized tokens on their repository.

• Have the organization's owners require 2FA be configured before explicit access to the organization's resources can be granted (including the repository of interest). This is a configuration setting that will be enforced by GitHub.

• Modify the commit workflow to require signed commits for (at least) significant milestones (merges, releases, etc.).

• Enable branch protection on (at least) the production branch(es). The restrictions should apply to administrators as well.

• Deploy a status check which verifies the signature on a "Verified" commit came from an authorized key. This countermeasure does add some extra administration, as the GPG keys of authorized committers will need to be maintained or certified.