The npm Blog

npm offers a way for security researchers, package users, package maintainers, and community members to report security vulnerabilities via the “Report a Vulnerability” button on npm Package pages. This provides the community a way to participate in coordinated disclosure with the package maintainer instead of opening a public issue, which could put users at risk.

These reports go directly to the npm Security team for triage instead of to the package maintainers. This is our way of helping the community spend less time on low-quality security reports.

In order for us to make sure reported vulnerabilities are handled rapidly and effectively, we need you, our community, to provide us with actionable, detailed information. Here’s some basic do’s and don’ts for your security report:

What should be included in a quality security report

• The package name and version where you experienced the vulnerability. Example: [email protected] or marked@*
  
• A short description of the vulnerability and its impact. Example: “If a user is able to control input into the function foo then the user is able to execute commands giving the attacker the same access as the user running the application.”
  
• Details of the environment in which you experienced the vulnerability. Example: “This was found to be exploitable using node.js 6.0.0 on OSX, but was not tested using any other platform or Node.js version.”
  
• A demonstrable proof of concept or steps to reproduce the same result. This helps the npm Security team efficiently triage the issue (see the example below).
  
• Any particular references, code snippets, or documents that might help the npm Security team or the maintainer better understand (see the example below).
  

What should not be reported

• Reports without actionable context are very time-consuming for our team to adequately process. These requests should go to the package maintainer in the form of an issue.
  
• The output of npm audit - As the npm Security team already knows about these flaws, it’s better to reach out to the maintainer directly to update dependency versions.
  
• General feature requests
  
• Stack traces or errors without explanation as to what security impact they have.
  

Also note: Vulnerabilities in the npm Registry, website, or other core services and tooling should be reported to [email protected].

Example quality report

I would like to report a command injection vulnerability in the “foobarbaz” package, version 1.0.0.

Follow the below steps to reproduce this vulnerability.

Environment:

Node.js v10.9.0 on Linux

1. npm i [email protected]

2. Create the following proof-of-concept:

The code below illustrates the issue. Executing this code in a directory that contains the file existingfile.zip (a valid zip file that exists on disk, does not necessarily have to be attacker controlled) will also execute the supplied touch xyz command creating a file, but this could be any command the user executing the code has permission to run.

‘‘‘

var foo = require('foobarbaz');

var unzip = foo.unzip;

// Gather user input from some source. In this case we simulate it with a string

var userinput = './existingfile.zip; touch xyz"';

// This line calls the vulnerable method with our user input.

unzip(userinput, './unzipped', function(){});

‘‘‘

Thank you

We’re grateful for our community’s continual efforts to identify and report vulnerabilities and we look forward to your future submissions. We will continue to improve our tools and resources so that npm remains the source of trusted JavaScript.

Q. Hi! Can you state your name, what you do, and/or what your company does?

Hi there! My name is Adam Reis, and I am the co-founder and CTO of Hello Club.

We’ve created Hello Club to help reduce the workload and time spent on admin tasks for the volunteers and committee members who often run clubs.

It has been designed to be easy to use and fun to work with, and allows clubs to keep track of members, bookings, events, and finances effortlessly. It integrates with popular tools like Mailchimp and Xero and also has an integrated access control system for clubs that need it.

Best of all, it’s free for small clubs, so if you know anyone involved in a (sport) club, feel free to point them in our direction!

How’s your day going?

It’s been great so far, thanks! Super busy, but that’s a good thing :).

Tell me the story of npm at your company. What specific problem did you have that npm solved?

We needed a good way to package and distribute reusable components for our Javascript modules, and were looking for a tool that could help orchestrate our build processes, test scripts, and database migration scripts.

npm offered all of that along with a great eco system of already-existing packages that we use for both our front-end, back-end, and IoT devices.

To people who are unsure what they could use npm for — how would you explain the use case?

I would say that npm allows you to bundle and distribute your code, so that you can reuse it in multiple different projects. What’s great is that you can use it for both public (open source) code, as well as proprietary code and modules.

It also allows you to lock in specific versions of modules you want to use — you don’t have to worry about breaking your application when packages are updated or that all your developers are using the exact same version.

In addition, npm can help you organize your scripts and build tools and commands, making it easy to manage the build, test, and maintenance processes of your software or application.

How’s the day to day experience of using npm?

It’s been great! We’ve use it just about every single day for the past 4–5 years, and find that in general it’s been stable and effective, with minimal downtime of the service.

Would you recommend that another org or company use npm and why?

I definitely would. I think npm is the best package manager out there at the moment and would highly recommend it to anyone developing anything with JavaScript.

