Spera is now part of Okta and its commitment to secure Identity. | Read more
In an era where identity stands as the last line of defense against a multitude of cyber attacks, securing GitHub users within a large enterprise has emerged as a critical challenge. This necessity is underscored by the need to fortify the company's code and intellectual property. The security team is tasked with navigating a complex landscape encompassing users, identity providers (such as Okta and Microsoft Entra ID), organizational structures, configurations, and repository permissions. Notably, the administration of this system often does not rest in the hands of the security team but rather belongs to a separate team. Compounding this challenge, we've observed a prevalent use of multi-organization architecture among our customers, amplifying the complexity of the task at hand. This observation emphasizes the significance of unraveling the intricacies associated with gaining visibility and control as we strive for enhanced cybersecurity measures.
For over a decade, companies have been facing the question - how do we manage developers’ GitHub accounts? Should we separate work-related accounts from personal accounts, or should developers use the same one for both use cases? In the case of multiple organizational units and subsidiaries, do we manage access to each one of them individually, or do we enforce a single policy across multiple organizations?
For most SaaS applications, SSO solves many of the difficulties arising from maintaining multiple accounts. GitHub is unique, however, since it is a lot more integrated with the local computer than most SaaS apps. Repositories are accessed and written to using the account configured locally. IDEs and code-completion tools integrate directly with the GitHub account, making handling multiple accounts much more difficult.
For this reason, GitHub provides various configuration options, each with distinct strengths and weaknesses. Organizations can opt to leverage their employees' existing personal accounts, configuring SAML Single Sign-On (SSO) to be mandatory at different levels of access within the organization. Alternatively, they may choose to take full control of their employees' accounts, restricting public interaction on GitHub.
While using Github’s “Enterprise-Managed Users” feature solves many of the potential security issues arising from managing multiple organizations, in practice we see many of our customers opting to use other methods, citing difficulties with usability for employees, with collaboration across organizations, and with allowing automation and service account usage.
Lack of Visibility: Management of GitHub organizations might fall under the ownership of IT departments, and be out of reach for security teams. Security teams need to trust, but verify the security controls.
Configuration Complexity: When managing multiple users, organizations and identity providers, security configurations might become complicated. This can lead to inconsistent policies and missed spots.
Mergers and Acquisitions: The problem gets even more challenging when the joined companies decide to make the transition gradually, maintaining the usage of the original Identity Providers for each company. While maintaining this separation for a long period of time could cause problems, it could prove a good solution for the transition period, and can only be achieved by using a different SSO configuration for each organization.
Security Controls in Each Organization: Implementing security controls like Multi-Factor Authentication (MFA) becomes intricate when dealing with numerous organizations. MFA might be set up directly on GitHub, through external identity providers using SSO, or not enforced at all. External users and collaborators might be subject to different policies than employees. We often hear customers struggling to identify where MFA is enforced, and whether there are organizations that can be accessed without it.
Offboarding process: Offboarding of employees becomes complicated when attempting to track access to organizations. Administrators often hold multiple accounts, set up during testing or created for external integrations. Personal email addresses must be detached from company-related accounts. If multiple identity providers are used, they each must be individually scanned for potential misses.
Least privilege and user access reviews: Least privilege means giving users only the access they really need on GitHub, lowering the risk of unauthorized entry and security issues. Regularly checking and adjusting user access helps keep things secure and aligned with their roles. However, in a multi-organization setup, getting these access reports can be time-consuming and difficult.
Spera Security addresses these by providing you with visibility:
Spera Security enables organizations to successfully secure their multi-organization GitHub architecture. If you’re strategizing your GitHub identity architecture, contact me or someone in our team for a discussion on how you can leverage our experience.
