In May 2022, GitHub announced an initiative intended to improve the security of the software supply chain. This initiative will require contributors to the GitHub platform to enable multi-factor authentication (MFA) by the end of 2023.

This program will include a phased rollout designed to protect the open source ecosystem. By the end of May 2022, the top 500 maintainers will be required to enroll in 2FA, ensuring that projects with widespread usage have improved account security. From there, the requirement will expand to cover all GitHub repos and contributors by the end of 2023.

However, while this initiative is designed to improve the overall security of the software supply chain, it doesn’t go far enough. Transitioning the top 500 maintainers to MFA within a month is good, but any package could be vital to an organization’s software security. Additionally, the GitHub mandate only secures one stage of the software supply chain, leaving multiple attack vectors still open.

Why GitHub’s 2FA mandate isn’t enough

The SolarWinds hack and similar recent attacks have demonstrated the importance of securing the software supply chain. One of the primary concerns of software developers is that the code used by their customers is free of bugs, vulnerabilities, and malicious functionality. Achieving this goal requires securing the build and delivery process to ensure that the code shipped to the customer is authentic and free from malicious modifications.

GitHub’s mandate is designed to secure one phase of the software development process. However, full supply chain security requires a four-stage approach to software integrity management:

• Source Threat Protection: Proving that the source code used in a build was written by certified and verified developers and no one else.
• Build Threat Protection: Verifying that the code being built is the same source code that was verified.
• Dependencies Protection: Validating that all third-party dependencies used by the code are authentic and secure.
• Delivery Protection: Ensuring that the software received and run by the customer is the same software that the organization built from verified source and dependencies.

The GitHub 2FA mandate only provides limited protection against these threats. By requiring 2FA to access the GitHub admin console, GitHub provides limited assurance that only authorized developers are pushing code to GitHub. However, this has two major security holes:

1. GitHub repos start on a developer’s machine, and code could be modified by an attacker on the machine before it is pushed to GitHub by an authorized developer.
2. GitHub is assuming that key management and 2FA are handled properly so that an attacker cannot gain access to both factors.

GitHub may prove that pushes to GitHub originate from known and trusted developers. However, they don’t verify that the commits changing that code were created by the same verified developers.

Overcoming the limitations of the 2FA mandate

GitHub’s 2FA requirement for access to the admin console is a step in the right direction for supply chain security. However, it falls far short of what is actually needed to address supply chain threats. While it secures the process of pushing committed code to the cloud, it doesn’t ensure the integrity and authenticity of those commits.

Beyond Identity’s code commit signing solution provides much stronger protections for the integrity and security of the software supply chain. With Beyond Identity, developers digitally sign each commit to their local repo, which ensures that all modifications to the code were performed by an authorized developer. Private keys are stored in a computer’s Trusted Platform Module (TPM) or secure enclave and managed in accordance with corporate security policy, such as required use of strong MFA.

GitHub isn’t going to solve the software supply chain problem for you. You have to do it yourself by:

• Signing your commits
• Verifying that your commits are coming from your developers and no one else
• Verifying that what you're getting from third parties or dependencies is from them and no one else
• Confirming the integrity that what you’ve built makes it to your customer as intended.

Learn more about protecting your organization and customers against software supply chain threats with Beyond Identity Secure DevOps.