DEVOPS
What to Consider Before Enforcing Multi-Factor Authentication (MFA) on GitHub
October 19, 2022
Multi-factor authentication (MFA) is becoming an industry standard. Implementing GitHub MFA is a great way to reduce security risk in GitHub and its contents. Before you implement GitHub MFA, there are some important considerations and limitations to understand in order to ensure a smooth, non-disruptive adoption of this security best practice.
Multi-factor authorization (MFA) is becoming an industry standard for software supply chain security in an era of data leaks, compromised hardcoded secrets, and an endless number of malicious actors operating 24/7. Developers and their ecosystem are increasingly a target, as the meaning of changing source code becomes equivalent to accessing cloud environments, especially where everything is deployed as code.
The fact that these breaches can lead to large-scale damage to an organization makes securing the company’s software supply chain critical. This article explores what an organization should consider when deciding whether to enforce MFA, as well as when and how the different stages of Security Assertion Markup Language (SAML) identity management can factor into the decision. We also discuss the limitations of MFA and how Arnica can help transition an organization smoothly to enforcing GitHub MFA to comply with software supply chain best practices.
GitHub provides several different ways for users to authenticate and gain access to a GitHub organization’s private resources. Developers can create and manage their own accounts, either logging in using GitHub.com directly or via an additional security layer using SAML SSO. Alternatively, organizations using GitHub Enterprise Cloud can choose to leverage Enterprise Managed User accounts, which are completely separate from any personal GitHub account a developer may have; these also allow the organization to have full control over account provisioning, access, and privileges.
Enterprise Managed User accounts give organizations the most control over the activities of the account holders, with the ability to audit account activity, limit the scope of contributions and social activity to private repositories, and define specifications for user profiles and usernames. However, this option may not be the most developer-friendly, and tradeoffs have to be made between the developer experience and levels of code security.
By opting to allow developers to use their own accounts to sign in, with or without SAML SSO, developers are able to stay in control of their own GitHub identity. They also don’t have to manage a separate “work” GitHub account and can keep data such as commit statistics all in one place. To see it in action, go to https://github.com/settings/profile and enable the checkbox as seen in the screenshot below:
More information about viewing contributions on your GitHub profile can be found here: https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-profile/managing-contribution-settings-on-your-profile/viewing-contributions-on-your-profile
It is widely known that unauthorized access via compromised developer accounts is a source of risk for the software supply chain. To mitigate this risk, MFA has long been recommended as an effective defense to augment traditional password-based authentication and third-party authentication or “Bring Your Own Identity” (BYOI). For example, in the CIS Software Supply Chain Guide, a set of software supply chain best practices that can help organizations reach CIS compliance, the Source Code controls section highlights the importance of restricting codebase access to only authorized individuals. This includes mandating MFA for all code contributors when authenticating. GitHub also announced that it is requiring all users to enable 2FA by the end of 2023. Woot woot!
When enforcing MFA, it’s important to ensure that all members of the organization are aware of the requirement ahead of time. For example, when GitHub MFA is enforced for a GitHub organization, any members who do not comply will be removed from the organization. GitHub provides a way for administrators to see which members are removed as well as steps to restore membership, but this could confuse developers and disrupt existing workflows if it is not properly communicated.
Many organizations also create users that are being implemented as service accounts, such as bots or processes that use GitHub APIs periodically. GitHub offers a way to enforce MFA for these accounts as well while still enabling programmatic access via personal access tokens (PATs). Organizations enabling SAML SSO will need to instruct the service account owners to authorize PATs in order to access the protected organizations. It is worth keeping in mind that GitHub automatically expires tokens that haven’t been used in over a year, so if there is an annual script, it needs to be taken into consideration. If configured as explained, there should be no issues with continuing to use these accounts after enforcing GitHub MFA.
If your GitHub organization is not using SAML SSO for authentication and allows personal account access, requiring MFA for personal accounts is a good first step to reducing the risk of unauthorized access:
If your organization is transitioning from allowing personal account access to SAML SSO, GitHub allows two levels of SAML integration: enabling SAML without enforcement and enforcing SAML.
Enabling SAML without enforcement is a good intermediate step to full enforcement. While developers are being onboarded to SAML SSO, there will be a mix of users accessing private resources who are authenticating through personal accounts and SAML SSO. Effectively, during this period, the same vulnerabilities exist as when there is no SAML integration. As you are rolling out SAML SSO registration, if your identity provider does not already require MFA, it would be good to communicate and roll out enforcement of GitHub MFA at this time to ensure everyone is in full compliance in one step.
When SAML is enforced, your personal GitHub identity is linked with your identity provider’s SAML policy, and any unauthorized accounts will have access revoked. Many identity providers require MFA when initializing a SAML session, and with enforced SSO, your GitHub organization can benefit from that security along with all other accounts linked to SAML SSO. If no MFA is configured with the identity provider, then enforcing GitHub MFA can provide security for your GitHub resources. However, you may have to deal with the increased management burden of decentralized MFA enforcement for each service application your developers use.
While MFA may increase protection against software supply chain attacks, it doesn’t completely prevent unauthorized access. Token-based or SSH/GPG key-based authentication can still be compromised, just like passwords. While you can further harden SSH and GPG key-based authentication with a local password, the developer experience of this workflow is not ideal since it requires an extra step when pushing code.
Non-bot interactive service accounts, such as an automation service account that simulates user behavior, may encounter problems authenticating when MFA is enabled. There are some workarounds for this, such as requiring human intervention to authorize a service account when needed, but this is a manual step. Another option is to lower the MFA requirement while keeping other security filters such as an IP address allowlist, but there are enough challenges with this route to warrant a completely separate post.
As mentioned earlier in this article, the transition to SAML SSO must be done with care since GitHub will remove any account that is not already registered in your identity provider. One method to make this transition smoother is to ensure the count of GitHub identities is equal to the count of mapped SAML identities:
This will give you a way to verify that everyone bringing their own identity is also enrolled in SAML SSO so that enforcement can be turned on with minimal disruption. At the same time, it helps keep your codebase safe from unauthorized access before SAML SSO is properly enforced; it also follows the security principle of least privilege to source code.
One common use case: In a Bring-Your-Own-Identity paradigm that does not have properly enforced SAML SSO, an employee who departs the company may still have access to your resources if permissions are not managed correctly. Arnica maps Bring-Your-Own-Identities to SAML identities, which is part of the free plan. Here is an example of such mapping:
With Arnica’s access management capabilities, you can find out who has permissions and perform user entitlement reviews easily.