Any cool npm stuff your company has done publicly that you’d like to promote?

To support the basic functionality we needed for our application, we’ve developed an ecosystem of packages called Meanie that work together to provide a framework for anyone developing with the MEAN stack (MongoDB, Express, Angular, Node).

Most of these modules are available as open source under the @meanie namespace and are updated regularly, so feel free to check them out and use them in your own projects.

Today the Node.js and JS Foundations announced an intent to merge.

tl;dr – This is a good thing. I’m psyched.

The JavaScript community is a big and diverse group of people, doing lots of stuff. Most companies in the world use JavaScript, and at npm, we have a unique view into the shape and scope of this ecosystem.

The overwhelming majority of JavaScript users are people making websites, using modern frameworks, and tooling built in Node.js. They are trying to get a job done, and they want streamlined tools that make them more able to do their jobs. Many of them are not what we might have thought of as “Node Devs” a few years ago (though many are). Their websites run on every back-end platform, including but not limited to Node.js, and they all have to ship a website to browsers, which means JavaScript. Node.js is the dominant platform for building the tools for doing this, and npm is the place where platforms, modules, and tooling are distributed and shared.

A split between “back-end” and “front-end” JavaScript makes less and less sense in light of the way that this community has grown over the last 9 years since Node.js was released. (Wow, has it really been that long? Time flies.) A fast-growing community means that most of the people writing websites, using Node.js-powered tooling and pulling libraries and frameworks from npm, have only been doing it for less than 2 years. The split may have felt normal to those of us involved in 2009, but it seems unnatural and awkward to most working in the field today. It’s just JavaScript. It runs on servers, and on the command line, and in browsers, and you use npm and a bunch of other tools it provides. Is “babel” a front-end tool or a back-end tool? Why are there two groups, when it’s mostly the same people?

Node.js getting more integrated with the broader JS community means that the project can more effectively advocate for server-side use cases, and can get better feedback from those who are depending on Node.js to power the tools they use to ship websites.

As one of the companies at the center of JavaScript development, we at npm are thrilled to see the two major JavaScript foundations joining forces to provide a forum for the entire Open Source JavaScript community. Consistency of governance, processes, and policies can make it easier for devs in disparate JavaScript projects to collaborate and coordinate, removing an unnecessary barrier to innovation. Both foundations now have an established history of iterating on their processes. I hope that this new shift provides a chance to retrospect on what worked, what didn’t work, and what can be improved by working together.

On a personal note, I got involved with Node.js in the first place because I wanted to live in a world where front-end, back-end, tooling, and infrastructure coding did not require constantly shifting my brain around to a whole new language. I couldn’t have predicted how npm would become so relevant to the world of web development, and it’s more than I would have thought to hope for. There’s a lot of open questions about what exactly a merged foundation will look like, but I’m very happy to see things move in this direction.

Q1. Hi! Can you state your name, what you do, and/or what your company does?

I’m Amer Wilson, CRM Consultant at Rolustech, a certified SugarCRM and Salesforce Partner firm. We do CRM customization, implementation, and integrations and have been in the CRM industry for 10 years.

Q2. How’s your day going?

Great!

Q3.Tell me the story of npm at your company. What specific problem did you have that npm solved?

Our company builds software and does CRM customization for our clients. We have used npm in multiple projects. Some of the use cases are below where we used or will use npm:

1. We provide SugarCRM solutions for our Clients. There are many packages available for SugarCRM that we use in our different projects, all installed and managed with the help of npm. We don’t want to commit these dependencies and libraries in our version control system and want to share the same copy of these with everyone in our development team. We simply define these dependencies in the package.json file and other developers just run “npm install” to get all of these installed in their project.

2. We build custom CRM Portals in Ember.js. We install the dependencies in our Ember projects with npm. We use Ember.js command line utility named “ember-cli” and we use npm to install it. We use npm commands to test and build Ember projects.

3. We are developing a CRUD Application in MEAN stack. All the dependencies in Angular are installed by npm. Also, Express is installed in the node server by npm. The tests are performed by npm and the build is created by npm.

4. In one of our projects, we have to show real-time notifications to the CRM users. The solution involves the building of a WebSocket server and we are going to use Node.js and express.js for it. Again we will have to use npm to install all dependencies.

Q4. To people who are unsure what they could use npm for — how would you explain the use case?

npm will help Javascript developers to share their code with other developers or at other places and manage dependency conflicts intelligently.

