Small World with High Risks:

A Study of Security Threats in the npm Ecosystem

Markus Zimmermann Cristian-Alexandru Staicu Cam Tenny

Department of Computer Science Department of Computer Science r2c
TU Darmstadt TU Darmstadt
Michael Pradel
Department of Computer Science
arXiv:1902.09217v2 [cs.CR] 7 Jun 2019

TU Darmstadt

Abstract JavaScript packages for the client-side, server-side, and other

platforms, npm is the centerpiece of a large and important
The popularity of JavaScript has lead to a large ecosystem
software ecosystem.
of third-party packages available via the npm software pack-
The npm ecosystem is open by design, allowing arbitrary
age registry. The open nature of npm has boosted its growth,
users to freely share and reuse code. Reusing a package is as
providing over 800,000 free and reusable software packages.
simple as invoking a single command, which will download
Unfortunately, this open nature also causes security risks, as
and install the package and all its transitive dependencies.
evidenced by recent incidents of single packages that broke
Sharing a package with the community is similarly easy, mak-
or attacked software running on millions of computers. This
ing code available to all others without any restrictions or
paper studies security risks for users of npm by systematically
checks. The openness of npm has enabled its growth, provid-
analyzing dependencies between packages, the maintainers
ing packages for any situation imaginable, ranging from small
responsible for these packages, and publicly reported secu-
utility packages to complex web server frameworks and user
rity issues. Studying the potential for running vulnerable or
interface libraries.
malicious code due to third-party dependencies, we find that
Perhaps unsurprisingly, npm’s openness comes with secu-
individual packages could impact large parts of the entire
rity risks, as evidenced by several recent incidents that broke
ecosystem. Moreover, a very small number of maintainer ac-
or attacked software running on millions of computers. In
counts could be used to inject malicious code into the majority
March 2016, the removal of a small utility package called
of all packages, a problem that has been increasing over time.
left-pad caused a large percentage of all packages to become
Studying the potential for accidentally using vulnerable code,
unavailable because they directly or indirectly depended on
we find that lack of maintenance causes many packages to de-
left-pad.1 In July 2018, compromising the credentials of the
pend on vulnerable code, even years after a vulnerability has
maintainer of the popular eslint-scope package enabled an
become public. Our results provide evidence that npm suffers
attacker to release a malicious version of the package, which
from single points of failure and that unmaintained pack-
tried to send local files to a remote server.2
ages threaten large code bases. We discuss several mitigation
Are these incidents unfortunate individual cases or first
techniques, such as trusted maintainers and total first-party
evidence of a more general problem? Given the popularity
security, and analyze their potential effectiveness.
of npm, better understanding its weak points is an important
step toward securing this software ecosystem. In this paper,
1 Introduction we systematically study security risks in the npm ecosystem
by analyzing package dependencies, maintainers of packages,
JavaScript has become one of the most widely used program- and publicly reported security issues. In particular, we study
ming languages. To support JavaScript developers with third- the potential of individual packages and maintainers to impact
party code, the node package manager, or short npm, provides the security of large parts of the ecosystem, as well as the
hundreds of thousands of free and reusable code packages. ability of the ecosystem to handle security issues. Our analysis
The npm platform consists of an online database for search- is based on a set of metrics defined on the package dependency
ing packages suitable for given tasks and a package manager, graph and its evolution over time. Overall, our study involves
which resolves and automatically installs dependencies. Since 5,386,239 versions of packages, 199,327 maintainers, and
its inception in 2010, npm has steadily grown into a collection 1 https://www.infoworld.com/article/3047177/javascript/
of over 800,000 packages, as of February 2019, and will likely how-one-yanked-javascript-package-wreaked-havoc.html
grow beyond this number. As the primary source of third-party 2 https://github.com/eslint/eslint-scope/issues/39
609 publicly known security issues. the name of the dependent package and a version constraint.
The overall finding is that the densely connected nature of The version constraint either gives a specific version, i.e., the
the npm ecosystem introduces several weak spots. Specifi- dependency is locked, or specifies a range of compatible ver-
cally, our results include: sions, e.g., newer than version X. Each time an npm package
is installed, all its dependencies are resolved to a specific
• Installing an average npm package introduces an implicit
version, which is automatically downloaded and installed.
trust on 79 third-party packages and 39 maintainers, cre-
ating a surprisingly large attack surface. Therefore, the same package installed on two different ma-
chines or at two different times may download different ver-
• Highly popular packages directly or indirectly influence sions of a dependency. To solve this problem, npm introduced
many other packages (often more than 100,000) and are package-lock.json, which developers can use to lock their tran-
thus potential targets for injecting malware. sitive dependencies to a specific version until a new lock file
is generated. That is, each package in the dependency tree is
• Some maintainers have an impact on hundreds of thou-
locked to a specific version. In this way, users ensure uniform
sands of packages. As a result, a very small number
installation of their packages and coarse grained update of
of compromised maintainer accounts suffices to inject
their dependencies. However, a major shortcoming of this ap-
malware into the majority of all packages.
proach is that if a vulnerability is fixed for a given dependency,
• The influence of individual packages and maintainers the patched version is not installed until the package-lock.json
has been continuously growing over the past few years, file is regenerated. In other words, developers have a choice
aggravating the risk of malware injection attacks. between uniform distribution of their code and up-to-date
dependencies. Often they choose the later, which leads to a
• A significant percentage (up to 40%) of all packages technical lag [12] between the latest available version of a
depend on code with at least one publicly known vulner- package and the one used by dependents.
ability.
Overall, these findings are a call-to-arms for mitigating se- Heavy Reuse Recent work [11, 18] provides preliminary
curity risks on the npm ecosystem. As a first step, we discuss evidence that code reuse in npm differs significantly from
several mitigation strategies and analyze their potential effec- other ecosystems. One of the main characteristic of the npm
tiveness. One strategy would be a vetting process that yields ecosystem is the high number of transitive dependencies. For
trusted maintainers. We show that about 140 of such maintain- example, when using the core of the popular Spring web
ers (out of a total of more than 150,000) could halve the risk framework in Java, a developer transitively depends on ten
imposed by compromised maintainers. Another strategy we other packages. In contrast, the Express.js web framework
discuss is to vet the code of new releases of certain packages. transitively depends on 47 other packages.
We show that this strategy reduces the security risk slightly
slower than trusting the involved maintainers, but it still scales Micropackages Related to the reuse culture, another inter-
reasonably well, i.e., trusting the top 300 packages reduces esting characteristic of npm is the heavy reliance on packages
the risk by half. If a given package passes the vetting process that consist of only few lines of source code, which we call
for maintainers and code, we say it has “perfect first-party micropackages. Related work documents this trend and warns
security”. If all its transitive dependencies pass the vetting about its dangers [1, 19]. These packages are an important
processes we say that it has “perfect third-party security”. part of the ecosystem, yet they increase the surface for certain
If both conditions are met, we consider it a “fully secured attacks as much as functionality heavy packages. This exces-
package”. While achieving this property for all the packages sive fragmentation of the npm codebase can thus lead to very
in the ecosystem is infeasible, packages that are very often high number of dependencies.
downloaded or that have several dependents should aim to
No Privilege Separation In contrast to, e.g., the Java se-
achieve it.
curity model in which a SecurityManager3 can restrict the
access to sensitive APIs, JavaScript does not provide any kind
2 Security Risks in the npm Ecosystem of privilege separation between code loaded from different
packages. That is, any third-party package has the full privi-
To set the stage for our study, we describe some security- leges of the entire application. This situation is compounded
relevant particularities of the npm ecosystem and introduce by the fact that many npm packages run outside of a browser,
several threat models. in particular on the Node.js platform, which does not provide
any kind of sandbox. Instead, any third-party package can
2.1 Particularities of npm access, e.g., the file system and the network.
Locked Dependencies In npm, dependencies are declared 3 https://docs.oracle.com/javase/6/docs/api/java/lang/

