The state ofopen source
security report
2019

03

Table of contents

Vulnerability characteristics of each ecosystem
XSS vulnerabilities						27SQL injection vulnerabilities					28Sensitive information exposure					2900Regular expression denial of service				30State of open source security report 2019
TL;DR - The state of open source security 2019 report,

02

The open source landscape				31

Cleartext transmission of sensitive information			An introduction to this report				3at a glance						4

01Path traversal			04

32

The open source security lifecycle
Discovering vulnerabilities					34Open source security ownership					

35Adoption						6Finding out about vulnerabilities					

36Risks and impact 					9Spotlight: Vulnerabilities without CVEs

Indirect dependencies					10Time to adopt security fixes					

38Security posture of open source maintainers 		 11How do maintainters find out about vulnerabilities?		

39

Security audits						12Inclusion to disclosure						40			37Spotlight: Equifax, a year later					41Releasing fixes							42Known open source vulnerabilities
Known vulnerabilities in application libraries 		

14

Trends in severity 					

16Spotlight: Zip Slip 					

17Known vulnerabilities in system libraries 			

18

Known vulnerabilities in docker images 			

20

Vulnerability differentiation based on image tag 		22

Spotlight: Malicious packages 				

24Rate of fixing							43Spotlight: Responsible security disclosures				

05

44

The future of open source
Take action							46TL;DR - Report summary						47An introduction to this report
Adoption of open source software has continued over recent years,

To better understand the open source security landscape, and what

and in 2018 we specifically witnessed how enterprise organizations

we can all do to make it better, we gathered information from astrengthened their stakes on open source software. For example,

number of public and private data sources including the following:in 2018 alone, IBM acquired RedHat for $34 billion, further provingthat open source software is becoming the foundation for theèèmodern enterprise. Microsoft acquired GitHub for $7.5 billion,
demonstrating the commercial opportunity in building tools for the
open source community.
As adoption of open source software continues to grow rapidly, therisk of exposure to security vulnerabilities is also increasing.

a survey created and distributed by Snyk that was completed byover 500 open source maintainers and users.

èèinternal data from the Snyk vulnerability database, as well as
hundreds of thousands of projects monitored and protectedby Snyk.

èè

research taken from external sources published by various
vendors and data gathered by scanning millions of GitHub
repositories and packages on public registries.

Let’s start by showing you some of the key takeaways from this reportas a dashboard on the following page.

All rights reserved. 2019 © Snyk

3

TL;DR - The state of open source security 2019 report, at a glance Open source adoptionèè

Growth in indexed packages, 2017 to 2018

Known vulnerabilitiesèèćć Maven Central - 102%èèćć npm - 37%

by 47%. Maven Central and PHPćć RubyGems - 5.6%

Packagist disclosures grew by 27%

èèvulnerabilities found in RHEL, Debianindirect dependencies

and Ubuntu as compared to 2017èè37% of open source developers don’t
implement any sort of security testing

èè

èè

èè

Snyk statsèèfor its users to remediate vulnerabilities intheir projectsèèmaintainers consider themselves tohave high security knowledge

CVE/NVD and public vulnerability
databases miss many vulnerabilities, only

68% of users feel that developers should

Only three in ten open source

In the second half of 2018 alone, Snyk
opened more than 70,000 Pull Requests

accounting for 60% of the vulnerabilities
Snyk tracks

docker container images

was added to an open source package until it

All rights reserved. 2019 © Snyk

own the security responsibility of their

The median time from when a vulnerability
was fixed was over 2 years

base image tag

81% of users feel developers are
responsible for open source security

44% of scanned docker images can fix
known vulnerabilities by updating their

Who's responsible foropen source security?

during CI and 54% of developers don't do
any docker image security testingsèèèè

Vulnerability identification

Each of the top ten most popular default
vulnerable system libraries

In 2018, we tracked over 4 times more

78% of vulnerabilities are found in

Known vulnerabilities indocker images
docker images contains at least 30

and 56% respectively

npm reported 304 billion downloads





èè

In 2018, vulnerabilities for npm grewćć NuGet - 26%

for 2018
èè

88% growth in application vulnerabilities
over two years

ćć PyPI - 40%

èè



èè

In 2018 alone, 500 vulnerabilities weredisclosed by Snyk’s proprietary dedicatedresearch team4

01

Nobody would question that open source software
has made an incredible impact on modern softwaredevelopment, and continues to expand every year.
GitHub reported that 2018 had seen more newusers signing up than during all of its first six years
combined. This is accompanied with a 40% rise in new

The open source
landscapeorganizations and new repositories created on theplatform, making 2018 the year during which almost
one third of all repositories that exist on GitHub
were created.
Open source software is everywhere too contributions are made across all languages andplatforms, impacting growth in different industries
and, as per Forrester’s report*, is an essential part of abusiness technology strategy.

* Miller, Paul. Nelson, Lauren E. “Open Source Powers Enterprise Digital
Transformation.” Forrester, 25 April 2016 (source)Adoption
We’ve seen big technology players doubling-down

We may see further growth in numbers from 2018

on open source in 2018 as mentioned already earlier

due to undisclosed vulnerabilities that will only bein this report. Let’s look at the numbers. In every

publicized later this year, further amplifying theregistry we reviewed, we saw an increasing rate of

direction of this trend.

open source libraries being indexed in every
language ecosystem. This is to be expected, but therate of growth may come as a surprise to many.

Total packages indexed per ecosystem

All but one ecosystem presents two-digit numbers
for increased growth in new libraries added to open

1000000

source registries: Maven Central, with a strong
growth of 102%, followed by PyPI with 40%, npm
with 37%, NuGet with 26% and lastly RubyGems with

750000Maven Central

5.6% growth of newly indexed packagesin the registries.

npm

500000Use of open source isaccelerating. In 2018, Javapackages doubled, and npm
added roughly 250,000
new packages

NuGet
PyPI

250000

RubyGems0
Jan 2017

All rights reserved. 2019 © Snyk

Jan 2018

Jan 2019

6

In 2018, The Linux Foundation reported that open

We can see how open source package growth

The spike in download count mid-year is due tosource contributors have committed over 31 billion

translates into user adoption when looking at thea fault in linehaul, the statistics gathering service

lines of code to date. However, with great adoption

download numbers for various packages infor PyPI, which missed recording about half of thecomes great responsibility and risk that need to bedifferent ecosystems.