For example, imagine there is a project in which you make use of different dependencies e.g bootstrap, jasmine, karma, tslint. There are different developers working on the project. You don’t want to commit all of those libraries and JavaScript files in your repository because these files are not going to be changed and everyone needs to have the same version of these files. These can be installed directly by npm. What you need to do is create a package.json file and define all these dependencies in that file and commit it in your repo. Now other developers working on the project will simply run “npm install” command and npm will take care of the rest. All the dependencies will be downloaded and installed in their project. This is a very convenient way to share the code between different people.

Moreover, developers can create and publish their own Node modules of reusable code so that other developers can use it by installing them with the help of npm.

Q5. How’s the day to day experience of using npm?

We keep on using it in different projects as described above. Any new dependency needs to be added to project, we just add it in package.json file and rest npm takes care of.

Q6. Would you recommend that another org or company use npm and why?

We absolutely recommend it for getting the multiple benefits described above.

Q7. Any cool npm stuff your company has done publicly that you’d like to promote?

Not really.

This post was written by Benjamin Coe, Product Manager at npm, Inc. and lead maintainer of yargs and Istanbul for the Node.js Collection. It covers work that has gone into introducing native code coverage support to Node.js.

TLDR: You can now expose coverage output through Node.js by setting the environment variable NODE_V8_COVERAGE to the directory you would like coverage data output in. The tool c8 can be used to output pretty reports based on this coverage information.

A Bit of History: How Test Coverage Has Historically Worked

In JavaScript code, coverage has traditionally been facilitated by a clever hack: tools like Istanbul and Blanket parse JavaScript code inserting counters that (ideally) don’t change the original behavior of the application, for instance:

function foo (a) {
  if (a) {
  // do something with 'a'.
  } else {
  // do something else.
  }
}

gets rewritten as:

function foo(a) {
  cov_2mofekog2n.f[0]++;
  cov_2mofekog2n.s[0]++;
  if (a) {
    // do something with 'a'.
    cov_2mofekog2n.b[0][0]++;
  } else {
    // do something else.
    cov_2mofekog2n.b[0][1]++;
  }
}

cov_2mofekog2n.f[0]++ indicates that the function foo was executed, cov_2mofekog2n.s[0]++ indicates that a statement within this function was called, and cov_2mofekog2n.b[0][0]++ and cov_2mofekog2n.b[0][1]++indicate that branches were executed. Based on these counts, reports can be generated.

This transpilation approach works, but has shortcomings:

• Tools like Istanbul need to play catch up with the evolving JavaScript language and sometimes lag behind on language features; here’s a pull request adding object-spread syntax to Istanbul from September 2017, several months after the feature became widely available.
• Introducing counters on every line of an application significantly impacts performance (Node.js’ own test suite runs about 300% slower when instrumented).
• It’s difficult to insert counters into a codebase without accidentally changing its behavior.

I found myself wishing there was a better way to collect code coverage…

Code Coverage in V8

I was chatting with Bradley Farias in August of 2017 about ESM module support in Node.js as ESM modules presented a problem for Istanbul. The problem? Bradley’s rewrite of Node.js’ loader to support ESM modules no longer supported hooking require statements, this made it difficult for Istanbul to detect that an ESM module had been loaded and instrument it. I made a strong case for adding this functionality back, Bradley had another suggestion:

What if we leverage V8’s new built in coverage functionality?

Using coverage built directly into the V8 engine could address many of the shortcomings facing the transpilation-based approach to code coverage. The benefits being:

• Rather than instrumenting the source-code with counters, V8 adds counters to the bytecode generated from the source-code. This makes it much less likely that the counters alter your program’s behavior.
• Counters introduced in the bytecode don’t impact performance as negatively as injecting counters into every line of the source (I noticed a 20% slowdown in Node.js’ suite vs 300%).
• As soon as new language features are added to V8, they would be immediately available for coverage.

I proceeded to investigate using Node.js’ inspector module for collecting coverage directly from V8; there were some hiccups:

• Timing issues with the inspector made it so only function-level coverage could be enabled (you couldn’t collect coverage for block-level statements: if statements, while statements, switch statements).
• Block coverage was missing some features: || expressions, &&expressions.
• The dance to get the inspector up and running felt overly complex. You needed to start your program, enable the inspector, hook into it, and dump the coverage report.

These challenges aside, using V8’s coverage via the inspector felt promising. I was left wanting to help see things over the finish line.

Moving Towards a Proof of Concept

I reached out to Jakob Gruber on the V8 team regarding the bugs I was seeing integrating V8 coverage with Node.js. The folks at Google were also excited to see coverage support in Node.js and pitched in to start addressing bugs almost immediately.

After a discussion with several V8 maintainers, we determined that there was in fact a mechanism for enabling block level coverage:

