Blog
Being able to write code, develop software and applications has never been easier. There are hundreds of resources dedicated to educating people on how to learn to code and seek assistance from other knowledgeable developers and hobbyists. There is a wide array of programming languages each suited for different purposes such as standalone applications or high-availability clustered web applications. Almost every application today relies on code from third-party libraries and packages to provide enhanced functionality. Over the past few years, there have been many application security and bugs related to libraries and packages that applications relied on. Take the number of downloads for the popular service for install open-source JavaScript code, the Node Package Manager (NPM) for example. There were 5.946 billion downloads, image the impact a single bug or vulnerability in this vital package would cause, it would affect millions of applications and their user base.
How One Package Broken the Internet
That was precisely the case in early 2016; a developer removed a small package consisting of just 11 lines of code which had 2.48 million downloads and caused disruptions in applications and websites that depended on this package. The number of affected applications is difficult to pinpoint due to dependency chains and differing update/build schedules, however, Babel, Atom, and React, a JavaScript library for user interfaces which is used by Facebook, all required the affected package and were in use by over 5 million live websites, which means the total of affected projects could have neared 8 million. This tiny bit of code that most developers could have been able to write themselves sent many developers into a quick panic. It’s not hard to imagine the disaster this would cause if it there was malicious code, a security vulnerability or a backdoor in the package. Third-party code has a massive impact to application security.
Application Security Considerations
While an outage causes temporary disruptions a security vulnerability or even intentionally malicious dependency could result in a breach that total millions of dollars and as we have seen, impact millions of organizations. This could have been the case just a few weeks ago in July 2018. A developer’s account for a popular package that received 9.366 million downloads in during June was compromised, then the culprit published a new version of the affected library. The updated code would steal the credentials of the users who changed their NPM password. The malicious code and potentially affected accounts were quickly noticed and swiftly resolved, the initial breach of credentials and any subsequent breach of credentials through the malicious package could have easily been mitigated by using two-factor authentication (2FA), which we recently wrote about here.
This is hardly the first breach of an open-source library either, in-fact while writing this post a security incident involving Homebrew, a popular package installer for MacOS, occurred where commit access was gained in as little as 30 minutes. This could have resulted in an attacker pushing malicious updates and code to the software, fortunately the individual who discovered this was a security research, disclosed the issue privately and it was resolved. In order to improve security moving forward Homebrew are also reviewing their 2FA policies and usage to prevent similar incidents. In August 2017, 38 malicious NPM packages were removed, in May 2018 an attempt to hide a backdoor within a popular package was discovered and removed, Ubuntu Store, Arch Linux, Python’s PyPi and Docker Hub have all had similar incidents. The Equifax hack was also related to a vulnerability in an open-source library/package.
Why use Open-source code at all?
As mentioned there are pitfalls with blindly relying on packages found on the internet, but it does not have to be all bad news. From an application security point of view, there are several advantages of open-source applications.
Open-source code is open to more review and as a result, more bugs and security vulnerabilities may be identified by the community.
Open-source licenses typically permit copying and modifications so your organization can create and maintain its own, secure copy of the dependencies.
You can run the code through vulnerability scanners, bug testing, and code review.
Being aware of the pitfalls associated with open-source projects is the best way to mitigate the likelihood of exposing your organization to additional risks.
Developers need to be aware and not blindly rely on packages found online, and they need to be tested and vetted
Maintain a list of dependencies in applications, regularly review and remove packages where no longer required.
Don’t rely on open-source developers to reach out and notify users of vulnerabilities
Be aware that open source code does not necessarily follow a lifecycle, old code may not be fixed or updated, and projects can even be abandoned altogether
Leveraging open-source operating systems, software and code libraries is very popular and has many advantages, however precautions need to be taken especially when developing applications and trusting third-party packages that directly interact with your code. Taking a strategically planned approach to developing applications with requirements for evaluating and reviewing third-party code can help prevent untrustworthy sources from being trusted and help ensure the protection of your most valuable assets.