downloads up until around August. The missing

mitigated by anyone who owns, maintains or uses

downloads presumably add up to more than thethis code. In 2017 the CVE list reported more thanExamining the python registry, PyPI boasts

14,000 vulnerabilities, breaking the record for the

more than 14 billion downloads during 2018, andmost CVEs reported in a single year. 2018 continued

doubles the download count in our 2017 report of

the record-breaking streak with over 16,000

approximately 6.3 billion downloads.

recorded 14 billion downloads of 2018.

vulnerabilities reported.

Number of PyPI packages downloaded in 2018
Open source software
consumption is also taking
huge leaps forward. Twice as
many Python packages were
downloaded from PyPI, and astaggering 317 billion JavaScript
packages from npm

2.5 bil.
2 bil.
1.5 bil.
spike due to PyPI stats
gathering service issue

1 bil.
500 mill.
0
Jan

All rights reserved. 2019 © Snyk

Feb

Mar

Apr

May

Jun

Jul

Aug

Sep

Oct

Nov

Dec

7

The npm registry is core to the entire JavaScript

The increased adoption of Docker containers further

ecosystem. It has seen steady growth for both theamplifies the strong growth of open source software.

number of packages being added and downloaded

Docker Inc, the de-facto library and community

consistently over the years. It featured more thanfor container images, reports more than 1 billion

30 billion downloads just for the single monthcontainer downloads every 2 weeks over the lastof December 2018, and an incredible 317 billion

year, and about 50 billion to date, with more thandownloads for the entire year of 2018.

1 million new applications added into Docker Hub

As package counts grow,so do their vulnerabilities.
A record setting 16,000
new vulnerabilities weredisclosed in 2018

over the last year alone.

Number of npm packages downloaded in 201840 bil.
30 bil.
20 bil.
10 bil.
0
Jan

All rights reserved. 2019 © Snyk

Feb

Mar

Apr

May

Jun

Jul

Aug

Sep

Oct

Nov

Dec

8

Risks and impact
It shouldn't come as a surprise to most that in thisThe more we use open source software, the more risk

year’s State of the Octoverse report from GitHub,

we accumulate as we’re including someone else’s

security is the most popular project integration

code that could potentially contain vulnerabilities

app category with more than one integration for

now or in the future. Moreover, risk doesn’t solely

developers. Here’s a quote from industry analyst

reflect how secure the code is but also the licensing

Gartner in a recent application security report thatcompliance of code you adopt and whether thatcovers the necessity for organisations to test forcode is in violation of the license itself.

security as early as possible in the application lifecycle.

Only one in threedevelopers can addressa high or critical-severity
vulnerability in a day
or less

All rights reserved. 2019 © Snyk

Almost half (43%) of
respondents have at least
20 direct dependencies,
amplifying the need to monitor
for open source vulnerabilities
introduced throughthese libraries“

Enterprises should use SCA tools on a regular basis to audit repositories that containsoftware assets (such as version control and configuration management systems) toensure that the software developed and/or used by the enterprise meets security andlegal standards, rules and regulations. Application developers should have access to
SCA tools to inspect the components they plan to use.
— Mark Horvath, Hype Cycle For Application Security 2018, Gartner

9

Indirect dependencies
It is hard to imagine the days of writing software

Of course, finding the vulnerabilities in a dependency

Additionally, being able to suggest the steps

without any open source dependencies. Managing

is just the first step. Being able to precisely determine

to take that will eliminate the vulnerability

dependencies for a project is an important task, andall the paths through the dependency tree in which

while preserving the compatibility between

requires due diligence to correctly keep track of thethe vulnerable dependency can be reached is a more

dependencies is an even greater and much morelibraries you depend upon. After all, the application

complex issue.

interesting challenge.

you are deploying bundles your code as well as
your dependencies.

Most dependencies in npm, Mavenand Ruby are indirect dependencies,
requested by the few libraries
explicitly defined. Vulnerabilities inindirect dependencies account for
78% of overall vulnerabilities

Snyk has scanned over a million snapshot

The direct and indirect dependency split acrossecosystems
DirectIndirect

100%

75%

50%

projects and has discovered that vulnerabilities inindirect dependencies account for 78% of overallvulnerabilities. This further amplifies a critical need for

25%clear insight into the dependency tree and the need to
be able to correctly highlight nuances of a vulnerable
path in order to address these vulnerabilities.

All rights reserved. 2019 © Snyk

0%
PyPI

PHP
Packagist

Maven
CentralRubyGems

npm

10Security posture of open source maintainers
Most developers and maintainers will likely agree that

This year, the majority of users ranked their security

The most movement is seen with the low and highsecurity should play an important role when buildingknow-how as medium, with an average of 6.6 out of

rankings. Last year, security know-how was ranked

products and writing code. However there are no text-

ten. A small portion of them (7%) ranked themselves

as high by only 17%, while this year it has increased

book rules for maintainers to follow for building open

as low, whereas the medium know-how ranking,to almost 30%. In addition, we can see similarsource projects, and as such their security standards

representing the majority of users, has actually

growth in low-ranked security know-how, which

can vary significantly.

declined to 63% vs 56% last year.

reached 26% last year but only 7% this year.

Maintainers find themselves using their time andefforts on different aspects of the project, often
functional, which in turn, could make security less ofa priority for them in their process.

OS maintainers are confident in their own
security knowledge
7%

There’s a positive trend towards security engagement
and awareness since the time of our previous report,

30%

released in 2017.

High

Open source maintainers
stated their security
knowledge is improving
but not high enough,averaging 6.6/10

MediumLow

63%

All rights reserved. 2019 © Snyk

11

Security audits
A security audit could exist as part of a code review

across all audit cycles as compared to last year’s

keep up with the fast pace of modern,where peers ensure that secure code best practices arereport with an increase of an average 10% of users

continuous development.

followed, or by running different variations of security

auditing their source code more often over theaudits such as static or dynamic application security

quarterly and yearly cycles.

Shifting left, especially in security, is key andtesting. Whether manual or automatic audits, they are

at times even critical, to reducing the cost

all a vital part of detecting and reducing vulnerabilities

Security professionals often cite the shift-leftof security incidents that are only found inin your application, and should be executed as

mantra in support of handling security concerns andproduction. One way to address security earlier

regularly and early in the development phase as

potential problems earlier in the application lifecycle.