in a configuration file called package.json, which specifies SecurityManager.html

No Systematic Vetting The process of discovering vulner- Exploiting Unmaintained Legacy Code (TM-leg) As
abilities in npm packages is still in its infancy. There currently with any larger code base, npm contains vulnerable code,
is no systematic vetting process for code published on npm. some of which is documented in public vulnerability
Instead, known vulnerabilities are mostly reported by indi- databases such as npm security advisories7 or Snyk vulnerabil-
viduals, who find them through manual analysis or in recent ity DB8 . As long as a vulnerable package remains unfixed, an
research work, e.g., injection vulnerabilities [30], regular ex- attacker can exploit it in applications that transitively depend
pression denial of service [9, 29], path traversals [16], binding on the vulnerable code. Because packages may become aban-
layer bugs [6]. doned due to developers inactivity [8] and because npm does
Publishing Model In order to publish a package, a devel- not offer a forking mechanism, some packages may never be
oper needs to first create an account on the npm website. Once fixed. Even worse, the common practice of locking dependen-
this prerequisite is met, adding a new package to the repos- cies may prevent applications from using fixed versions even
itory is as simple as running the “npm publish” command when they are available.
in a folder containing a package.json file. The user who first Package Takeover (TM-pkg) An adversary may convince
published the package is automatically added to the main- the current maintainers of a package to add her as a maintainer.
tainers set and hence she can release future versions of that For example, in the recent event-stream incident9 , the attacker
package. She can also decide to add additional npm users as employed social engineering to obtain publishing rights on
maintainers. What is interesting to notice about this model the target package. The attacker then removed the original
is that it does not require a link to a public version control maintainer and hence became the sole owner of the package.
system, e.g., GitHub, hosting the code of the package. Nor A variant of this attack is when an attacker injects code into
does it require that persons who develop the code on such the source base of the target package. For example, such code
external repositories also have publishing rights on npm. This injection may happen through a pull request, via compromised
disconnect between the two platforms has led to confusion4 development tools, or even due to the fact that the attacker
in the past and to stealthy attacks that target npm accounts has commit rights on the repository of the package, but not
without changes to the versioning system. npm publishing rights. Once vulnerable or malicious code is
injected, the legitimate maintainer would publish the package
2.2 Threat Models on npm, unaware of its security problems. Another takeover-
like attack is typosquatting, where an adversary publishes
The idiosyncratic security properties of npm, as described
malicious code under a package name similar to the name of
above, enable several scenarios for attacking users of npm
a legitimate, popular package. Whenever a user accidentally
packages. The following discusses threat models that either
mistypes a package name during installation, or a developer
correspond to attacks that have already occurred or that we
mistypes the name of a package to depend on, the malicious
consider to be possible in the future.
code will be installed. Previous work shows that typosquatting
Malicious Packages (TM-mal) Adversaries may publish attacks are easy to deploy and effective in practice [31].
packages containing malicious code on npm and hence trick
other users into installing or depending on such packages. In Account Takeover (TM-acc) The security of a package
2018, the eslint-scope incident mentioned earlier has been depends on the security of its maintainer accounts. An attacker
an example of this threat. The package deployed its payload may compromise the credentials of a maintainer to deploy
at installation time through an automatically executed post- insecure code under the maintainer’s name. At least one recent
installation script. Other, perhaps more stealthy methods for incident (eslint-scope) is based on account takeover. While
hiding the malicious behavior could be envisioned, such as we are not aware of how the account was hijacked in this
downloading and executing payloads only at runtime under case, there are various paths toward account takeover, e.g.,
certain conditions. weak passwords, social engineering, reuse of compromised
Strongly related to malicious packages are packages that passwords, and data breaches on npm.
violate the user’s privacy by sending usage data to third par-
ties, e.g., insight5 or analytics-node6 . While these libraries Collusion Attack (TM-coll) The above scenarios all as-
are legitimate under specific conditions, some users may not sume a single point of failure. In addition, the npm ecosystem
want to be tracked in this way. Even though the creators of may get attacked via multiple instances of the above threats.
these packages clearly document the tracking functionality, Such a collusion attack may happen when multiple main-
transitive dependents may not be aware that one of their de- tainers decide to conspire and to cause intentional harm, or
pendencies deploys tracking code. when multiple packages or maintainers are taken over by an
attacker.
4 http://www.cs.tufts.edu/comp/116/archive/spring2018/

etolhurst.pdf 7 https://www.npmjs.com/advisories
5 https://www.npmjs.com/package/insight 8 https://snyk.io/vuln/?type=npm
6 https://www.npmjs.com/package/analytics-node 9 https://github.com/dominictarr/event-stream/issues/116
3 Methodology 3.2 Metrics
To analyze how realistic the above threats are, we systemati- We introduce a set of metrics for studying the risk of attacks
cally study package dependencies, maintainers, and known on the npm ecosystem.
security vulnerabilities in npm. The following explains the
data and metrics we use for this study. Packages and Their Dependencies The following mea-
sures the influence of a given package on other packages in
the ecosystem.
3.1 Data Used for the Study
Packages and Their Dependencies To understand the im- Definition 3.4 For every p ∈ Pt , the package reach PR(p)
pact of security problems across the ecosystem, we analyze represents the set of all the packages that have a transitive
the dependencies between packages and their evolution. dependency on p in Gt .
Definition 3.1 Let t be a specific point in time, Pt be a set of
npm package names, and Et = {(pi , p j )|pi 6= p j ∈ Pt } a set Note that the package itself is not included in this set. The
of directed edges between packages, where pi has a regular reach PR(p) contains names of packages in the ecosystem.
dependency on p j . We call Gt = (Pt , Et ) the npm dependency Therefore, the size of the set is bounded by the following
graph at a given time t. values 0 ≤ |PR(p)| < |Pt |.
Since |PR(p)| does not account for the ecosystem changes,
We denote the universe of all packages ever published on the metric may grow simply because the ecosystem grows.
npm with P . By aggregating the meta information about pack- To address this, we also consider the average package reach:
ages, we can easily construct the dependency graph without
the need to download or install every package. Npm offers ∑∀p∈Pt |PR(p)|
an API endpoint for downloading this metadata for all the PRt = (1)
|Pt |
releases of all packages ever published. In total we consider
676,539 nodes and 4,543,473 edges. Using the bounds discussed before for PR(p), we can calcu-
To analyze the evolution of packages we gather data about late the ones for its average 0 ≤ PRt < |Pt |. The upper limit is
all their releases. As a convention, for any time interval t, obtained for a fully connected graph in which all packages can
such as years or months, we denote with t the snapshot at the reach all the other packages and hence |PR(p)| = |Pt | − 1, ∀p.
beginning of that time interval. For example, G2015 refers to If PRt grows monotonously, we say that the ecosystem is get-
the dependency graph at the beginning of the year 2015. In ting more dense, and hence the average package influences
total we analyze 5,386,239 releases, therefore an average of an increasingly large number of packages.
almost eight versions per package. Our observation period The inverse of package reach is a metric to quantify how
ends in April 2018. many packages are implicitly trusted when installing a partic-
Maintainers Every package has one or more developers ular package.
responsible for publishing updates to the package.
Definition 3.2 For every p ∈ Pt , the set of maintainers M(p) Definition 3.5 For every p ∈ Pt , the set of implicitly trusted
contains all users that have publishing rights for p. packages ITP(p) contains all the packages pi for which
p ∈ PR(pi ).
Note that a specific user may appear as the maintainer of
multiple packages and that the union of all maintainers in the
Similarly to the previous case, we also consider the size of
ecosystem is denoted with M .
the set |ITP(p)| and the average number of implicitly trusted
Vulnerabilities The npm community issues advisories or package ITPt , having the same bounds as their package reach
public reports about vulnerabilities in specific npm packages. counterpart.
These advisories specify if there is a patch available and which Even though the average metrics ITPt and PRt are equiv-
releases of the package are affected by the vulnerability. alent for a given graph, the distinction between their non-
Definition 3.3 We say that a given package p ∈ P is vul- averaged counterparts is very important from a security point
nerable at a moment t if there exists a public advisory for of view. To see why, consider the example in Figure 1. The
that package and if no patch was released for the described average PR = IT P is 5/6 = 0.83 both on the right and on the
vulnerability at an earlier moment t 0 < t. left. However, on the left, a popular package p1 is dependent
upon by many others. Hence, the package reach of p1 is five,
We denote the set of vulnerable packages with V ⊂ P . In and the number of implicitly trusted packages is one for each
total, we consider 609 advisories affecting 600 packages. We of the other packages. On the right, though, the number of
extract the data from the publicly available npm advisories10 . implicitly trusted packages for p4 is three, as users of p4
10 https://www.npmjs.com/advisories implicitly trust packages p1, p2, and p3.
 p1 p6 p1 p5

