Node.js Security: The License and Security Risks of Using Node.js

Open source software now dominates application development. Open source represented 60% of the code analyzed during Black Duck Audits in 2018, up from 57% in 2017 and 35% in 2016.

When a codebase contains open source software, it takes advantage of development work that someone else has already completed for free. But an application using a component doesn’t inherit just its features; it also inherits any licensing and security issues lurking in the component. Companies using open source code need to make sure they comply with the legal terms under which that code is released, and they need to know whether that code contains any vulnerabilities.

The Black Duck Audit Services team conducts open source software audits on thousands of codebases for its customers each year, primarily as part of merger and acquisition due diligence. During these audits, we find thousands of license and security risks in open source code in our customers’ codebases. So let’s talk about some of the open source license and security risks that come with using Node.js, one of the most popular JavaScript runtime environments.

Node.js

According to the Node.js website: “Node.js is a JavaScript runtime built on Chrome’s V8 JavaScript engine. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient. Node.js’ package ecosystem, npm, is the largest ecosystem of open source libraries in the world. As an asynchronous event-driven JavaScript runtime, Node is designed to build scalable network applications.”

Node.js is becoming more widespread because it enables the use of server-side JavaScript. JavaScript is arguably the most popular programming language right now because of its scalability, performance, and ease of use. Traditionally, JavaScript was used for client-side front-end web development. The scripts were embedded in the HTML, and the JavaScript engine in the client’s web browser handled the rest. However, thanks to Node.js, JavaScript functionality has been extended to the server-side.

The JavaScript community has grown at an impressive rate. On GitHub, more repositories are created in JavaScript than in any other language. The growth of this open source community has led to the wide adoption of server-side JavaScript with Node.js. This, in turn, has affected open source use in our customers’ codebases. JavaScript applications tend to be heavy with open source code. Thus, as the use of JavaScript in application development increases, so does the use of open source software.

Npm and Potential Security Risks

Npm, the default package manager for Node.js, is one of the largest open source package ecosystems in the world. This rich ecosystem of open source packages has led to an increase in developer productivity and application performance, which is a win-win scenario for development organizations.

Node.js codebases often contain hundreds or even thousands of npm packages. Developers may be unaware of the packages’ direct and indirect dependencies and the security risks associated with them.

Npm began focusing on security in 2018 when they released npm audit, a new command that performs a moment-in-time security review of a project’s dependency tree and produces an npm audit security report. The report contains information about security vulnerabilities in the dependencies and provides npm commands and recommendations for further troubleshooting. The big question is whether companies are looking at the list of security vulnerabilities and managing them appropriately.

Why Do so Many Node.js Projects Have Security Risks?

Many of the organizations that the Black Duck Audit Services team works with have internal security programs and deploy security testing tools, such as static analysis and dynamic analysis. While those tools are useful for identifying common coding errors that may result in security issues, they have proven ineffective at identifying vulnerabilities that enter code through open source components. For example, 12% of codebases using the Node.js frameworkS in 2018 included the Robot vulnerability, over 3% included the Drown vulnerability, and over 2% included Freak. And 1.6% of the codebases even contained the Poodle vulnerability, which was publicly disclosed in 2014.

Why Do so Many Node.js Projects Have License Risks?

Many automated tools that identify open source components in technologies like Node.js do so by analyzing the package manager index files that describe the dependencies in the project. But this cursory list of components and licenses doesn’t account for open source reuse, which is a common occurrence. The open source community reuses open source projects for the same reasons as organizations do: to speed development, incorporate functionality, and decrease time to market. Thus, both commercial and open source developers can introduce code snippets, functions, methods, and operational pieces of code into files.

For that reason, many Node.js projects contain licensing terms other than the license that governs Node.js; on average, 20% of the codebases we audited in 2018 that used the Node.js framework contained hidden reciprocally licensed components. In other words, Node.js uses additional open source content governed by licensing that may be incompatible with commercial use.

The following are examples of open source components that we found in projects using the Node.js framework. Each of these components could pose a license risk as a result of hidden reciprocal components or licenses. Failure to comply with the open source licenses associated with hidden components could put a business at risk of litigation and compromising of an IP.

Deep Dive Node.js Packages Are Completely Necessary

In conclusion, it should be evident that a framework like Node.js requires a deeper dive into the actual source of a package than many automated tools provide. You should learn more about the dependencies of the open source packages in your Node.js applications and the hidden snippets that could place legal restrictions on those packages.

While some organizations are working to address the vulnerability concerns in open source JavaScript packages, much of that work focuses on issues reported to the National Vulnerability Database (NVD).