This document discusses security, licensing, maintenance, breaking changes and compatibility considerations for Node.js modules. It notes that while 84% of developers are confident in Node.js core security, only 16% are confident that third-party modules are vulnerability-free. It provides tips on using npm audit, GitHub security alerts, and locking dependencies to mitigate security risks. It also discusses understanding open source licenses, analyzing module quality and maintenance, how semantic versioning relates to breaking changes, and resources for long term support and compatibility of Node.js modules.
2. NODE.JS MODULES ARE GREAT
Many are
Open Source
with code
available on
GitHub Promotes
code
sharing
and reuse
Over 800K
modules
available
on npm
registry
7. STATE OF NODE.JS SECURITY
84% are moderately to
very confident in the
security of Node.js core
16% are confident that
third-party packages they
use are vulnerability-free
https://nodesource.com/blog/the-state-of-node-js-security-in
STATE OF NODE.JS SECURITY
84%are moderately
to very confident in
the security of
Node.js core
16%are confident
that third-party
packages they use are
vulnerability-free
https://nodesource.com/blog/the-state-of-node-js-security-in-2017/
STATE OF NODE.JS SECURITY
84%are moderately
to very confident in
the security of
Node.js core
16%are confident
that third-party
packages they use are
vulnerability-free
https://nodesource.com/blog/the-state-of-node-js-security-in-2017/
12. CARE? 🤷
If you link with open source libraries and
then distribute the software, your
software needs to be COMPLIANT with
the licenses of the linked libraries
13. WHAT DO YOU MEAN DISTRIBUTE?
• Transferring software between
employees of the same company is not
normally a distribution
• Users interacting with an app over
network, it is not a distribution for most
open source licenses
• Network Protective licenses (AGPL,
etc.)
• Hosting the JavaScript files on a public
web server is a distribution
22. BREAKING CHANGES
• How strictly are they following
SemVer?
• How often will I have to update
major versions?
• Are security/bug fixes only
released on the latest major
release?
- Hi My names Beth - Past two years I've been working in the Node.js team in IBM Runtime Technologies - Our team originally focused on bringing Node.js to IBM Platforms - IBM SDK for Node.js - Our team has contributed and maintain those upstream in Node.js - So now we’re moving on to look at how we can encourage more of our Enterprise customers to leverage Node.js and its Ecosystem. - One the key areas of concern for our customers is their module dependencies.
- So first of all Node.js Modules are great - Powerful things about Node.js is the massive module ecosystem around it. - There are over 800k modules on NPM Registry, so there’s a high chance that one exists to help the work you want to do - This makes it quick and easy to get small prototypes going while promoting code sharing and reuse.
- As an example - Using 1 module and writing 14 lines of code I can setup and interact with TwitterClient - It is very terse, very quick to achieve something, which enables developers to concentrate on the business logic of their application rather than specific implementations details
- But that’s actually a lot of code in production - Look at the whole tree of deps - There’s a total of 49 packages - Almost 46K lines of code - Covered by 6 different license types - The amount of code you write is significantly differently from the amount that you deploy and are responsible for in production
It’s important to think about that code And this what concerns our enterprise customers. the more code you deploy into production, the more risk.
These are the five “risk” area that pop up a lot, Security, Licenses, Maintenance, Breaking changes Compatibility
Looking at security
There was a survey of Node Developers covering the state of Node.js security from NodeSource and Sqreen last year . From those results, they 84% of Node.js developers are moderately to very confident in the security of Node.js core. Happy to pickup the Node.js runtime. They're confident security issues will be detected and resolved. But, only 16% of Node.js developers surveyed were confident that third-party packages they were using were vulnerability free And, Security issues in node module dependencies can escalates Each year we a get a couple of notable security issues pop up
- In 2017, we had the cross-env issue, where an attacker published malicious code to the similarly named crossenv, so missing out the dash. - malicious code that would be executed on install. - Sent the users environment variables to a remote server, so any credentials you had stored in you environment could've be leaked. - So one typo while trying to install a module could leave you exposed - This type of attack is sometimes called typo-squatting. - It's not only cross-env that has been targeted. Reported and taken down pretty quickly
And then in 2018, I’m sure you remember the eslint issue . Targeting more of a devDependency. - Access was gained to a Eslint publishers account, and a malicious release was published to the NPM registry as a new release - Malicious code in this instance actually tried to expose information stored in the npmrc file. And this is where you'd store your npm registry token. - Intention viral attack, with that one token, they were able to pickup other tokens to enable to do the same . Solution was to revoke all NPM tokens created after a certain date
`npm audit` GitHub security alerts Lock your versions down in your package.json Wildcards?? Specifically ,it wouldn’t have auto downloaded the new release eslint issue
Licenses
Why should you care about licenses? if you link with OS libraries and then distribute the software, your software need to be compliant with the licenses of the linked libraries. And that’s not only the License of the direct dependency, it includes the license of the whole dependency tree
- So sometimes it is unclear what is meant by the term distributing - Transferring software between the same company is not normally a distribution - Users interacting with an app over a network is not a distribution for most licenses. There are Network Protective licenses like AGPL
License types can be loosely grouped into three areas
Protective, If you use one of these, your software has to be bound by the same conditions as the linked software Weakly protective, less restriction for dynamic linking Public Domain and permissive licenses, like MIT that allow you to do anything except sue the author Public Domain or Permissive licenses, which allow you to do everything except sue the author
Sometimes it can be hard to understand this legal terminonlog help select an appropriate license for your own software/module
- To understand which licenses you’re using in the whole tree - you can use a module called license checker - This will out put all the licenses it can detect in the tree - You can also pass it some options to exclude known good options
Looking at maintenance If most of your code is coming from your dependencies, you need to be aware of how maintained the mass of code you're building on top of is
Hit by a bus scenario
GitHub Insights - deprecated, issues fixed, active, new features - how many maintainers are there, - NPM search by quality, which is utilizes npms, which was a project created by developers who were hitting the same issue of not knowing which modules to choose. - Npms collates some of the metrics like “number of commits, ratio of issues closed” to determine stability/maintenance/
- Another concern for our customers is breaking changes. - Some projects still have relatively long release cycles, choosing a module that makes breaking changes _too_ often will be an issue. - They need to have time to migrate to the next version
This is a versioning scheme Breaking Feature Fix
So when looking for a module, you should see if the module is adopting or adhering to Semantic versioning. Bear in mind it is up to the module owners interpretation of what is a patch/breaking change. Another concern would be how often you have to update major versions Will I have to choose between a breaking change and a security fix? Talk about Node.js
With Node.js, they have a defineda Long Term support policy
LTS Node.js
- local dev environment is not the same as their target deployment environment. - So it'd be a pain to get some code all up and running locally, only to find out one of your dependencies does not work in your target production enivronement.
5 major areas of concern when choosing a node module - Security – CI tools etc to watch for vulnerabilities, pattern scanners Licenses - Licenses checker – BE AWARE Vet the whole tree Maintenance - Critical app Breaking changes - LTS policies Compatibility - Check it runs on target runtime
Thanks If you want to win a drone, head to the IBM booth at 3:45
