Two-Factor Authentication by 2023 is Not Soon Enough

In May, GitHub took a step toward improving software security, announcing that contributors to all code repositories must use two-factor authentication (2FA) by the end of 2023. While obviously a welcome change, one has to wonder why they’re waiting so long.

Employing 2FA increases account security, certainly, but today’s software supply chain is too critical (and GitHub is too attractive a target) to wait another year before mandating this now-commonplace protection. Developers, software vendors, and customers should consider what they can do now to strengthen their software, both for their own benefit and that of the rest of the software ecosystem.

The Growing Threat of Supply Chain Attacks

A lot of supply chain attacks in recent years resulted from account takeovers, in which threat actors go directly to a package manager (such as npm or PyPi) or GitHub, compromise an account, and use it to insert malicious code into a widely used repository. The resulting code looks like it came from a valid contributor who regularly works on that project, so organizations assume it’s legitimate. They then use that public -- but compromised -- code in their mission-critical applications, and the impact flows downstream from there.

A quick browse of issue commenters, forks, and social media can quickly reveal organizations or projects that depend on the compromised repository, and at that point it’s fishing with dynamite -- a textbook supply chain attack.

GitHub is the world’s largest software development platform, with more than 83 million developers contributing to over 200 million repositories. There’s an implicit trust in its developers, many of whom work on open-source projects, and software in those repositories can be used extensively. As a result, account compromises in GitHub or the npm Registry, a source of shared JavaScript code that GitHub acquired in 2020, can have a widespread impact across the supply chain.

This isn’t intended to be a dig on GitHub -- it’s a larger conversation about what organizations leveraging open-source software, a fantastic tool, need to do to protect the integrity of their products, and ultimately their businesses.

Securing the Software Ecosystem

To start, you don’t have to wait to adopt some form of 2FA, which typically uses a combination of a password with a security token or biometric feature like a fingerprint or face scan. 2FA isn’t perfect, but it is harder to compromise than a single password and it has proven effective at reducing credential compromises and other attacks.

Other effective steps organizations can focus on include:

Software composition analysis. SCA is an automated process of evaluating the security, license compliance and code quality of open-source software. With the increased use of cloud-native applications and DevOps/DevSecOps practices, trying to track open-source code manually is no longer practical. SCA’s automated analysis is quickly becoming essential.

Software Bill of Materials (SBOM). SBOM is a machine-readable inventory of software components and dependencies, including information about those components and their hierarchical relationships. An SBOM can reduce risk, along with providing other benefits such as reducing costs and compliance risks.

SBOMs can also help in avoiding potentially harmful practices, such as auto-merging code from open-source repositories, and they allow you to be as discerning as possible when going between versions in open-source repos.

Passwordless Technology. Requiring 2FA is a notable improvement, but it almost always will include a password as one of its factors. What about doing away with passwords altogether?

The idea has been kicked around for years, but it recently got a significant boost when Apple, Google and Microsoft announced plans to build support for passwordless authentication across all of the platforms they control. It might be hard to imagine a world without passwords, but it already exists on billions of devices that users unlock with fingerprint or face verification, or the use of a device PIN, all of which are simpler and more secure than passwords or technologies such as one-time passcodes sent via SMS.

Passwordless authentication can include physical security keys, specialized apps, emailed magic links and biometrics. In a credential stuffing attack, for example, an attacker might use a password obtained from a data breach -- say, a password you used five years ago for a forum about fixing your TV. If, like most human beings, you reuse passwords, it might also be the password you use for GitHub. And so a supply chain attack gets underway.

You might not think that passwords are your problem, but passwords are your problem; especially when a single password is the only thing standing between an attacker and your data. Encouraging 2FA for GitHub contributors undoubtedly is a positive step but forcing it should happen sooner rather than later.