p6
p2 p3

p2 p3 p4 p5 p4

(a) Wide distribution of trust: (b) Narrow distribution of trust:

max(PR) = 5, max(ITP) = 1 max(PR) = 3, max(ITP) = 3
Figure 1: Dependency graphs with different maximum pack-
age reaches (PR) and different maximum numbers of trusted
packages (ITP).

Maintainers The number of implicitly trusted packages or

the package reach are important metrics for reasoning about
TM-pkg, but not about TM-acc. That is because users may de-
cide to split their functionality across multiple micropackages Figure 2: Evolution of number of packages and maintainers.
for which they are the sole maintainers. To put it differently,
a large attack surface for TM-pkg does not imply one for Vulnerabilities For reasoning about TM-leg, we need to
TM-acc. estimate how much of the ecosystem depends on vulnerable
Therefore, we define maintainer reach MRt (m) and implic- code:
itly trusted maintainers ITMt (p) for showing the influence of
maintainers. Definition 3.9 Given all vulnerable packages pi ∈ Vt at
time t, we define the reach of vulnerable code at time t as
Definition 3.6 Let m be an npm maintainer. The maintainer VRt = ∪ pi ∈Vt PR(pi ).
reach MR(m) is the combined reach of all the maintainer’s
Of course the actual reach of vulnerable code can not
packages, MR(m) = ∪m∈M(p) PR(p)
be fully calculated since it would rely on all vulnerabilities
Definition 3.7 For every p ∈ Pt , the set of implicitly trusted present in npm modules, not only on the published ones. How-
maintainers ITM(p) contains all the maintainers that have ever, since in TM-leg we are interested in publicly known
publishing rights on at least one implicitly trusted package, vulnerabilities, we define our metric according to this sce-
ITM(p) = ∪ pi ∈ITP(p) M(pi ). nario. In these conditions, the speed at which vulnerabilities
are reported is an important factor to consider:
The above metrics have the same bounds as their packages
Definition 3.10 Given all vulnerable packages pi ∈ Vt at
counterparts. Once again, the distinction between the package
time t, we define the vulnerability reporting rate VRRt at
and the maintainer-level metrics is for shedding light on the Vt |
security relevance of human actors in the ecosystem. time t as VRRt = ||Pt|
.
Furthermore, to approximate the maximum damage that
colluding maintainers can incur on the ecosystem (TM-coll), 4 Results
we define an order in which the colluding maintainers are
selected: We start by reporting the results on the nature of package level
dependencies and their evolution over time (corresponding
Definition 3.8 We call an ordered set of main- to TM-mal and TM-pkg). We then discuss the influence that
tainers L ⊂ M a desirable collusion strat- maintainers have in the ecosystem (related to TM-acc and
egy iff ∀mi ∈ L there is no mk 6= mi for which TM-coll). Finally, we explore the dangers of depending on
∪ j<i MR(m j ) ∪ MR(mi ) < ∪ j<i MR(m j ) ∪ MR(mk ). unpatched security vulnerabilities (addressing TM-leg).

Therefore, the desirable collusion strategy is a hill climbing

4.1 Dependencies in the Ecosystem
algorithm in which at each step we choose the maintainer that
provides the highest local increase in package reach at that To set the stage for a thorough analysis of security risks en-
point. We note that the problem of finding the set of n main- tailed by the structure of the npm ecosystem, we start with
tainers that cover the most packages is an NP-hard problem a general analysis of npm and its evolution. Since its incep-
called maximum coverage problem. Hence, we believe that tion in 2010, the npm ecosystem has grown from a small
the proposed solution is a good enough approximation that collection of packages maintained by a few people to the
shows how vulnerable the ecosystem is to a collusion attack, world’s largest software ecosystem. Figure 2 shows the evo-
but that does not necessary yield the optimal solution. lution of the number of packages available on npm and the
 each depended upon package runs its post-installation scripts
on the user’s machine – code executed with the user’s operat-
ing system-level permissions. When using the package, calls
into third-party modules may execute any of the code shipped
with the depended upon packages.

When installing an average npm package, a user implic-

itly trusts around 80 other packages due to transitive
dependencies.

One can observe in Figure 3 a chilling effect on the number

