A Day in the Life of npm Security

The JavaScript ecosystem is a lush, fertile, mostly beneficent garden. But even the best gardens need some tending. Much of that tending comes in the form of the continuous research on the part of the npm security team mated with their automated processes behind the scenes at npm, Inc. when new packages are published. Another crucial element is the vigilance of the JavaScript community at large looking for and reporting potential vulnerabilities of packages in the registry.

The net effect of this widely-scoped vigilance is an inbox chock full of vulnerability reports that must be addressed every day.

Meet André Eleuterio, the vulnerability coordinator of that npm security inbox. Each week, security@npmjs.com receives dozens of vulnerability reports from the JavaScript community and dedicated security researchers. Every day, André combs through the security inbox plus report streams from a number of external security feeds to triage each one and prioritize them by severity.

What’s in the Box?

npm takes every vulnerability report seriously and it’s André’s job to see each one through the process. Of the dozens of inbound reports each week, André says about 20% move forward beyond the initial report. In all, the number of qualified incidents addressed by the security team measures on average 25 per week, at least one of which is malware which takes the highest priority.

What Happens Next?

If a user reports that a package contains malicious code, we follow the same process for malware detected by our internal threat hunting program. We must first confirm the report and remove the package from the registry. We then conduct further incident response to ensure the malware or related variants are completely removed from the registry––such as analyzing similar packages and suspicious activities. Occasionally, this requires cooperation with third-parties, such as the recent Komodo incident.

Once a vulnerability has been confirmed and reproduced in the lab, the next step is to reach out to the package maintainers to apprise them of the issue and coordinate further action. We do this for a couple of reasons: 1) we want to make sure they have all the details to understand and patch the issue; and 2) we want the maintainers to be aware that an advisory will be going out for their package. In some cases the advisories are already public in third-party databases. Because of the massive reach of npm audit, we want to make sure that all maintainers know before a vulnerability is added to our database. 

If a vulnerability is already public, we wait 48 hours for package maintainers to respond and discuss the issue. If a zero-day vulnerability is reported privately to us, we initiate an advisory publication embargo for 45 days until we can verify there is a fix in place.

What’s in the Workshop?

Reviewing and handling incoming vulnerability reports is a full-time job, but the fun doesn’t stop there. The npm security team continues to build and extend internal tools to detect and eliminate potential threats and vulnerabilities. The new security insights API provides visibility into malware, package publication, and package behavior that makes new classes of tools and threat detection possible. We’re busy building stuff with it, but we’re also excited to see what other people will do with it. If you want access to the security insights API, check out the private beta ›

As always, if you suspect a vulnerability in a public package, please report it to security@npmjs.com.