Identity and access management (IAM) has always been an area of focus for organizations, particularly when it comes to source control management systems (SCM). And rightly so — inadequate identity and access management is one of the top 10 CI/CD security risks.
IAM focuses on properly managing the large number of both human and programmatic identities existing in an organization’s ecosystem. Within the context of IAM for their SCM — such as GitHub — organizations need to optimize their security and governance over all identities in their SCM. In doing so, they can ensure they’re protected from account compromise, which bad actors can leverage to access the production environment.
Many organizations integrate GitHub with single sign-on (SSO) and use that as a primary control to address IAM risks within their GitHub organizations. But this practice isn’t as straightforward as it seems. To start, SSO is only available for organizations using the GitHub Enterprise license. And while SSO is a strong control, it must be configured properly and must exist alongside additional controls to properly protect organizations from IAM risks.
Single Sign-On (SSO) in GitHub
GitHub organizations are shared accounts that enable simultaneous collaboration and administration across multiple repositories. Both business and open-source project maintainers use these organizations because of their valuable functionality. GitHub organizations enable centrally managed configurations that impact all of the organization’s repositories and members — such as branch settings, labels and organization webhooks. They also create a security baseline by configuring permissions, setting repository visibility and enforcing two-factor authentication (2FA) on user accounts.
GitHub organizations also enable the ability to manage access controls across multiple projects through features like SSO. With SSO, organization members can securely authenticate across multiple platforms by using one set of credentials through an identity provider (IdP).
Companies can also combine SSO with a system for cross-domain identity management (SCIM) layer. Adding SCIM on top of SSO allows you to automatically add, manage and deprovision organization members’ access to a GitHub Enterprise.
Managing members through SSO and SCIM helps organizations to set and control a password policy, configure and enforce a 2FA mechanism aligned with the company’s standards, provide users with a single password and other security tasks. Implementing SSO also helps restrict user access to a corporate ecosystem by requiring authentication via the company’s email address.
While SSO is an important tool for IAM, it’s only available in the premium GitHub Enterprise plan. Other widely-used licenses, like GitHub Team, don’t support SSO, which introduces important security considerations that teams must consider as they adopt IAM best practices in their organization.
Let’s dive into the top three IAM risks associated with GitHub organizations. Along the way, we’ll cover IAM best practices to keep your organization secure.
Private Email Addresses in GitHub Accounts
Because GitHub is the most popular SCM and is used extensively by developers, it’s common for developers to have pre-existing GitHub user accounts for their private use. Developers typically prefer to use their private accounts while doing work for their company because it’s easier to centralize and manage their projects and work under one user account. But this isn’t a best practice, as private email addresses introduce a host of security concerns.
When employees use private email addresses, the security of an employee’s GitHub account is highly dependent on the security of the external private email account to which it’s assigned. The baseline security level of the organization and its connected assets — such as code, artifacts and CI/CD integrations — will be set to the security level of the employees’ private email addresses, rather than the organization’s security level.
If attackers gain control over the user’s private email account, they can use GitHub’s password recovery mechanism to set a new GitHub password and use it to log in. From there, they can compromise the GitHub account and instigate an attack on the GitHub organization.
To protect your organization from these risks, follow key best practices. First, establish an employee onboarding protocol where new hires create a dedicated GitHub account tied to their corporate email address.
You’ll also want to enforce two-factor authentication (2FA) in your GitHub organization, which is made available on all GitHub’s licensing plans.
Ghost GitHub Accounts
Another GitHub IAM risk arises when offboarding an employee. As a part of the offboarding process, you’ll want to ensure all their user accounts are disabled or deleted to prevent future access to the organizations’ systems.
When GitHub organizations are integrated with the corporate SSO authentication solution, users can no longer access company systems once the user account is disabled in the IdP. This process maintains IAM best practices.
But if your GitHub organization’s authentication is based solely on GitHub-based identities and not SSO, disabling the user accounts of offboarded employees in the IdP won’t affect their GitHub user accounts. This means that offboarded employees will retain access to their user accounts.
To remove members from the organization, the organization owner will need to manually identify members by their username and remove them from the organization during offboarding. If this practice isn’t consistently applied during the offboarding process, and private email accounts are allowed to access GitHub, then your organization is vulnerable to IAM-based attacks.
Don’t discount how challenging — and time-consuming — it is to completely disable offboarded employees’ user accounts. To reduce your attack surface, enable SSO.
If your GitHub license doesn’t support SSO, you’ll need to carefully maintain an external inventory of accounts storing all organization accounts’ usernames and email addresses. Without this inventory, you’ll need to manually remove or disable private user accounts — or use custom scripts to do so. User accounts can otherwise fall through the cracks, leaving them to remain an indefinite part of the GitHub organization.
Is The User Fully Offboarded?
In the two risks detailed above, we described issues that originate from managing GitHub users without SSO.
Companies that manage their users through SSO might believe the employee lifecycle, from onboarding to offboarding, can be thoroughly managed through the IdP. But even with SSO, the organization is still exposed to IAM risk if it hasn’tproperly implemented SCIM.
According to GitHub documentation, while the creation of SSH keys or personal access tokens (PATs) 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 reauthenticating to GitHub’s website. This means that the GitHub user will remain an organization member and have full access through any of their SSH keys and PATs.
These stale programmatic credentials expose your organization to risks associated with insufficient credential hygiene — yet another top 10 CI/CD security risk. To revoke these credentials, the organization owner will be required to manually remove the user account from the GitHub organization.
Implementing 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.
Addressing IAM Risks in Your GitHub Organization
Identity and access management risks are a high priority for any security team responsible for protecting the organization’s SCM.
Because SCM is the gateway to a corporate’s entire CI/CD ecosystem, inadequate IAM practices in the SCM can lead to the compromise of not only the assets stored in a GitHub Enterprise, but in other systems as well — including production.
That’s why it’s important to integrate GitHub with SSO while also adopting other best practices to protect your organization from IAM-based risks.
Learn More
With customized IAM policies, organizations can ensure that users have appropriate access, comply with regulatory requirements, reduce the risk of insider threats, and simplify the access management process.
If you’d like to learn about the CIEM capabilities of Prisma Cloud, take it for a free 30-day test drive.