of dependencies around the year 2016 which will become
more apparent in the following graphs. Decan et al. [14]
hypothesize that this effect is due to the left-pad incident. In
order to confirm that this is not simply due to removal of more
Figure 3: Evolution of direct package dependencies and its than a hundred packages belonging to the left-pad’s owner, we
impact on transitive dependencies. Note the logarithmic scale remove all the packages owned by this maintainer. We see no
on the y-axis. significant difference for the trend in Figure 3 when removing
these packages, hence we conclude that indeed there is a
number of maintainers responsible for these packages. Both significant change in the structure of transitive dependencies
numbers have been increasing super-linearly over the past in the ecosystem around 2016.
eight years. At the end of our measurement range, there is
a total of 676,539 packages, a number likely to exceed one 4.1.2 Package Reach
million in the near future. These packages are taken care of
The above analysis focuses on depended upon packages. We
by a total of 199,327 maintainers. The ratio of packages to
now study the inverse phenomenon: packages impacted by in-
maintainers is stable across our observation period (ranging
dividual packages, i.e., package reach as defined in Section 3.
between 2.81 and 3.51).
Figure 4 shows how many other packages a single package
In many ways, this growth is good news for the JavaScript
reaches via direct or indirect dependencies. The graph at the
community, as it increases the code available for reuse. How-
top is for an average package, showing that it impacts about
ever, the availability of many packages may also cause devel-
230 other packages in 2018, a number that has been growing
opers to depend on more and more third-party code, which
since the creation of npm. The graph at the bottom shows the
increases the attack surface for TM-pkg by giving individual
package reach of the top-5 packages (top in terms of their
packages the ability to impact the security of many other pack-
package reach, as of 2018). In 2018, these packages each
ages. The following analyzes how the direct and transitive de-
reach between 134,774 and 166,086 other packages, making
pendencies of packages are evolving over time (Section 4.1.1)
them an extremely attractive target for attackers.
and how many other packages individual packages reach via
To better understand how the reach of packages evolves
dependencies (Section 4.1.2).
over time, Figure 5 shows the distribution of reached pack-
ages for multiple years. For example, the red line shows that
4.1.1 Direct and Transitive Dependencies in 2018, about 24,500 packages have reached at least 10 other
packages, whereas only about 9,500 packages were so in-
Figure 3 shows how many other packages an average npm fluential in 2015. Overall, the figure shows that more and
package depends on directly and transitively. The number more packages are reaching a significant number of other
of direct dependencies has been increasing slightly from 1.3 packages, increasing the attractiveness of attacks that rely on
in 2011 to 2.8 in 2018, which is perhaps unsurprising given dependencies.
the availability of an increasing code base to reuse. The less
obvious observation is that a small, linear increase in direct Some highly popular packages reach more than 100,000
dependencies leads to a significant, super-linear increase in other packages, making them a prime target for attacks.
transitive dependencies. As shown by the upper line in Fig- This problem has been aggravating over the past few
ure 3, the number of transitive dependencies of an average years.
package has increased to a staggering 80 in 2018 (note the
logarithmic scale). The high reach of a package amplifies the effect of both
From a security perspective, it is important to note that each vulnerabilities (TM-leg) and of malicious code (TM-mal).
directly or transitively depended on package becomes part of As an example for the latter, consider the event-stream inci-
the implicitly trusted code base. When installing a package, dent discussed when introducing TM-acc in Section 2.2. By
 computing event-stream’s reach and comparing it with other
packages, we see that this package is just one of many possible
targets. As of April 1, 2018 (the end of our measurement pe-
riod), event-stream has a reach of 5,466. That is, the targeted
package is relatively popular, but still far from being the top-
most attractive package to compromise. In fact, 1,165 other
packages have a greater or equal reach than event-stream.

Variants of the event-stream attack could easily be re-

peated with other packages.

In order to perform a similar analysis for the eslint-scope

security incident, we need to use a slightly modified version
of package reach. This attack targeted a development tool,
namely eslint, hence, to fully estimate the attack surface we
need to consider dev dependencies in our definition of reach.
We do not normally consider this type of dependencies in our
measurements because they are not automatically installed
with a package, unlike regular dependencies. They are instead
used only by the developers of the packages. Therefore the
modified version of package reach considers both transitive
regular dependencies and direct dev dependencies.
We observe that eslint-scope has a modified reach of more
than 100,000 packages at the last observation point in the data
set. However, there are 347 other packages that have a higher
reach, showing that even more serious attacks may occur in
the future.

The attack on eslint-scope has targeted a package with

an influence not larger than that of hundreds of other
Figure 4: Evolution of package reach for an average package packages. It is likely that similar, or perhaps even worse,
(top) and the top-5 packages (bottom). attacks will happen and succeed in the future.

4.2 Analysis of Maintainers

We remind the reader that there is a significant difference
between npm maintainers and repository contributors, as dis-
cussed in Section 2.1. Even though contributors also have a
lot of control over the code that will eventually end up in an
npm package, they can not release a new version on npm, only
the maintainers have this capability. Hence, the discussion
that follows, about the security risks associated with maintain-
ers, should be considered a lower bound for the overall attack
surface.
Attacks corresponding to TM-acc in which maintainers are
targeted are not purely hypothetical as the infamous eslint-
scope incident discussed earlier shows. In this attack, a mali-
cious actor hijacked the account of an influential maintainer
and then published a version of eslint-scope containing ma-
Figure 5: Distribution of package reach by individual pack- licious code. This incident is a warning for how vulnerable
ages, and how it changes over time. Note the log scale on the the ecosystem is to targeted attacks and how maintainers in-
vertical axis. fluence can be used to deploy malware at scale. We further
discuss the relation between packages and maintainers.
Figure 6: Evolution of maintainers sorted by package count Figure 7: Evolution of package count for six popular main-
per year. tainers.