in the process and to increase the chances ofpossible in order to reduce risks of exposure and data

This approach can uncover many valuable insights

developers adopting those practices is to selectbreaches at a later stage.

for developers through automation and help security

tools that are developer friendly and built to
integrate with their existing workflows.

One in four open
source maintainers
do not audit theircode bases

OS maintainers differ in their code auditing cadence
10%
26%

Every couple of years
or more21%

At least once a quarter

Last year 44% of respondents stated they had neverrun a security audit, while this year, the number is

At least once a year

considerably lower with 26% of users stating they
do not audit their source code. We’re seeing positive
trends toward repeated auditing actions this year

All rights reserved. 2019 © Snyk

At least once a month

We don’t

21%
21%

12

02
Known open source
vulnerabilities

A vulnerability is a vulnerability, whether known or not.
The key difference between the two is the likelihood of
an attacker to be aware of this vulnerability, and try to
exploit it. Therefore, the better known the vulnerability
is, the more urgent it is to deal with it.
A known vulnerability might have a CVE ID associatedwith it as part of a responsible disclosure, or it mightjust be disclosed on the internet or stored in open
databases. These are all types of known vulnerabilities
that you should prioritize eliminating as they have ahigher chance of being attacked in production. Afterthese, vulnerabilities that are captured in closed
vulnerability databases or even shared in the dark web
should be considered.

Known vulnerabilities in application libraries
Today, we’re witnessing an increase in the number

We may see further growth in numbers from 2018of vulnerabilities reported across many of thedue to undisclosed vulnerabilities that will only beecosystems that we track, including PHP Packagist,

publicized later this year, further amplifying theMaven Central Repository, Golang, npm, NuGet,

direction of this trend.

RubyGems, and PyPI.

In 2018, new disclosuresfor npm grew by 47%, andMaven Central grew by 27%

In 2017, we saw a 43% increase of vulnerabilities
reported across all registries, and in 2018 thevulnerability count grew by a further 33%.
When examining the five different ecosystems:

New vulnerabilities each year by ecosystem
2000

PHP, Java, JavaScript, Python and Go, we see anincreasing trend in the number of vulnerabilities
disclosed across all of them since 2014.

1500

PHP Packagist
Maven Central

1000

Vulnerabilities arefound at an increasing
pace, nearly doubling in
the last 2 years

Golang500

0

All rights reserved. 2019 © Snyk

npm

PyPI

2014

2015

2016

2017

2018

14

In 2018 vulnerabilities disclosed for PHP Packagist
grew by a staggering 56%, and for Maven Central,
disclosures increased by 27%. Although Golang is asmaller ecosystem, it has growing security researchand reported 52% new vulnerabilities in 2018 over 2017.
Looking back at the data from 2014 in Snyk’s

Since 2014, the number ofvulnerabilities in Snyk's
database for npm grewby 954% and for MavenCentral by 346%

vulnerability database, we see a strong overall
increase in the number of vulnerabilities acrossthe board.
Today, we track 1766 vulnerabilities in the MavenCentral Repository, 1268 in npm, 746 in PHP Packagist,
807 in PyPI, and 94 in Golang.
Since 2014, the number of vulnerabilities in the Snyk
database has increased by an astonishing 371%, with
npm vulnerabilities increasing by an incredible 954%
and Maven Central vulnerabilities increasing by 346%.

All rights reserved. 2019 © Snyk

15

Trends in severity
When we look at vulnerability severity for

Vulnerability severities by year

application libraries disclosed over the last three
years across all language ecosystems, 2018 shows asmaller number of high vulnerabilities as compared1000

to the previous year.
However an interesting insight for both 2017

776

750

660

and 2018 is that there were more high severity
vulnerabilities than medium or low vulnerabilities
as compared to 2016.

540
467

500

Low

455
355

Medium

250

High

73

30

39
0
2016

All rights reserved. 2019 © Snyk

2017

2018

16

Spotlight: Zip Slip
In 2018, the Snyk Security research team responsibly disclosed many

thousands of projects, including ones from HP, Amazon, Apache,instances of a vulnerability dubbed Zip Slip, a widespread arbitrary

Pivotal, and many others.

file overwrite critical vulnerability. It can be exploited using a
specially crafted archive that holds directory traversal filenames

The research that spanned various ecosystems uncovered tens

and typically results in remote command execution.

of vulnerabilities in libraries such as Apache Ant, adm-zip,
SharpCompress and others used by thousands of projects for Java,It was discovered and responsibly disclosed by the Snyk Security

npm, NuGet, Go, .NET, Ruby, Python and C++. Almost half of themteam ahead of a public disclosure on 5th June 2018, and affects

were found to be of high severity.

“

When we discovered the first instance of the Zip Slip vulnerability in a big project,
it was very exciting. It was our eureka moment, but when we discovered that every
other application had a vulnerable implementation, we were extremely surprised.
We realised that this vulnerability wasn’t just affecting a few apps, but loads ofprojects across ecosystems.
­— Danny Grander, Snyk CSO

All rights reserved. 2019 © Snyk

17

Known vulnerabilities in system libraries
There is an increase in the number of vulnerabilities

Linux OS vulnerabilities steadily increasing

reported for system libraries, affecting some of the
popular Linux distributions such as Debian, RedHat
Enterprise Linux and Ubuntu. IIn 2018 alone we
tracked 1,597 vulnerabilities in system libraries with

RHEL

DebianUbuntu2500

known CVEs assigned for these distros, which ismore than four times the number of vulnerabilities

2000

compared to 2017.

1500
1000
500
0
2008

All rights reserved. 2019 © Snyk

2009

2010

2011

2012

2013

2014

2015

2016

2017

2018

18

As we look at the breakdown of vulnerabilities

High and critical vulnerabilities in system libraries(high and critical) it is clear that this severity levelHigh

is continuing to increase through 2017 and 2018.

Critical

5000

4000

3000

2000

1000

0
2014

All rights reserved. 2019 © Snyk

2015

2016

2017

2018

19

Known vulnerabilities in docker images
The adoption of application container technology

Accordingly, we’ve scanned through ten of

is increasing at a remarkable rate and is expected

the most popular images with Snyk’s recently

to grow by a further 40% in 2020, according toreleased docker scanning capabilities.

Docker images almost
always bring known
vulnerabilities alongside
their great value

451 Research. It is common for system libraries to
be available in many docker images, as these rely

