GitHub brings 2FA to the JavaScript package manager

0

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

Additionally, all npm packages have been re-signed and there is now an npm Command Line Interface (CLI) command to audit package integrity.

Finally, GitHub added the ability to connect GitHub and Twitter accounts to npm, as well as a simplified login and publishing experience with the npm CLI.

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

There is not a huge volume of these types of attacks, but it’s clear that cybercriminals are trying to compromise the security of software supply chains by gaining illicit access to the platforms used to build applications, Borins noted. Once cybercriminals gain access to it, they could potentially insert malware into software components that could end up in a number of downstream applications. This malware can then be used to, for example, potentially launch a ransomware attack or simply exfiltrate data. Even more troubling, this malware could start spreading laterally throughout an entire application environment.

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

The challenge GitHub is trying to address is the extent to which certain security controls should be enabled by default depending on the level of risk, Borins said. Individual developers, for example, may have a higher risk tolerance than a corporate IT organization building an application that is central to the processes that drive the business, he noted. In some cases, organizations may choose to completely restrict access where a username/password cannot be remembered, while others will simply limit access to ensure productivity is maintained, added Borines.

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

The crucial problem, of course, is that no one knows for sure which open-source component might one day end up in which application. Regardless of the type of application, developers now routinely reuse code that may contain a 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 minimum is going to start with implementing two-factor authentication, Borins said.

Regardless of the DevSecOps approach, almost everyone recognizes the need to better secure software supply chains. The only thing that remains to be determined is the impact achieving this goal might have on the rate of development and delivery of the software.

Share.

Comments are closed.