4.2.1 Packages per Maintainer sudden spikes where they added many packages in a short
time. We explain this by the tremendous increase in popular-
Even though the ecosystem grows super-linearly as discussed ity for TypeScript in the recent years and by the community
in Section 4.1, one would expect that this is caused mainly by effort to prevent typosquatting attacks by reserving multiple
new developers joining the ecosystem. However, we observe placeholder. The graph of the other maintainers is more linear,
that the number of packages per maintainer also grows sug- but surprisingly it shows a continuous growth for all the six
gesting that the current members of the platform are actively maintainers.
publishing new packages. The average number of packages
controlled by a maintainer raises from 2.5 in 2012 to 3.5 in The number of packages that both the influential and
2013 and almost 4.5 in 2018. Conversely, there are on aver- the average maintainers control increased continuously
age 1.35 maintainers in the lifetime of a package. The top over the years.
5,000 most popular packages have an average number of 2.83
maintainers. This is not unexpected, since multiple people are
involved in developing the most popular packages, while for 4.2.2 Implicitly Trusted Maintainers
the majority of new packages there is only one developer.
Next, we study in more detail the evolution of the number One may argue that the fact that maintainers publish new
of packages a maintainer controls. Figure 6 shows the main- packages is a sign of a healthy ecosystem and that it only
tainer package count plotted versus the number of maintainers mimics its overall growth. However, we show that while that
having such a package count. Every line represents a year. may be true, we also see an increase in the general influence
The scale is logarithmic to base 10. It shows that the majority of maintainers. That is, on average every package tends to
of maintainers maintain few packages, yet some maintain- transitively rely on more and more maintainers over time.
ers maintain over 100 packages. Over the years, the package In Figure 8 we show the evolution of IT Mt , the average
count for the maintainers increased consistently. In 2015, only number of implicitly trusted maintainers. As can be seen,
slightly more than 25,000 maintainers maintained more than IT Mt almost doubled in the last three years for the average
one package, whereas this number has more than tripled by npm package, despite the plateau of the curve reached in 2016
2018. which we again speculate it is caused by the left-pad incident.
We further analyze five different maintainers in top 20 This is a worrisome development since compromising any
according to number of packages and plot the evolution of of the maintainer accounts a package trusts may seriously
their package count over the years in Figure 7. types is the impact the security of that package, as discussed in TM-acc.
largest maintainer of type definitions for TypeScript, most The positive aspect of the data in Figure 8 is that the growth
likely a username shared by multiple developers at Microsoft, in the number of implicitly trusted maintainers seems to be
ehsalazar maintains many security placeholder packages, jon- less steep for the top 10,000 packages compared to the whole
schlinkert and sindresorhus are maintaining many micropack- ecosystem. We hypothesize that the developers of popular
ages and isaacs is the npm founder. From Figure 7 we can packages are aware of this problem and actively try to limit
see that for two of these maintainers the increase is super- the IT Mt . However, a value over 20 for the average popular
linear or even near exponential: types and kylemathews have package is still high enough to be problematic.
Figure 8: Evolution of average number of implicitly trusted
maintainers over years in all packages and in the most popular Figure 10: Distribution of maintainers reach in different years.
ones.
4.2.3 Maintainers Reach
In Figure 10, we plot the reach MRt of the maintainers in the
npm ecosystem. The reach has increased over the years at all
levels. For example, in 2015 there were 2,152 maintainers
that could affect more than 10 packages, and this number
increased to 4,041 in 2016, 6,680 in 2017 and finally reaching
an astonishingly high 10,534 in 2018. At the other end of
the distribution, there were 59 maintainers that could affect
more than 10,000 packages in 2015, 163 in 2016, 249 in
2017 and finally 391 in 2018. The speed of growth for MRt
is worrisome, showing that more and more developers have
control over thousands of packages. If an attacker manages
to compromise the account of any of the 391 most influential
maintainers, the community will experience a serious security
incident, reaching twice as many packages as in the event-
Figure 9: Number of implicitly trusted maintainers for top stream attack.
10,000 most popular packages.
391 highly influential maintainers affect more than
The average npm package transitively relies on code 10,000 packages, making them prime targets for attacks.
published by 40 maintainers. Popular packages rely on The problem has been aggravating over the past years.
only 20.
Finally, we look at the scenario in which multiple popular
maintainers collude, according to the desirable collusion strat-
When breaking the average IT Mt discussed earlier into in- egy introduced in Section 3.2, to perform a large-scale attack
dividual points in Figure 9, one can observe that the majority on the ecosystem, i.e., TM-col. In Figure 11 we show that
of these packages can be influenced by more than one main- 20 maintainers can reach more than half of the ecosystem.
tainer. This is surprising since most of the popular packages Past that point every new maintainer joining does not increase
are micropackages such as "inherits" or "left-pad" or libraries significantly the attack’s performance.
with no dependencies like "moment" or "lodash". However,
only around 30% of these top packages have a maintainer cost 4.3 Security Advisories Evolution
higher than 10. Out of these, though, there are 643 packages
influenced by more than a hundred maintainers. Next, we study how often vulnerabilities are reported and
fixed in the npm ecosystem (TM-leg). Figure 13 shows
the number of reported vulnerabilities in the lifetime of the
More than 600 highly popular npm packages rely on ecosystem. The curve seems to resemble the evolution of
code published by at least 100 maintainers. number of packages presented in Figure 2, with a steep in-
crease in the last two years. To explore this relation further
we plot in Figure 14 the evolution of the number of advisories
 Figure 11: Combined reach of 100 influential maintainers. Figure 14: Evolution of VRRt , the rate of published vulnera-
bilities per 10,000 packages.

reported per 10,000 packages and we observe that it grows

from two in 2013 to almost eight in 2018. This is a sign of a
healthy security community that reports vulnerabilities at a
very good pace, keeping up with the growth of the ecosystem.
When analyzing the type of reported vulnerabilities in de-
tails, we observe that almost half of the advisories come from
two large-scale campaigns and not a broader community ef-
fort: First, there are 141 advisories published in January 2017
involving npm packages that download resources over HTTP,
instead of HTTPs. Second, there are 120 directory traver-
sal vulnerabilities reported as part of the research efforts of
Liang Gong [16]. Nevertheless, this shows the feasibility of
large-scale vulnerability detection and reporting on npm.
Publishing an advisory helps raise awareness of a security
problem in an npm package, but in order to keep the users
secure, there needs to be a patch available for a given advi-
Figure 12: Total reach of packages for which there is at least sory. In Figure 13 we show the evolution of the number of
one unpatched advisory (vulnerability reach VRt ). unpatched security vulnerabilities in npm, as defined in Sec-
tion 3. This trend is alarming, suggesting that two out of three
advisories are still unpatched, leaving the users at risk. When
manually inspecting some of the unpatched advisories we
notice that a large percentage of unpatched vulnerabilities are
actually advisories against malicious typosquatting packages
for which no fix can be available.
To better understand the real impact of the unpatched vul-
nerabilities we analyze how much of the ecosystem they im-
pact, i.e., vulnerability reach as introduced in Section 3.2. To
that end, we compute the reach of unpatched packages at
every point in time in Figure 12. At a first sight, this data
shows a much less grim picture than expected, suggesting
that the reach of vulnerable packages is dropping over time.
However, we notice that the effect of vulnerabilities tends
to be retroactive. That is, a vulnerability published in 2015
affects multiple versions of a package released prior to that
Figure 13: Evolution of the total and unpatched number of
date, hence influencing the data points corresponding to the
advisories.
years 2011-2014 in Figure 12. Therefore, the vulnerabilities
Figure 15: Correlation between number of vulnerabilities and
number of dependencies. Figure 16: Decrease in average number of implicitly trusted
maintainers and packages as the set of trusted maintainers or
that will be reported in the next couple of years may correct packages increases.
for the downwards trend we see on the graph. Independent
of the downwards trend, the fact that for the majority of the 5.2 Warning about Vulnerable Packages
time the reach of vulnerable unpatched code is between 30%
and 40% is alarming. To warn developers about unpatched vulnerabilities in their de-
pendencies, the npm audit tool has been introduced. It com-
pares all directly depended upon packages against a database
Up to 40% of all packages rely on code known to be
of known vulnerabilities, and warns a developer when depend-
vulnerable.
ing upon a vulnerable version of a package. While being a
valuable step forward, the tool currently suffers from at least
5 Potential Mitigations three limitations. First, it only considers direct dependencies
but ignores any vulnerabilities in transitive dependencies. Sec-
The following section discusses ideas for mitigating some of ond, the tool is limited to known vulnerabilities, and hence its
the security threats in the npm ecosystem. We here do not effectiveness depends on how fast advisories are published.
provide fully developed solutions, but instead outline ideas Finally, this defense is insufficient against malware attacks.
for future research, along with an initial assessment of their
potential and challenges involved in implementing them.
5.3 Code Vetting
5.1 Raising Developer Awareness A proactive way of defending against both vulnerable and
malicious code is code vetting. Similar to other ecosystems,
One line of defense against the attacks described in this paper such as mobile app stores, whenever a new release of a vetted
is to make developers who use third-party packages more package is published, npm could analyze its code. If and only
aware of the risks entailed by depending on a particular pack- if the analysis validates the new release, it is made available to
age. Currently, npm shows for each package the number of users. Since the vetting process may involve semi-automatic
downloads, dependencies, dependents, and open issues in the or even manual steps, we believe that it is realistic to assume
associated repository. However, the site does not show any that it will be deployed step by step in the ecosystem, starting
information about the transitive dependencies or about the with the most popular packages. Figure 16 (orange curve)
number of maintainers that may influence a package, i.e., our illustrates the effect that such code vetting could have on
ITP and ITM metrics. As initial evidence that including such the ecosystem. The figure shows how the average number of
metrics indeed predicts the risk of security issues, Figure 15 implicitly trusted packages, ITP, reduces with an increasing
shows the number of implicitly trusted packages versus the number of vetted and therefore trusted packages. For exam-
number of vulnerabilities a package is affected by. We find ple, vetting the most dependent upon 1,500 packages would
that the two values are correlated (Pearson correlation coeffi- reduce the ITP ten fold, and vetting 4,000 packages would
cient of 0.495), which is not totally unexpected since adding reduce it by a factor of 25.
more dependencies increases the chance of depending on vul- An obvious question is how to implement such large-scale
nerable code. Showing such information, e.g., the ITP metric, code vetting, in particular, given that new versions of pack-
could help developers make more informed decisions about ages are released regularly. To estimate the cost of vetting new
which third-party packages to rely on. releases, Figure 17 shows the average number of lines of code
 effect that such a process would have, we simulate how train-
