GitHub Brings 2FA to JavaScript Package Manager

GitHub has made generally available a two-factor authentication tool for the package manager for JavaScript applications maintained by its NPM, Inc. arm.

In addition, all npm packages have been re-signed and there is now an npm command line interface (CLI) command to audit package integrity.

Finally, GitHub has added the ability to connect GitHub and Twitter accounts to npm along with a streamlined login and publishing experience with the npm CLI.

Myles Borins, staff product manager for open source at GitHub, said these enhancements are part of an ongoing effort to enable organizations to better secure their software supply chain by better protecting credentials against being used to take over GitHub accounts.

There isn’t a huge volume of these types of attacks, but it’s apparent cybercriminals are attempting to compromise the security of software supply chains by gaining illicit access to the platforms used to build applications, noted Borins. Once cybercriminals gain access, they could potentially insert malware in software components that could find its way into any number of downstream applications. That malware can then be used to, for example, potentially launch a ransomware attack or simply exfiltrate data. More troubling still, that malware might begin to spread laterally across an entire application environment.

GitHub is currently dealing with the fallout from a report that its repositories were attacked; that turned out to be a false alarm. The repositories attacked turned out to be either forks or clones of real, popular repositories with names similar to legitimate repositories on the GitHub platform. No malicious code was actually merged into any of the original repositories; however, it’s apparent cybercriminals are using a technique known as spoofing commit metadata to attempt to trick developers into committing code to a fake repository.

The challenge that GitHub is trying to navigate is the degree to which some security controls should be enabled by default based on the level of risk, said Borins. Individual developers, for example, might have a higher tolerance for risk than an enterprise IT organization building an application that is core to the processes that drive the business, he noted. In some cases, organizations may opt to restrict access altogether whenever a user name/password can’t be remembered while others will simply limit access to ensure productivity is maintained, added Borins.

In general, the average enterprise IT organization is likely to have a higher tolerance for disrupting workflows to make sure critical intellectual property is always protected, he added.

The critical issue, of course, is no one knows for sure what open source component might one day wind up in what application. Regardless of the type of application, developers now routinely reuse code that could contain any number of known vulnerabilities or zero-day vulnerabilities that have yet to be discovered. The foundation for building secure DevSecOps workflows for most organizations at a bare minimum is going to start with implementing two-factor authentication, said Borins.

Regardless of the DevSecOps approach, just about everyone recognizes there is a need to better secure software supply chains. The one thing that remains to be determined is what impact achieving that goal might actually have on the rate software is being built and delivered.