1. A program needed to be started with the --inspect-brk flag, such that the inspector terminated execution immediately.
2. Coverage needed to be enabled.
3. Runtime.runIfWaitingForDebugger needed to be run to kick off program execution.
4. The event Runtime.executionContextDestroyed needed to be listened for, at which point coverage could be output.

I tested the approach outlined above and it worked!

I next asked Jakob if I could pitch in and start implementing some of the missing coverage functionality in V8. With the patient help of several folks on the V8 team, I was able to implement support for || and && expressions. This was my first time writing C++ in years and was a ton of fun for me.

At this point we had detailed V8 coverage information being output, but no easy way to output human readable reports. Two npm modules were written to facilitate this:

• v8-to-istanbul, which converts from V8 format coverage output to Istanbul format.
• c8, which pulls together the entire inspector dance into a single command, sot you can collect coverage by simply running c8 node foo.js.

Leveraging these new libraries, we were finally able to see coverage reports!

This was a exciting milestone, but I still wasn’t satisfied. Here’s why:

• The inspector dance continued to get more complicated.
• Depending on how a program exited, for instance if process.exit(0) was called, there was no way to dump a coverage report.
• The approach we were using required that we wait for the inspector to start and connect to it over a socket; this was slow and felt inelegant.

Node-Core Implementation

I had an epiphany, what if Node.js could be placed into a mode that always dumped coverage?

• This would mean that another process wouldn’t need to connect to the inspector session and kick off coverage tracking.
• It would put us in a position to better detect when Node.js was shutting down, such that we could capture process.exit(0) and process.killevents.

In conversation with Anna Henningsen, it turned out that the Node.js inspector implementation lent itself to my idea:

1. The inspector is actually always running in most environments, the websocket interface is just not enabled.
2. There is an internal inspector protocol available that can interact with the inspector without creating a socket connection.

Excited, I sat down and implemented V8 test coverage as a feature of Node.js itself. Here’s what it looks like:

• In Node.js >=10.10.0 you can now set the environment variable NODE_V8_COVERAGE to a directory, this will result in V8 coverage reports being output in this location.
• The tool c8 now simply enables the NODE_V8_COVERAGE environment variable, consumes the V8 coverage data, and outputs pretty reports.

Next Steps

You can start using the Node.js built in coverage reporting today:

1. Make sure you’ve upgraded to Node.js 10.10.0.
2. Install the c8 tool, which can be used to convert V8 coverage output into human readable reports.
3. Use c8 to execute your application, e.g., c8 node foo.js.

This feature is brand new, and I’d love for JavaScript communities to help see things over the finish line.

You can help by:

• Playing with the Node.js built in coverage and filing any bugs you find.
• Submitting patches for existing bugs.
• Spreading the word about this awesome new tool that’s available for JavaScript testing.

What if installs were so fast they could happen in the background, just by using Node? What if every file in your dependencies could be guaranteed to be bit-by-bit identical to what’s on the registry? What if working on a new project was as simple as clone and run? What if your build tools got out of your way?

Introducing tink, a proof of concept implementation of an install-less installer.

tink acts as a replacement for Node.js itself, working from your existing package-lock.json. Try it out on a project without a node_modules and you’ll find that you can still require any of your dependencies even though you never ran an install. The first run will take a few seconds while it downloads and extracts the package tarballs, but subsequent runs are nearly instantaneous even though it’s still verifying that everything in your package-lock.json is on your system.

The first thing you’ll notice is that none of those modules are put into your node_modules folder — in fact, the only thing you’ll find there is a .package-map.json file. This contains hashes of all of the files in every package you have installed. These are verified before they’re loaded, so you can have confidence that you’re getting what you asked for (if a verification fails then the file is fetched from its original source, all transparently).

We’re not throwing the baby out with the bathwater though. You can still install things in your node_modules folder and those versions will be used in preference to the cached version. This opens a path to live-editing of dependencies (sometimes a necessary debugging technique) and support for things like postinstall scripts that mutate the package distribution.

tink is an opportunity to change how we relate to our Node.js projects and the npm Registry. Should using require or import on a module not in your package.json just add it to your package.json? Should extremely popular features like babel-compatible esm, typescript, or jsx be available by default? These are the questions we’ve been asking ourselves and we’d love to hear what you would want from a next generation experience. Come by npm.community and let us know!

A new version of the npm CLI has been released!

• next: 6.4.1
• latest: 6.4.1

Check out the changelog on npm.community

Q. Hi! Can you state your name, what you do, and/or what your company does?