ing and vetting a particular number of trusted maintainers in-
fluences the average number of implicitly trusted maintainers,
ITM. The simulation assumes that the most influential main-
tainers are vetted first, and that once a maintainer is vetted
she is ignored in the computation of the ITM. The results of
this simulation (Figure 16) show a similar effect as for vetting
packages: Because some maintainers are highly influential,
vetting a relatively small number of maintainers can signifi-
cantly reduce security risks. For example, vetting around 140
maintainers cuts down the ITM in half, and vetting around
600 could even reduce ITM to less than five. These results
show that this mechanism scales reasonably well, but that hun-
dreds of maintainers need to be vetted to bring the average
Figure 17: Number of lines of code that need to be vetted for number of implicitly trusted maintainers to a reasonable level.
achieving a certain number of trusted packages. Moreover, two-factor authentication has its own risks, e.g.,
when developers handle authentication tokens in an insecure
that are changed per release of a package, and would need to way14 or when attackers attempt to steal such tokens, as in
be vetted to maintain a specific number of trusted packages. the eslint-scope incident.
For example, vetting the changes made in a single new release
of the top 400 most popular packages requires to analyze over
6 Related Work
100,000 changed lines of code. One way to scale code vet-
ting to this amount of code could be automated code analysis In this section we discuss the closest related work contained
tools. Recently, there have been several efforts for improving mainly in two distinct research areas: JavaScript security and
the state of the art of security auditing for npm, both from software ecosystem studies. While some of this work studies
academia, e.g., Synode [30], BreakApp [32], NodeSec [16], the npm ecosystem, to the best of our knowledge, we are
NoRegrets [25], Node.cure [10], and from industry practi- the first to analyze in depth the role maintainers play in the
tioners, e.g., Semmle11 , r2c12 , and DeepScan13 . Orthogonal ecosystem and the impact of different types of attacks, as well
to automated code analysis tools, the npm community could as the potential impact of vetting code.
establish crowd-sourced package vetting, e.g., in a hierarchi-
cally organized code distribution model similar to the Debian Server-side JavaScript Security There are many studies
ecosystem. that investigate problems with dependency management for
Another challenge for code vetting is that npm packages, in the JavaScript or other ecosystems. Abdalkareem et al. [2] in-
contrast to apps in mobile app stores, are used across different vestigate reasons why developers would use trivial packages.
platforms with different security models. For example, XSS They find that developers think that these packages are well
vulnerabilities are relevant only when a package is used on the implemented and tested and that they increase productivity as
client-side, whereas command injection via the exec API [30] the developer does not need to implement such small features
is a concern only on the server-side. A code vetting process herself. Another empirical study on micropackages by Kula
could address this challenge by assigned platform-specific et al. [19] has similar results. They show that micropackages
labels, e.g., “vetted for client-side” and ”vetted for server- have long dependency chains, something we also discovered
side”, depending on which potential problems the vetting in some case studies of package reach. We also show that
reveals. these packages have a high potential of being a target of an
attack as they are dependent on by a lot of packages. Another
previously studied topic is breaking changes introduced by
5.4 Training and Vetting Maintainers dependencies. Bogart et al. [5] perform a case study inter-
Another line of proactive defense could be to systematically viewing developers about breaking changes in three different
train and vet highly influential maintainers. For example, this ecosystems. They find that npm’s community values a fast ap-
process could validate the identity of maintainers, support proach to new releases compared to the other ecosystems. De-
maintainers in understanding basic security principles, and velopers of npm are more willing to adopt breaking changes
ensure that their accounts are protected by state-of-the-art to fight technical debt. Furthermore, they find that the seman-
techniques, such as two-factor authentication. To assess the tic versioning rules are enforced more overtime than in the
beginning. Similarly, Decan et al. [11] analyze three package
11 https://semmle.com/
12 https://r2c.dev/ 14 https://blog.npmjs.org/post/182015409750/
13 https://deepscan.io/ automated-token-revocation-for-when-you
ecosystems, including npm, and evaluate whether dependency data set include at least one vulnerable library. This number
constraints and semantic versioning are effective measures is suprisingly close to the reach we observe in npm for the
for avoiding breaking changes. They find that both these mea- vulnerable code. However, one should take both these results
sures are not perfect and that there is a need for better tooling. with a grain of salt since inclusion of vulnerable libraries does
One such tool can be the testing technique by Mezzetti et not necessary lead to a security problem if the library is used
al. [25] which automatically detects whether an update of a in a safe way. Libert et al. [22] perform a HTTP-level analysis
package contains a breaking change in the API. With this of third-party resource inclusions, i.e., dependencies. They
method, they can identify type-related breaking changes be- conclude that nine in ten websites leak data to third-parties
tween two versions. They identify 26 breaking changes in 167 and that six in ten spwan third-party cookies.
updates of important npm packages. Pfretzschner et al. [27]
describe four possible dependency-based attacks that exploit Studies of Software Ecosystems Software ecosystem re-
weaknesses such as global variables or monkeypatching in search has been rapidly growing in the last year. Manikas [23]
Node.js. They implement a detection of such attacks, but they surveys the related work and observes a maturing field at the
do not find any real-world exploits. One way to mitigate these intersection of multiple other research areas. Nevertheless,
attacks is implemented by Vasilakis et al. [32] in BreakApp, a he identifies a set of challenges, for example, the problem
tool that creates automatic compartments for each dependency of generalizing specific ecosystem research to other ecosys-
to enforce security policies. This increases security when us- tems or the lack of theories specific to software ecosystems.
ing untrusted third-party packages. Furthermore, third-party Serebrenik et al. [28] perform a meta-analysis of the diffi-
packages can have security vulnerabilities that can impact cult tasks in software ecosystem research and identify six
all the dependents. Davis et al. [9] and Staicu et al. [29] find types of challenges. For example, how to scale the analysis
denial of service vulnerabilities in regular expressions in the to the massive amount of data, how to research the quality
npm ecosystem. In another study, Staicu et al. [30] find sev- and evolution of the ecosystem and how to dedicate more
eral injection vulnerabilities due to the child_process module attention to comparative studies. Mens [24] further looks at
or the eval function. Brown et al. [6] discuss bugs in the the socio-technical view on software maintenance and evo-
binding layers of both server-side and client-side JavaScript lution. He argues that future research needs to study both
platforms, while Wang et al. [33] analyze concurrency bugs the technical and the social dimension of the ecosystem. Our
in Node.js Finally, Gong [16] presents a dynamic analysis study follows this recommendation as it not only looks at the
system for identifying vulnerable and malicious code in npm. influence of a package on the npm ecosystem, but also at the
He reports more than 300 previously unknown vulnerabilities, influence of the maintainers. Several related work advocates
some of which are clearly visible on the figures in Section 4.3. metrics borrowed from other fields. For example, Lertwit-
Furthermore, there are studies that look at how frequent se- tayatrai et al. [21] use network analysis techniques to study
curity vulnerabilities are in the npm ecosystem, how fast the topology of the JavaScript package ecosystem and to ex-
packages fix these and how fast dependent packages upgrade tract insights about dependencies and their relations. Another
to a non-vulnerable version. Chatzidimitriou et al. [7] build study by Kabbedijk et al. [17] looks at the social aspect of
an infrastructure to measure the quality of the npm ecosystem the Ruby software ecosystem by identifying different roles
and to detect publicly disclosed vulnerabilities in package de- maintainers have in the ecosystem, depending on the number
pendencies. Decan et al. [13] perform a similar study but they of developers they cooperate with and on the popularity of
investigate the evolution of vulnerabilities over time. They their packages. Overall, the research field is rising with a lot
find that more than half of the dependent packages are still af- of studied software ecosystems in addition to the very popular
fected by a vulnerability after the fix is released. However, we ones such as JavaScript which is the focus of our study.
show that the problem is even more serious because for more Ecosystem Evolution Studying the evolution of an ecosys-
than half of the npm packages there is no available patch. tem shows how fast it grows and whether developers still
Client-Side (JavaScript) Security Client-side security is a contribute to it. Wittern et al. [34] study the whole JavaScript
vast and mature research area and it is out scope to extensively ecosystem, including GitHub and npm until September 2015.
survey it here. Instead, we focus on those studies that ana- They focus on dependencies, the popularity of packages and
lyze dependencies in client-side code. Nikiforakis et al. [26] version numbering. They find that the ecosystem is steadily
present a study of remote inclusion of JavaScript libraries growing and exhibiting a similar effect to a power law dis-
in the most popular 10,000 websites. They show that an av- tribution as only a quarter of packages is dependent upon.
erage website in their data set adds between 1.5 and 2 new Comparing these numbers with our results, we see a con-
dependencies per year. Similar to our work, they then discuss tinuous near-exponential growth in the number of released
several threat models and attacks that can occur in this tightly packages and that only 20% of all packages are dependent
connected ecosystem. Lauinger et al. [20] study the inclusion upon. A similar study that includes the JavaScript ecosystem
of libraries with known vulnerabilities in both popular and by Kikas et al. [18] collects data until May 2016 and focuses
average websites. They show that 37% of the websites in their on the evolution of dependencies and the vulnerability of the
dependency network. They confirm the same general growth References
as the previous study. Furthermore, they find packages that
have a high impact with up to 30% of other packages and ap- [1] Rabe Abdalkareem, Olivier Nourry, Sultan Wehaibi,
plications affected. Our study gives an update on these studies Suhaib Mujahid, and Emad Shihab. Why do developers
and additionally looks at the evolution of maintainers as they use trivial packages? an empirical case study on npm.
are a possible vulnerability in the ecosystem. The dependency In FSE, 2017.
network evolution was also studied for other ecosystems. De-
can et al. [14] compare the evolution of seven different pack- [2] Rabe Abdalkareem, Olivier Nourry, Sultan Wehaibi,
age managers focusing on the dependency network. Npm is Suhaib Mujahid, and Emad Shihab. Why do develop-
the largest ecosystem in their comparison and they discover ers use trivial packages? an empirical case study on
that dependencies are frequently used in all these ecosystems npm. In Proceedings of the 2017 11th Joint Meeting
with similar connectedness between packages. Bloemen et on Foundations of Software Engineering, ESEC/FSE
al. [4] look at software package dependencies of the Linux 2017, Paderborn, Germany, September 4-8, 2017, pages
distribution Gentoo where they use cluster analysis to explore 385–395, 2017.
different categories of software. German et al. [15] study the
[3] Gabriele Bavota, Gerardo Canfora, Massimiliano Di
dependency network of the R language and the community
Penta, Rocco Oliveto, and Sebastiano Panichella. The
around its user-contributed packages. Bavota et al. [3] an-
evolution of project inter-dependencies in a software
alyze the large Apache ecosystem of Java libraries where
ecosystem: The case of apache. In 2013 IEEE Interna-
they find that while the number of projects grows linearly, the
tional Conference on Software Maintenance, Eindhoven,
number of dependencies between them grows exponentially.
The Netherlands, September 22-28, 2013, pages 280–
Comparing this to the npm ecosystem, we find the number of
289, 2013.
packages to grow super-linearly while the average number of
dependencies between them grows linearly. [4] Remco Bloemen, Chintan Amrit, Stefan Kuhlmann, and
Gonzalo Ordóñez-Matamoros. Gentoo package depen-
dencies over time. In 11th Working Conference on Min-
ing Software Repositories, MSR 2014, Proceedings, May
31 - June 1, 2014, Hyderabad, India, pages 404–407,
7 Conclusions 2014.