The findings show that in every docker image

on a parent image that is commonly using a Linux

we scanned, we found vulnerable versions of

distribution as a base.

system libraries. The official Node.js image ships
580 vulnerable system libraries, followed by theDocker Hub provides insights into the most popularothers each of which ship at least 30 publicly

docker images.

known vulnerabilities.

Number of OS vulnerabilities by docker image
600

580

500

89

100

85

69

61

61

47

47

47

couchbasememcached

redis

30

0
node

All rights reserved. 2019 © Snyk

postgres

nginx

httpd

mongo

mysql

ubuntu20

Snyk recently released its container vulnerability
management solution to empower developers to fully
own the security of their dockerized applications.
Using this new capability, developers can find known
vulnerabilities in their docker base images and fix themusing Snyk’s remediation advice. Snyk suggests either
a minimal upgrade, or alternative base images that
contain fewer or even no vulnerabilities.

Fix can be easy if you’reaware. 20% of images can
fix vulnerabilities simply
by rebuilding a docker
image, 44% by swappingbase image

Based on scans performed by Snyk users, we found that
44% of docker image scans had known vulnerabilities,
and for which there were newer and more secure baseimage available. This remediation advise is uniqueto Snyk. Developers can take action to upgrade their
docker images.
Snyk also reported that 20% of docker image scans had
known vulnerabilities that simply required a rebuild of
the image to reduce the number of vulnerabilities.

All rights reserved. 2019 © Snyk

21

Vulnerability differentiation based on image tag
The current Long Term Support (LTS) version of the

Alpine Linux handles vulnerabilities differently thanNode.js runtime is version 10. The image tagged withthe other major distros, who prefer to backport sets

10 (i.e: node:10) is essentially an alias to node:10.14.2-

of patches. At Alpine, they prefer rapid release cycles

jessie (at the time that we tested it) where jessie

for their images, with each image release providing a

specifies an obsolete version of Debian that is no

system library upgrade.

longer actively maintained.

Most vulnerabilities
originate in the base image
you selected. For that reason,
remediation should focus onbase image fixes

If you had chosen that image as a base image inyour Dockerfile, you’d be exposing yourself to 582

Number of vulnerabilities by node image tag

vulnerable system libraries bundled with the image.
Another option is to use the node:10-slim image tag

600

582

which provides slimmer images without unnecessary
dependencies (for example: it omits the main pages

500

and other assets). Choosing node:10-slim however
would still pull in 71 vulnerable system libraries.

400

The node:10-alpine image is a better option to choose300

if you want a very small base image with a minimal setof system libraries. However, while no vulnerabilities

200

were detected in the version of the Alpine image wetested, that’s not to say that it is necessarily free of

100

71

security issues.

00
node:10

All rights reserved. 2019 © Snyk

node:10-slim

node:10-alpine
22Moreover, Alpine Linux doesn’t maintain a security

A practice that some teams follow is to use a specificUsing the Snyk Docker scanning features we foundadvisory program, which means that if a systemversion tag instead of an alias so that their basethat when a project uses a specific version tag suchlibrary has vulnerabilities, Alpine Linux will not issue

image would be node:10.8.0-jessie for example.

as node:10.8.0-jessie, we could then recommend

an official advisory about it; Alpine Linux will mitigate

However, as newer releases of Node 10 are released,

newer images that contain fewer vulnerabilities.

the vulnerability by creating a new base image version

there is a good chance those newer images will

including a new version of that library that fixes theinclude fewer system library vulnerabilities.

issue, if one is available (as opposed to backporting
as mentioned).
There is no guarantee that the newer fixed version, ofa vulnerable library will be immediately available on
Alpine Linux, although that is the case many times.
Despite this, if you can safely move to the Alpine
Linux version without breaking your application, you
can reduce the attack surface of your environment
because you will be using fewer libraries.
The use of an image tag, like node:10, is in reality
an alias to another image, which constantly rotateswith new minor and patched versions of 10 as they
are released.

All rights reserved. 2019 © Snyk

23

Spotlight: Malicious packages
You may have heard about malicious packages in a variety ofèèa socially engineered inclusion of a malicious package (or acontexts, such as a malicious docker container or perhaps a malicious

package that will be malicious after inclusion) into a project

package in a public registry of one ecosystem or another. We havelist of dependencies

also discussed developers as a malware distribution vehicle in several
other contexts such as the Induc malware that infected Delphi

In 2018 we saw occurrences of all of these malicious package types

compilers and XCodeGhost that targeted iOS and OSx developers.

in the npm ecosystem, known for being one of the registries that
suffers from malicious packages more than others. The package that

However, not all malicious packages are the same in nature.

recently made the news in December 2018 was event-stream. It reliedWith regards to ecosystem registries we can broadly classify themon a malicious dependency that was delivered through a seemingly

into the following:

innocent attempt to make an open source contribution.

èèa typosquatting attack where a malicious package uses a very

This hack affected a staggering 8 million downloads of the malicious

similar name of a more popular package

package in only two months. Another example in 2018 is the ESLintscope package in which the maintainer’s account was compromised.

èèa compromised maintainer’s CI or registry account resulting in

We also saw a total of 11 typosquatting attacks for malicious packages

the publishing of a malicious version, or a malicious package

published in 2018 on the npm registry.

residing in a project’s list of dependencies

All rights reserved. 2019 © Snyk24

In addition to the typical typosquatting attempts that we’ve seenin the past, we also saw more mature malicious attempts to attack

In 2018, a malicious
package was downloaded
a record 8 million times. It
was one of 25 typosquatting
attacks in npm and PyPI

the npm ecosystem than in previous years, such as the ESLint-scopeattack. With much higher sophistication, the event-stream incident
exposed a high level of expertise and targeted attacks than we’veseen in previous malicious attempts in the ecosystem to date.
In contrast to the npm registry, the only other registries in which
we identified malicious packages were RubyGems with just one
malicious package in 2018, and Python with ten malicious packages
in 2017 and thirteen in 2018.

All rights reserved. 2019 © Snyk

25

03
Vulnerability
characteristics
of eachecosystem

We were curious to learn more about the distinct
vulnerability families found within each ecosystem
in order to better understand what attackers target
for exploitation.

XSS vulnerabilities
Cross-site Scripting (XSS) attacks have been an ever-

XSS vulnerabilities disclosed by year

increasing pain point for web applications and we see
the trend in XSS vulnerabilities spiking in 2018 across200

