The use of Node.js is rising. But many organizations don’t know about the potential license and security risks that Node.js can pose for their applications.
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.
How are Node.js and open source related?
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.
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.
|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.
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.
- Should you care about the license? (TL;DR: yes!)
- `npm audit`: identify and fix insecure dependencies
*** This is a Security Bloggers Network syndicated blog from Software Integrity Blog authored by Synopsys Editorial Team. Read the original post at: https://www.synopsys.com/blogs/software-security/node-js-license-security-risks/