A. My name is Joe Hanley, and I am a full-stack software engineer at Capital One. We’re a bank, a credit card company, and a financial services provider, but we like to think of ourselves as a data and technology company at heart. I work in our San Francisco office on an internal tool that we use to track our interactions with other companies.

How’s your day going?

My day is going great so far! I just got into the office an hour ago and started working on a bug we discovered yesterday. I’m pretty excited to finish that up and get the fix into production, since afterwards I’ll get to work on some super cool pilot work for Amazon Neptune.

Tell me the story of npm at your company. What specific problem did you have that npm solved?

npm is in use all over Capital One! A quick search of our private Github shows over 9000 package.json files at the root level of a repo. My current team uses npm as our package manager for every component our project — our Angular front end, our orchestration layer, our Node.js backend, our NativeScript mobile app, and all of our Lambda microservices. We love npm for a few reasons. 

First, using package-lock lets us ensure that all of our team members  are working off the same version of each package, so we don’t run into unexpected compatibility issues. 

Second, since we use npm on all of our projects, it is super easy for new team members to get each of components running locally. Once they’ve gotten one component set up and working, the rest are simple to run. Third (and maybe most importantly), npm works well with our enterprise environment. It works with our corporate proxy and we can easily switch it between our private registry and the public one as needed.

To people who are unsure what they could use npm for — how would you explain the use case?

npm is great for any JavaScript based project where you want to use external packages in your code. We use it for all sorts of front end web projects, Node.js APIs, and cross-compiling mobile apps. It also great if you want to let other developers use your code in their own projects.

How’s the day to day experience of using npm?

My day to day experience with npm is very positive. I very rarely have issues with it, even when switching versions using nvm. One part of the experience that I really like is how easy it is to find new packages. Often, I’ll start Googling for a solution to a problem that’s facing me, and the first result will be a npm registry page for a package that does exactly what I need!

Would you recommend that another org or company use npm and why?

Absolutely. npm does exactly what you need a package manager to, and it does it without much friction. Additionally, it is widely known among web developers, so many new hires will already be super comfortable with it. Finally, it is flexible enough to accommodate most security requirements — as a bank, Capital One has super stringent security needs, and we are able to fit npm into our ecosystem easily.

Any cool npm stuff your company has done publicly that you’d like to promote?

Capital One has started open sourcing a bunch of the tools that we’ve developed while running a modern, technology focused banking and credit card company, and a ton of them are built using npm. Check them out here.

A new npm cli version has been released!

• latest: 6.4.0
• next: 6.4.1-next.0

Check out the changelog on npm.community

As you’ve probably noticed, npm has been on a roll delivering security features. We have three new features on the website that we’d like to share: the report a vulnerability button, security advisories, and a feature that prevents the use of compromised passwords.

Report a vulnerability

The rapidly growing number of packages in the npm Registry requires us to have a vigilant community who can report anything suspicious. If you feel like you’ve found a security flaw or a malicious module in the Registry, it’s easy to let us know:

On each package page there is now a “Report a Vulnerability” button. Press it and fill out the required information and we’ll decide whether to take action. 

Please note: there is no need to send us the output of npm audit as we already know about those vulnerabilities. Take a look at the About security audits documentation to learn about the output of npm audit.

Improved Security Advisories

Security advisories are what power npm audit. They give you a brief overview of the vulnerabilities in a package, how we recommend you respond, and some handy reference links to find out more.

Transitioning the Node Security Platform required us to move the security advisories to npmjs.com so we took that opportunity to improve their look and feel. We also added a detailed timeline for future advisories so you can learn what changed and when during an advisory’s lifecycle.

You can find a sorted list of advisories on the advisories page.

Blocking password reuse of compromised credentials

It’s fairly common for users to reuse passwords between accounts, but it’s an extremely risky practice that should be avoided. If a shared password is used on another account that is caught in a data breach, attackers can use this public data to guess their way into the user’s npm account and other accounts.

When you sign up for npm or change your password, your chosen password’s hash will be compared against an enormous list of 571 million password hashes graciously provided by Troy Hunt and the Have I Been Pwned project.

If a match is found, you will be presented with an error and will not be allowed to use the password.

Don’t worry! We aren’t sending your password to a third party service. We keep it local to our infrastructure and we don’t transfer or store it in clear text.

Other ways you can protect your account

A great companion to a strong password is 2-Factor Authentication. If you haven’t yet enabled it for your account, we encourage you to take a few seconds to do this. Once enabled, make sure to keep track of your recovery codes in a safe place like a password manager.

We hope you enjoy the new security features we’re continuing to release. If you have any feedback join the discussion at npm.community.