all ecosystems that Snyk has been monitoring.

150

XSS vulnerabilities in open
source libraries are still on
the rise, despite being a top
concern by OWASP for morethan 15 years

Within these ecosystems, we’ve detected that thenpm ecosystem has seen the most XSS vulnerabilities,
disclosing 225 in total; followed by Maven Central

100

50

0
2014

2015

2016

2017

2018

Repository with 167; and PyPI with 163 total crosssite scripting vulnerabilities. In 2018, the PHP
Packagist ecosystem disclosed the most with 56 XSS
vulnerabilities, followed by npm with 54, and MavenCentral with 29.

All rights reserved. 2019 © Snyk

27

SQL injection vulnerabilities
Another common attack vector that is consistently
featured in the OWASP’s top 10 over the past decade

SQL injection disclosures show spikes by
year and ecosystem

is CWE-89, more commonly known as SQL Injection.
Looking across the last three years, we can see thateach of the three main ecosystems we reviewed have

2016

2018

2017

20

peaks during different years. Maven libraries leadthe number of SQL injection vulnerabilities disclosed
in both 2016 and 2017, followed by PHP Packagist

16
15

libraries, which hit a peak in 2018.

10

8
6

5

0

4

3

2

5
3%

0
npm

All rights reserved. 2019 © Snyk

4

Maven Central

PHP Packagist

28

Sensitive information exposure
Looking at the Maven Central and PHP Packagist

The PyPI registry also has a good amount ofregistries we found they had the most vulnerabilities

vulnerabilities found in libraries, with examples ofrelated to information exposure, peaking in 2018 for

information exposure vulnerabilities. Packages such

both ecosystems.

as django displayed a user password hash to admin
users who only had View permissions. The package

Information exposures often happen unintentionally.

djangorestframework-api-key saved API keys in

They occur when a program or system discloses

plain text.

potentially sensitive information, such as environment
variable names and values. Cases of information
exposure may also occur “by design” such as whensensitive data is provided within URL parameters.
Several examples of information exposure
vulnerabilities in the Maven Central registry are

Sensitive information exposure vulnerabilities
affecting the Java ecosystem
100

2016

2018

2017

apache spark, jenkins core, keyclock-saml-core
packages. Jenkins ssh-agent CI plugin, for example,

75

leaked the SSH private key in the build logs for anyone
with Read permissions to see.

53
50

23

25

0

1

2
npm

All rights reserved. 2019 © Snyk

31 27

8

9

12

PHP Packagist

7

11
1

3

RubyGems

Maven Central

17
9

PyPI

29

Regular expression denial of service
The Node.js runtime is known to have many
strengths, but one of them, the single threaded Event
Loop, can also be its weakest link if not used correctly.
This happens more regularly than one might think.

Regular expression denial of service (ReDoS)
disclosures on the rise
80

Regular expression denial of service (ReDoS)
attacks exploit the non-linear worst-case complexity
vulnerabilities that some regex patterns can lead60

to. For a single-threaded runtime this could be
devastating, and this is why Node.js is significantly
affected by this type of vulnerability.

40

We found that there were a growing number of
ReDoS vulnerabilities disclosed over the last three
years, with a spike of 143% in 2018 alone.

20

0
2016

All rights reserved. 2019 © Snyk

2017

2018

30

Path traversal
Path and directory traversal vulnerabilities fiercely
stand out in the npm ecosystem with record

Path traversal vulnerabilities most commonly
seen in npm

numbers of 146 and 143 disclosures in 2017 and 2018,
respectively. The other ecosystems are much further
behind, which is a good thing!
One might presume that this may be attributed to theplethora of static and dynamic web servers built with

2016

2018

2017

200

146 143150

Node.js for both production and development use,
and therefore there are many more packages in which

100

such vulnerabilities might also be found.
50

0

0

2

3

RubyGems

All rights reserved. 2019 © Snyk

1

3

5

PHP Packagist

3

6
PyPI

21
3

5

17

Maven Central

4
npm

31

Cleartext transmission of sensitive information
Last but not least is another unique vulnerability
worthy of mention in the npm ecosystem, CWE-319,
also known as Cleartext Transmission of Sensitive
Information, in which resources are accessed overinsecure protocols. We were able to find 44 newreported vulnerabilities in packages from 2016,“

The state of an ecosystem's security and its public perception are often
extremely different. The lack of typing in JavaScript has spread the ideathat it is an unsafe language due to type manipulation, but in any case, thenumber of vulnerabilities discovered in npm modules over the last couple

and this number further rises to a hefty total of 110

of years is still lower than those discovered on Maven central. At the same

packages in 2017, a 250% increase.

time, some vulnerabilities may be exacerbated because Node.js is still
mono-threaded. ReDoS (or other CPU-exhaustion DoS), which is much
more common in the Node.js world, is an example of this. Hopefully,
Worker Threads will soon enable Node.js, in order to reduce these risks.
The security community in Node.js has been more and more active inthe past years and we can continue to work hard so that the ecosystem
becomes safer in the future.
­— Vladimir de Turckheim, Node.js Foundation Security WG

All rights reserved. 2019 © Snyk

32

04

A healthy approach to embracing security as partof the SDLC is to integrate it within the entire
development lifecycle, from design to production.
This significantly differs from the more traditional

The open source
security
lifecycle

one-off phase of security testing that occurs
periodically and doesn’t fit the modern, fast-paced
software delivery model. However, processes andguidelines may not be enough. Education, friendly
tooling, and engagement with R&D teams andstakeholders are just as important to the healthy
adoption of security practices within an organization.

Discovering vulnerabilities
It takes a great deal of knowledge, experience, anda sharp eye to properly code review for potential
security vulnerabilities within one’s own code. As
this isn’t a straightforward task, if carried out at all, itsuggests that vulnerable code may stay dormant for along time until it is picked up by anyone.

“

Another finding in our research is that teams that build security into their work also
do better at continuous delivery. A key element of this is ensuring that information
security teams make pre-approved, easy-to-consume libraries, packages, toolchains,and processes available for developers and IT operations to use in their work.
­— Nicole Forsgren, Accelerate: The Science of Lean Software and DevOps: Building
and Scaling High Performing Technology Organizations

