Subscribe
Open source use 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, 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 the open source functions, methods, and even code snippets 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 runtimes.
How are Node.js and open source related?
First, what is Node.js? From 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. Note that it wasn’t always the leader. 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 very open source heavy. Thus, as the use of JavaScript in application development increases, so does open source use.
What is npm and how is it related to 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 framework 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.
A Black Duck Open Source Audit doesn’t rely only on automated detection methodologies. A human auditor examines the code, looking at snippets detected by our forensic auditing tool and evaluating relevant string searches in the JavaScript source code. As a result, a Black Duck Audit frequently finds open source code that other tools and methods don’t detect. 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 significant risk of litigation and compromise of IP.
Component |
License |
Potential conflicts |
js-dom |
MIT |
The default-stylesheet included with this open source component is copied from Blink, the rendering engine used by Chromium, which is licensed under LGPL 2.0 or later. |
tough-cookie |
BSD 3-clause |
Up until 2.3.4, this component included Public Suffix List, which is licensed under MPL 2.0. |
seek-bzip |
MIT |
Before 1.0.5, this component was licensed under LGPL 2.1 or later. This component could pose a license risk as the LGPL 2.1 or later license and copyrights are still in the file ‘index.js’. The change of license was a result of upstream packages relicensing their open source components. But were all versions of the upstream packages relicensed? And why is the license still in the files? |
react-native |
MIT |
The file ‘DisplayMetricsHolder.java’ uses code that has been published on Stack Overflow, which is licensed under Creative Commons Attribution-ShareAlike 3.0. |
adm-zip |
MIT |
Up until July 2018, this component included ‘js-deflate’ in the file ‘deflater.js’, which is licensed under GPL 2.0 or later. |
Why you need to do a deep dive into packages in your Node.js projects
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.
And 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). By contrast, one of our research groups at Synopsys focuses on analyzing potential vulnerabilities in open source components and reporting on them via Black Duck Security Advisories (BDSA), which is available exclusively through Synopsys tools and Black Duck Audits.
A Black Duck Audit can help uncover hidden components that might be introducing these legal concerns, as well as provide more detailed vulnerability detection through our BDSA reporting.
Continue Reading
SANS report: Securing the shifting landscape of application development