We present a large-scale study of security threats resulting [5] Christopher Bogart, Christian Kästner, James D. Herb-
from the densely connected structure of npm packages and sleb, and Ferdian Thung. How to break an API: cost
maintainers. The overall conclusion is that npm is a small negotiation and community values in three software
world with high risks. It is “small” in the sense that packages ecosystems. In Proceedings of the 24th ACM SIGSOFT
are densely connected via dependencies. The security risk are International Symposium on Foundations of Software
“high” in the sense that vulnerable or malicious code in a sin- Engineering, FSE 2016, Seattle, WA, USA, November
gle package may affect thousands of others, and that a single 13-18, 2016, pages 109–120, 2016.
misbehaving maintainer, e.g., due to a compromised account, [6] Fraser Brown, Shravan Narayan, Riad S. Wahby, Daw-
may have a huge negative impact. These findings show that son R. Engler, Ranjit Jhala, and Deian Stefan. Finding
recent security incidents in the npm ecosystem are likely to and preventing bugs in javascript bindings. In 2017
be the first signs of a larger problem, and not only unfortunate IEEE Symposium on Security and Privacy, SP 2017,
individual cases. To mitigate the risks imposed by the current San Jose, CA, USA, May 22-26, 2017, pages 559–578,
situation, we analyze the potential effectiveness of several 2017.
mitigation strategies. We find that trusted maintainers and a
code vetting process for selected packages could significantly [7] Kyriakos C. Chatzidimitriou, Michail D. Papamichail,
reduce current risks. Themistoklis G. Diamantopoulos, Michail Tsapanos,
and Andreas L. Symeonidis. npm-miner: an infrastruc-
ture for measuring the quality of the npm registry. In
Acknowledgments Proceedings of the 15th International Conference on
This work was supported by the German Federal Ministry of Educa- Mining Software Repositories, MSR 2018, Gothenburg,
tion and Research and by the Hessian Ministry of Science and the Sweden, May 28-29, 2018, pages 42–45, 2018.
Arts within CRISP, by the German Research Foundation within the
ConcSys and Perf4JS projects. The authors would also like to thank
the team at r2c for their engineering support in obtaining the data [8] Eleni Constantinou and Tom Mens. An empirical com-
for this work. parison of developer retention in the rubygems and npm
software ecosystems. ISSE, 13(2-3):101–115, 2017.
 [9] James C. Davis, Christy A. Coghlan, Francisco Servant, [18] Riivo Kikas, Georgios Gousios, Marlon Dumas, and