Teams that practice DevOps or have a mature CI/
CD pipeline may find it easier to introduce security
testing as part of their build automation, yet we findthat almost 40% of users don’t implement any sortof security testing during their CI runs. A reassuringnote however is that more than half of them are atthe very least testing for vulnerabilities in their open
source dependencies.

Security testing during CI
No, we don’t have any automatedsecurity testing during CI

37%

We statically test our own
source code for vulnerabilities

37% of users of users
don’t implement any sortof security testing
during CI

36%

We test for known vulnerabilities inour open source dependencies

57%

We test for known vulnerabilities
in our container images

14%
0%

All rights reserved. 2019 © Snyk

10%

20%

30%

40%

50%

60%

34

Open source security ownership
When facing such alarming statistics, we set out to

According to 81% of respondents, developers shouldfind who in practice owns the security responsibility

own the security of their application code, sendingof an application or library today, as well as who users

a strong statement about the involvement andthink should take ownership of security.

engagement level that is expected from developers,
and supports the strong DevSecOps movement
which many are adopting today.

Who is responsible for security?
100%

81%
75%

50%

28%
23%

25%

12%
3%

0%
Security teamAll rights reserved. 2019 © Snyk

Developers

Operations

Other

Nobody35

Finding out about vulnerabilities
Snyk stats

From the user’s perspective, it is interesting to gain

A worrying 27% of respondents stated they do notinsights into how they learn about vulnerabilities inhave any proactive or automatic way to find out

their application dependencies in order to respond toabout newly discovered vulnerabilities in theirpotential threats as they are discovered.

applications. Only 36% of users confirmed that they

more than 70,000 Pull Requests for its

use a dependency management or scanning tool tousers across Maven, RubyGems and npm

help surface vulnerabilities.

ecosystems to remediate vulnerabilities inèèIn the second half of 2018 alone, Snyk opened

their projects.
èèHow do you find about vulnerabilities?

Java project, Snyk provided a remediation

2%

path to fix vulnerabilities that were found27%

I probably won’t
I read the release notes of most of my direct andindirect dependencies

36%

When my security team reports a severe vulnerability,
we search for apps using this component
We track the list of dependencies against public
databases (e.g. CVEs) ourselves

16%
9%

Out of all the dependencies in a scannedin 60% of them. It’s not always possible
to fix remediation paths when there is nocompatibility between a direct dependency
and a fixed version of an indirect dependency.
The Snyk Security team can provide custom
patches to fix some of these situations.

We use a dependency management/ scanning toolthat notifies us
Other

10%

All rights reserved. 2019 © Snyk

36

Spotlight: Vulnerabilities without CVEs
It is common for security teams to keep track of, and to react to,

In addition to comprehensiveness, CVEs and public databases are

new vulnerabilities as they are disclosed through the National

often slow to add vulnerabilities. If we look at npm as an example,

Vulnerabilities Database (NVD), or other public CVE repositories.

vulnerabilities only show up in npm audit an average of 92 days after
they are captured in Snyk's DB, and lag behind 72% of the time.

However, a good number of security vulnerabilities are discovered
and fixed in non-official channels such as through informal

These gaps indicate the CVE system and public open source

communication between maintainers and their users in an

databases are not currently coping with the pace and volume ofissue tracker.

open source software vulnerabilities. These mechanisms should be
reevaluated, and security conscious organisations should seek out

The Snyk database is carefully curated by an internal security

commercial databases for timely and broad coverage.

analysts team, and tracks vulnerabilities not included in these official
sources but mentioned in public locations such as forums or release
notes. Using Snyk's DB as a barometer, we see it uncovers 67% more
vulnerabilities than public databases.

All rights reserved. 2019 © Snyk

37

Time to adopt security fixes
How long does it take users to adopt new releases thatprovide security fixes to known vulnerabilities? We

Downloads of the vulnerable PyPI
websockets package in 2018

turned to Python’s PyPI registry and its websockets
package for an example to see how popular

30000

vulnerability disclosed

vulnerable releases continued to be used even after avulnerability fix was released.

25000

The websockets project is a fairly popular andwell-maintained package, dating back to 2013 andshowcasing regular releases to the present day.
In August 2018 a denial of service vulnerability was

20000

15000

disclosed to the community, affecting versions 4.0
and 4.0.1 of the package. At the time of disclosure,
newer versions already existed on the registry that

10000

provided the security fix, however looking at the
download counts for the vulnerable versions, a

5000

long trail of users still fetch vulnerable versions of
websockets can be seen.

0
AugustSeptember

OctoberNovember

December

By December 2018 we’re still tracking 11k downloads ofthe websockets package that contain the vulnerability,
even though there is a fixed version available as amajor upgrade with websockets version 5.0.

All rights reserved. 2019 © Snyk

38

How do maintainers find out about vulnerabilities?
It is more likely that maintainers be alerted toFurthermore, while the majority of users (72%) say

a security concern than it is that they find out

they review their own code to find vulnerabilities,

themselves. An industry-accepted best practice is

48% of users still learn about vulnerabilities in theira responsible disclosure policy, which details how

code only when someone else opens a public issue,

security researchers and individuals should safely

demonstrating how hard it is to rely on just one

report security vulnerabilities to project maintainers.

maintainer reviewing code even if that maintainer isperceived to have good security knowledge.

From the survey data, we can conclude that almost
half (48%) of respondents find out about a security
vulnerability that is in their code from a publicchannel, such as when someone else is opening apublic issue or contacting them over email.
72% of users said they find out about vulnerabilities
in their code when they review their own code
personally; however 62% of users have stated they
have only medium-level security know-how whereas
only 30% of them state their security expertise is high.

How do maintainers find out about vulnerabilities?
72%

When I review my code30%

Through an external audit
By someone openinga public issue

48%

By someone sendingme an email

37%
9%

Other

17%

I don’t0%

All rights reserved. 2019 © Snyk

10%

20%

30%

40%

50%

60%

70%

80%

39

Inclusion to disclosure
One of the research questions we wanted to

As this is more time-consuming and tricky to

Of these six libraries, we saw that the quickest

answer was how long it takes from the time aaccurately automate, we looked at the top six

time-to-fix from inclusion was almost one year, orvulnerability enters the code base and until it

npm libraries and analysed their code bases to see

289 days to be precise. The median time is almost

is discovered and disclosed? To answer this, we

the differences between the dates of the commits

2.5 years, and the worst case we saw was 5.9 years.

