Identity and Access Management has always been a major area of concern and focus for organizations, across all the different systems in the estate, including source control management systems (SCM), and specifically GitHub. Organizations spend a great deal of time in optimizing security and governance over identities in the SCM – both human and programmatic.
Inadequate Identity and Access Management, is the second risk of the “Top 10 CI/CD Security Risks”. It refers to “the difficulties in managing the vast amount of identities spread across the different systems in the engineering ecosystem, from source control to deployment. The existence of poorly managed identities – both human and programmatic accounts – increases the potential and the extent of damage of their compromise”.
Many organizations rely on integrating GitHub with SSO as a primary control for addressing Identity and Access Management risks within their GitHub organizations. However, SSO is only available for organizations using the GitHub Enterprise license. In addition, While SSO is indeed a strong control, it must be configured properly and must exist alongside some additional measures in order to provide optimal posture around Identity and Access Management risks.
In this blog we will dive into three major risks which organizations using Github should be aware of in the context of Identity and Access Management.
SSO in GitHub
GitHub organizations are shared accounts that enable simultaneous collaboration and administration across multiple repositories. Both business and open source project maintainers utilize these organizations, as not only do they enable centrally managing configurations that impact all of the organization’s repositories and members such as branch settings, labels, and organization webhooks, but also create a security baseline, for example setting permissions, repository visibility, and enforcing two-factor authentication (2FA) on user accounts.
A primary benefit of a GitHub organization is the ability to manage access controls across multiple projects. An important access control security feature offered by GitHub is single sign-on (SSO) authentication that enables organization members to securely authenticate across multiple platforms by using one set of credentials through an identity provider (IdP).
SSO can also be combined with a System for Cross-domain Identity Management (SCIM) layer on top of SSO. The implementation of a method to manage user identities such as SCIM allows to automatically add, manage, and deprovision organization members access to a GitHub Enterprise.
The benefits for a company managing members through SSO and SCIM include setting and controlling a password policy, configuring and enforcing a 2FA mechanism aligned with the company’s standards, and providing users with a single password, freeing them from the hassle of remembering multiple passwords for different systems and software. A significant benefit of implementing SSO in an organization is the capability to restrict user access to a corporate ecosystem by requiring authentication through the company’s email address.
As great as it sounds, there’s a major drawback – SSO is only available for the premium GitHub Enterprise plan. Lesser licenses such as GitHub Team, which are in wide use, don’t support SSO. As a result, organization membership may be based on GitHub based identities only.
Challenges with Organization Membership
GitHub is the most popular SCM. It is widely used by developers, and it’s very common for developers to have private GitHub user accounts for their private use, to maintain private projects or to contribute to open-source projects. Developers tend to like using their private accounts in companies that they work for, as they provide the ability to centralize and manage all their projects and work under one user account.
In GitHub organizations not enforcing SSO authentication, the organization owner can invite new members to join GitHub through either their email address or GitHub username. These methods open the door to inviting developers to become members of a corporate GitHub organization using private user accounts. Once accepting the invitation and becoming organization members, there’s no way to view the user accounts’ email addresses that were used to sign up to GitHub. Not even the organization owner has the ability to view the address.
We should mention that there is an option to view email addresses of GitHub user accounts if users decide to show them in their profile. However, that’s not the default setting, and the vast majority of users don’t reveal their emails in their profile.
By not employing SSO, organization owners are required to manually validate that each invited user uses the corporate’s email address, even if the user supplied the owner with their GitHub username for the purpose of the invitation. Also, owners will also have to constantly keep track of the accounts’ email addresses to verify that they were not changed from a corporate’s email address to a private one. This is a very challenging and expensive task in a large organization with a large workforce.
Risk #1: Private Email Addresses in GitHub Accounts
Without SSO authentication, organizations face a challenge ensuring that all employees, especially developers, don’t use their private user accounts in their GitHub organization, as the security of employees’ private accounts registered with an email address from a domain not owned or managed by the organization is highly dependent on the security of the external accounts they are assigned to. Since these accounts are not managed by the organization, they are not necessarily compliant with the organization’s security policy. The baseline security level of the organization and its connected assets such as code, artifacts, and CI integrations will be set to the security level of the employees’ private email addresses, which as mentioned above is completely out of the company’s governance. Attackers that gain control over the user’s private email account, can use GitHub’s password recovery mechanism to set a new GitHub password and use it to login.
All the effort and resources that the company invests in creating security frameworks to protect their assets, including implementing SSO authorization for the systems in use by the company in order to secure employees’ mailboxes, applying anti-phishing mechanisms and so on, become redundant if an attacker takes control of an employee’s private email address associated with a GitHub organization account, potentially compromising the account, and leaving the GitHub organization exposed to attacks.
It is highly recommended to establish a protocol where employees create a dedicated account upon onboarding, tied with their corporate email address to avoid a situation where new employees join the GitHub organization using their pre-existing accounts.
In addition, this risk can be significantly reduced by enforcing 2FA in the GitHub organization. 2FA is available for all types of GitHub’s licensing plans.
Risk #2: Ghost Accounts
Another risk that might occur when not implementing SSO authentication for GitHub surfaces when offboarding employees. When employees leave the company, best practices require that an offboarding process should take place to ensure all of their user accounts across the different systems used by the company are disabled or deleted, to prevent any user access to these systems.
GitHub organizations integrated with the corporate SSO authentication solution prevent the user from accessing company systems after the user account is disabled in the IdP.
However, when the authentication in the GitHub organization is based on GitHub based identities and not on SSO, disabling user accounts of offboarded employees in the IdP won’t affect their GitHub user accounts, and these user accounts would stay a member in the GitHub organization. To remove members from the organization, the organization owner has to identify members by their username, and remove them from the organization during offboarding, or else the users will still be capable of accessing the organization and its different resources.
Offboarded employees in possession of non-IdP GitHub accounts (which have not been manually removed), will still be able to log in to GitHub, even after their identity (including their corporate email) is deprovisioned in the IdP, as the GitHub authentication is not validated against the corporate IdP.
The combination of risks #1 #2, i.e. accounts which are both non-IdP as well as linked with a non-corporate email exist, creates an even greater expansion of the potential attack surface of the corporate’s GitHub organization.
Companies not implementing SSO to authenticate their GitHub user accounts tend to fail to hermetically disable user accounts belonging to offboarded employees. Unless an external inventory of accounts storing all of the organization accounts’ usernames and email addresses is carefully maintained, removing or disabling private user accounts can only be manually executed (or by the usage of custom scripts), requiring extraordinary resources. This is where private GitHub user accounts fall through the cracks and can potentially remain part of the organization forever.
Risk #3: Is the User Really Offboarded?
In the two risks detailed above, we described issues that originate from the fact that a company doesn’t manage its GitHub users through SSO.
Companies which do manage their users through SSO might believe that the entire employee management lifecycle from onboarding to offboarding can be seamlessly and thoroughly managed through the IdP. However, when SCIM isn’t implemented, that’s not precisely correct, and the corporate remains exposed to a major risk..
According to GitHub documentation, while the creation of SSH keys or PATs (Personal Access Tokens) require authorization through SSO, these credentials persist even if the associated user is deactivated in the IdP. In fact, deactivating the user in the IdP only prevents the user from re-authenticating to GitHub’s website, while the GitHub user will still remain an organization member and have full access through any of their SSH keys and PATs.
This leaves the average organization with countless stale programmatic credentials which can be leveraged by adversaries, exposing the corporate to “Insufficient Credential Hygiene” risks.
The organization owner will be actively required to remove the user account from the GitHub organization to revoke these sets of credentials.
An implementation of a solution such as SCIM on top of SSO ensures that user deactivation through the IdP will automatically deprovision the GitHub user from the GitHub organization, restricting any types of existing and future access.
Summary
Identity and Access Management risks are a high priority for any security team responsible for protecting the organization’s SCM.
As the SCM is the gateway to a corporate’s entire CI/CD ecosystem, Inadequate Identity and Access Management issues in the SCM can lead to compromising not only the assets stored in a GitHub Enterprise, but in other systems as well, including production.
Integrating GitHub with SSO is a strong control which can address many of the key Identity and Access Management risks. However, numerous risks are still highly relevant even when SSO is in use, around both human and programmatic access.
While addressing these risks is not a trivial task in complex environments, it is definitely achievable. Cider Security spends a great deal of time assisting organizations to optimize their CI/CD Security, with a strong emphasis on Identity and Access Management.