and Dongyoon Lee. The impact of regular expression Dietmar Pfahl. Structure and evolution of package de-
denial of service (redos) in practice: an empirical study pendency networks. In Proceedings of the 14th Inter-
at the ecosystem scale. In Proceedings of the 2018 ACM national Conference on Mining Software Repositories,
Joint Meeting on European Software Engineering Con- MSR 2017, Buenos Aires, Argentina, May 20-28, 2017,
ference and Symposium on the Foundations of Software pages 102–112, 2017.
Engineering, ESEC/SIGSOFT FSE 2018, Lake Buena
Vista, FL, USA, November 04-09, 2018, pages 246–256, [19] Raula Gaikovina Kula, Ali Ouni, Daniel M. Germán,
2018. and Katsuro Inoue. On the impact of micro-packages:
An empirical study of the npm javascript ecosystem.
[10] James C. Davis, Eric R. Williamson, and Dongyoon CoRR, abs/1709.04638, 2017.
Lee. A sense of time for javascript and node.js: First-
class timeouts as a cure for event handler poisoning. In [20] Tobias Lauinger, Abdelberi Chaabane, Sajjad Arshad,
27th USENIX Security Symposium, USENIX Security William Robertson, Christo Wilson, and Engin Kirda.
2018, Baltimore, MD, USA, August 15-17, 2018., pages Thou shalt not depend on me: Analysing the use of
343–359, 2018. outdated javascript libraries on the web. In NDSS, 2017.

[11] Alexandre Decan, Tom Mens, and Maëlick Claes. An [21] Nuttapon Lertwittayatrai, Raula Gaikovina Kula, Saya
empirical comparison of dependency issues in OSS Onoue, Hideaki Hata, Arnon Rungsawang, Pattara Lee-
packaging ecosystems. In IEEE 24th International Con- laprute, and Kenichi Matsumoto. Extracting insights
ference on Software Analysis, Evolution and Reengineer- from the topology of the javascript package ecosys-
ing, SANER 2017, Klagenfurt, Austria, February 20-24, tem. In 24th Asia-Pacific Software Engineering Con-
2017, pages 2–12, 2017. ference, APSEC 2017, Nanjing, China, December 4-8,
2017, pages 298–307, 2017.
[12] Alexandre Decan, Tom Mens, and Eleni Constantinou.
On the evolution of technical lag in the npm package [22] Timothy Libert. Exposing the hidden web: An analysis
dependency network. In 2018 IEEE International Con- of third-party HTTP requests on 1 million websites.
ference on Software Maintenance and Evolution, ICSME CoRR, abs/1511.00619, 2015.
2018, Madrid, Spain, September 23-29, 2018, pages 404–
[23] Konstantinos Manikas. Revisiting software ecosystems
414, 2018.
research: A longitudinal literature study. Journal of
[13] Alexandre Decan, Tom Mens, and Eleni Constanti- Systems and Software, 117:84–103, 2016.
nou. On the impact of security vulnerabilities in the
[24] Tom Mens. An ecosystemic and socio-technical view
npm package dependency network. In Proceedings of
on software maintenance and evolution. In 2016 IEEE
the 15th International Conference on Mining Software
International Conference on Software Maintenance and
Repositories, MSR 2018, Gothenburg, Sweden, May 28-
Evolution, ICSME 2016, Raleigh, NC, USA, October 2-7,
29, 2018, pages 181–191, 2018.
2016, pages 1–8, 2016.
[14] Alexandre Decan, Tom Mens, and Philippe Grosjean.
An empirical comparison of dependency network evo- [25] Gianluca Mezzetti, Anders Møller, and Martin Toldam
lution in seven software packaging ecosystems. CoRR, Torp. Type regression testing to detect breaking changes
abs/1710.04936, 2017. in node.js libraries. In 32nd European Conference on
Object-Oriented Programming, ECOOP 2018, July 16-
[15] Daniel M. Germán, Bram Adams, and Ahmed E. Hassan. 21, 2018, Amsterdam, The Netherlands, pages 7:1–7:24,
The evolution of the R software ecosystem. In 17th 2018.
European Conference on Software Maintenance and
Reengineering, CSMR 2013, Genova, Italy, March 5-8, [26] Nick Nikiforakis, Luca Invernizzi, Alexandros Kaprav-
2013, pages 243–252, 2013. elos, Steven Van Acker, Wouter Joosen, Christopher
Kruegel, Frank Piessens, and Giovanni Vigna. You
[16] Liang Gong. Dynamic Analysis for JavaScript Code. are what you include: large-scale evaluation of remote
PhD thesis, University of California, Berkeley, 2018. JavaScript inclusions. In CCS, pages 736–747, 2012.

[17] Jaap Kabbedijk and Slinger Jansen. Steering insight: [27] Brian Pfretzschner and Lotfi Ben Othmane. Identifica-
An exploration of the ruby software ecosystem. In Soft- tion of dependency-based attacks on node.js. In Proceed-
ware Business - Second International Conference, IC- ings of the 12th International Conference on Availability,
SOB 2011, Brussels, Belgium, June 8-10, 2011. Proceed- Reliability and Security, Reggio Calabria, Italy, August
ings, pages 44–55, 2011. 29 - September 01, 2017, pages 68:1–68:6, 2017.
[28] Alexander Serebrenik and Tom Mens. Challenges in [32] Nikos Vasilakis, Ben Karel, Nick Roessler, Nathan
software ecosystems research. In Proceedings of the Dautenhahn, André DeHon, and Jonathan M. Smith.
2015 European Conference on Software Architecture Breakapp: Automated, flexible application compartmen-
Workshops, Dubrovnik/Cavtat, Croatia, September 7-11, talization. In 25th Annual Network and Distributed
2015, pages 40:1–40:6, 2015. System Security Symposium, NDSS 2018, San Diego,
California, USA, February 18-21, 2018, 2018.
[29] Cristian-Alexandru Staicu and Michael Pradel. Freezing
the web: A study of redos vulnerabilities in javascript-
[33] Jie Wang, Wensheng Dou, Yu Gao, Chushu Gao, Feng
based web servers. In 27th USENIX Security Symposium,
Qin, Kang Yin, and Jun Wei. A comprehensive study on
USENIX Security 2018, Baltimore, MD, USA, August
real world concurrency bugs in node.js. In Proceedings
15-17, 2018., pages 361–376, 2018.
of the 32nd IEEE/ACM International Conference on
[30] Cristian-Alexandru Staicu, Michael Pradel, and Ben- Automated Software Engineering, ASE 2017, Urbana,
jamin Livshits. SYNODE: understanding and automat- IL, USA, October 30 - November 03, 2017, pages 520–
ically preventing injection attacks on NODE.JS. In 531, 2017.
25th Annual Network and Distributed System Security
Symposium, NDSS 2018, San Diego, California, USA, [34] Erik Wittern, Philippe Suter, and Shriram Rajagopalan.
February 18-21, 2018, 2018. A look at the dynamics of the javascript package ecosys-
tem. In Proceedings of the 13th International Con-
[31] Nikolai Philipp Tschacher. Typosquatting in program- ference on Mining Software Repositories, MSR 2016,
ming language package managers. PhD thesis, Univer- Austin, TX, USA, May 14-22, 2016, pages 351–361,
sität Hamburg, Fachbereich Informatik, 2016. 2016.