set out to analyze several top libraries in thethat introduced the vulnerability and fixed thenpm ecosystem and the vulnerabilities that werevulnerability. Of course, these calculations are

discovered in them during 2018.

slightly biased because we’re using such a small
sample size, but the range and order of numbers areinteresting all the same!

Vulnerabilities - days of inclusion to disclosureDay
1

Vulnerability
included

All rights reserved. 2019 © Snyk

Quickest
time-to-fix

Day
886

Slowestresponse timeMedian
Day
289

Day
2250

40

Spotlight: Equifax, a year later
A recent report released by the US government deemed theèè

any new build run by a CI server would automatically test

infamous Equifax breach as completely preventable, andapplication dependencies via a CI server plugin or a CLI

demonstrated how important it is to shift security to the left by

invocation as a task. This would immediately flag the new

integrating it into the development workflow.

vulnerability, breaking the CI job and forcing a remediation
action before continuing.
èèa monitoring solution was in place that notified developers of
the new vulnerability in their dependencies.

Further monitoring and runtime insights into how the application
behaves and what vulnerable functions it invokes could have alerted
With a DevSecOps mindset and good practices employed, aof vulnerabilities in the Struts library.

development team could have prevented the Struts vulnerability
making such an impact if:èèdevelopers would have found the issue by adopting open source
dependency scanning tools that integrate with their workflow
using IDE plugins or code linters.

All rights reserved. 2019 © Snyk

41

Releasing fixes
A crucial part of a responsible security disclosure is

Vulnerability report response times

the speed of fix and roll out. It’s important to be able

6%

to address the vulnerable issue as quickly as possible,
thereby reducing the time it exists in the code, and10%

also to provide sufficient time for users to upgrade to

22%
A few hours

a fixed version, preferably before the issue iscommon knowledge.

A day or lessAs the nature of open source communities revolves

A week or lessaround mostly volunteer work of developers (a BIG
thank you to all the wonderful people who contribute

A month or lessto open source software – your kind work is verymuch appreciated and rarely acknowledged orappreciated publicly!), it is interesting to gauge how
fast maintainers of open source software can react to aOver a month27%

security vulnerability and provide a fix.
An overwhelming majority of users, totaling 84%,
state they are likely to respond with a fix in less than35%

a week. 56% are likely to address it within a day, while
22% state they can address a security issue within a
few hours after the vulnerability has been reported –not all heroes wear capes!

All rights reserved. 2019 © Snyk

42

Rate of fixing
Examining the Snyk vulnerability database we can

Package vulnerabilities with known fixes

determine which packages have released versions
that contain vulnerability fixes. This paints a lessthan ideal picture for some ecosystems – looking at
you JavaScript! Java and Python exhibit ecosystems

84%

RubyGems

with strong attention to security vulnerabilities,
whereas JavaScript and Node.js as a whole showthat only 59% of packages have known fixes fordisclosed vulnerabilities.

59%

npm

Maven
Central

97%

PyPI

98%
0%

All rights reserved. 2019 © Snyk

25%

50%

75%

100%

43

Spotlight: Responsible security disclosures
A significant benefit of having a responsible disclosure policy is to

About 21% of maintainers with no public disclosure policy have

keep users out of harm’s way. When a vulnerability is reported andbeen notified privately about a vulnerability, as compared to 73% of

triaged in a confidential manner with the project maintainer it allows

maintainers with a disclosure policy in place.

the maintainer to prepare a fix before the information is disclosed
to the general public. If maintainers can act quickly and release a

Websites are susceptible to web security vulnerabilities and would

fix, then they provide a window of time during which their users

benefit from clear guidelines about web security policies.

can upgrade to the fixed version. This time window significantly

An emerging proposal to aid with this is the SECURITY.TXT (RFC

decreases the number of users that consume the vulnerable versions.

5785) which has seen early adoption already. The purpose of suchas policy file is to effectively communicate to security researchers

We believe that having a responsible disclosure policy in place will

the relevant contacts, preferred languages, exact policy and ways

also communicate the maintainer’s high commitment to security.

of communication, including public keys to securely and efficiently

We recommend to use a badge on the project’s homepage, anddisclose security vulnerability.

including a SECURITY.MD policy file in the project’s repository as agood practice.
In the last report we found that maintainers who have a public-facing
disclosure policy in place are far more likely to receive disclosuresfrom users in confidence, than those who do not.

All rights reserved. 2019 © Snyk

44

The future of open source
Open source is a core part of virtually all software applications today. Even the Java and Node.js platforms are open source! There’s no getting
away from the obvious fact that open source is here to stay and a welcome part of modern software development. It’s easier than it has ever been
to create a new open source project, as well as use other projects from other members of the community. This speed of development and sharing
has led to coding standards and practices varying greatly between open source projects, as it’s not always easy for developers to think about theconsequences of unintentionally sharing insecure code. In the great, wise, and slightly adapted words of Dr. Malcolm:“Your developers were so preoccupied with whether or not they could, they didn't
stop to think if they should.
­— Dr. Ian Malcolm, Jurassic Park

We’d like to conclude this report with some security advice for both open source project maintainers as well as those who consume open source
dependencies. Oh, I guess that’s pretty much everyone then!

All rights reserved. 2019 © Snyk

45

Take action
As OS maintainers and developers there are actions you can take to improve the security in projects you own and contribute to.

Open source maintainers

Open source developers

As an open source maintainer, you should offer secure releases of your code andAs a consumer of open source components, it’s your responsibility to fully

provide a communication strategy to those consumers in order to positively

understand the direct and indirect dependencies your projects use, including

impact other projects and applications, ultimately benefiting your own projects

any security flaws that might exist in that dependency tree. Consider adopting

as well.

the following security guidelines:

èè

èè

èè

èè

Practice secure code review with your peers if possible and follow securecode best practices. Make security considerations part of your code review

vulnerabilities in your third-party dependencies, providing remediation

checklist and educate those who are reviewing so that they know what they

advice to your team and monitoring a project’s dependencies even after itshould be looking for.

has been deployed.

Regularly audit your code base for vulnerabilities, through static and dynamic

èè

Follow responsible disclosure policies if you are reporting a security

code analysis, for example, that can be automated into your development

vulnerability to make sure you don’t put users in harm’s way. If you areworkflow and make it easier to catch vulnerabilities before they

unsure about how to do this, consider disclosing to a security company

become public.

that work through the disclosure with you, such as Snyk’s responsible
disclosure program.

Clearly define a simple process for communication of responsible disclosures,using your own policy or by referring to an existing program. To communicateèèRegularly audit your code base with a tool that automatically detects

èè

Subscribe to the security communication channels of your open source

your security awareness consider adopting a SECURITY.MD policy and adependencies, if they have them, so you’re aware of any potential

project badge that reflects the security health of the project.

vulnerabilities as they are reported.

Implement a shift-left security strategy that provides your team the insight
into security issues during development, CI, and even when pull requests are
created to eliminate all chances of vulnerable code entering your projects.

All rights reserved. 2019 © Snyk

46

TL;DR - Report summary
Data in this report was collected from thefollowing sources:

Open source adoptionèè

GitHub saw a 40% rise in new organizations and new repositories
created in 2018

Internal data from the Snyk vulnerability databaseèèAlmost one third of all repositories that exist on GitHub were created in 2018èè

Hundreds of thousands of projects monitored and protected by Snyk

èè

Growth in indexed packages from 2017 to 2018.

èèResearch taken from external sources published by various vendorsèèScanning millions of GitHub repositories and packages on public registriesèèOver 500 open source maintainers and users

èèćć Maven Central - 102% growthćć PyPI - 40% growthćć npm - 37% growthćć NuGet - 26% growth

Known vulnerabilities in application libraries
èè

Security vulnerabilities almost double in two years. In 2017 we saw a 43%
increase in the number of vulnerabilities reported. In 2018, that total
increased by a further 33% across all registries

èèThe number of Golang vulnerabilities grew in 2018 by 52%èèSince 2014, the number of vulnerabilities in the Snyk database has increasedby an astonishing 371%, with npm vulnerabilities increasing by an incredible
954% and Maven vulnerabilities increasing by 346%

Security ownershipćć RubyGems - 5.6% growthèè

The CVE list reported a record-breaking number of vulnerabilities reported
in 2018, which now totals more than 16,000 vulnerabilities in the
database overallèè

npm reported 304 billion package downloads for the entire year of 2018.

èè

Docker reported over 1 billion container downloads every 2 weeks over thelast year, and about 50 billion to dateèèDocker also reported 1 million new applications added into Docker Hub overthe last yearèè

78% of vulnerabilities are found in indirect dependenciesèè

On average, open source maintainers rate their own security knowledge
as 6.6/10

èè

81% of users feel developers are responsible for securityèèOnly 28% of users feel security teams are responsible for securityèèèè

68% of users feel that developers should own the security responsibility of
their docker container images

Only 3 in ten open source maintainers consider themselves to have highsecurity knowledgeèè

One in four open source maintainers do not audit their code bases

All rights reserved. 2019 © Snyk

47

Vulnerabilities in docker images

Vulnerability characteristics of each ecosystemèèEach of the top ten most popular default docker images contains at least 30
vulnerable system librariesèè

In 2018 there were 11 typosquatting attacks for malicious packages
published on the npm registryèè

44% of scanned docker images can fix known vulnerabilities by updating
their base image tagèèèè

20% of docker image scans had known vulnerabilities that simply requireda rebuild of the image to reduce the number of vulnerabilities

The number of XSS vulnerabilities is again on the increase. In 2018 the
PHP Packagist ecosystem disclosed the most with 56 XSS vulnerabilities,
followed by npm with 54, and Maven Central with 29èèèè

37% of open source developers don’t implement any sort of security testingin their CI and 54% of developers don’t do any docker image security testing

Path and directory traversal vulnerabilities fiercely stand out in the npm
ecosystem with record numbers of 146 and 143 disclosures in 2017 and2018, respectivelyèèThe number of Cleartext Transmission of Sensitive Information
vulnerabilities has increased by 250% since 2016

Known vulnerabilities in system librariesèè

1597 vulnerabilities in system libraries with known CVEs were raised in2018 for the Debian, RHEL and Ubuntu distributions

Discovering vulnerabilitiesèè

In 2018, we tracked over four times more vulnerabilities found in RHEL,
Debian and Ubuntu compared to 2017

èèAlmost 40% of open source users don’t implement any sort of security
testing during CIèèAccording to 451 Research, the adoption of application container
technology is expected to grow by a further 40% in 2020

èèOver half of open source users test for vulnerabilities in their open
source dependencies

èè

Ruby's default docker image ships with 583 system library vulnerabilities

All rights reserved. 2019 © Snyk

48

The Snyk Vulnerability database

Adopting fixesèèèè

84% of users state they are likely to respond to a fix in less than a weekèè

22% state they can address a security issue within a few hours of a reportèè

27% of users stated they do not have any proactive or automatic way tofind out about newly discovered vulnerabilities in their applications.

èè

Only 36% of users confirmed that they use a dependency management or
scanning tool to help surface vulnerabilities

èèIn the second half of 2018 alone, Snyk opened more than 70,000 Pull
Requests for its users across Maven, RubyGems and npm ecosystems toremediate vulnerabilities in their projects

CVE/NVD and public vulnerability databases miss many vulnerabilities, only
accounting for 60% of the vulnerabilities Snyk tracksèè

In 2018 alone, 500 vulnerabilities were disclosed by our proprietary researchèè

72% of the vulnerabilities in npm audit were added to the Snyk vulnerability
database firstèè

On average, Snyk discloses vulnerabilities 92 days sooner than they are
published on npm-audit

How do maintainers find out about vulnerabilities?
èè

Almost half (48%) of respondents find out about a security vulnerability thatis in their code from a public channel, such as a public issueèè

72% of users said they find out about vulnerabilities in their code when they
review it

Inclusion to disclosureèèOf the seven libraries we analysed, the quickest time-to-fix from inclusion
was 289 days. The median time is almost 2.5 years, and the worst case we
saw was 5.9 years

All rights reserved. 2019 © Snyk

49

Snyk helps you use open source and stay secure.
Get started at snyk.io

Report author
Liran Tal (@liran_tal)

Twitter: @snyksec
Web: https://snyk.io

Report contributors
Simon Maple (@sjmaple)

Office info

Guy Podjarny (@guypod)

LondonTel Aviv

Boston1 Mark Square

40 Yavne st., first floor

WeWork 9th Floor

London EC2A 4EG

501 Boylston St
Boston, MA 02116

Rachel Cheyfitz (@spinningrachel)Report design
Growth Labs (@GrowthLabsMKTG)