Created by

2017

The State of
Open Source
Security
The open source landscape is vast and only getting more diverse.
The overall security of open source is an important measuring
stick. We need to know where we stand today to know what we
can do better.

Any attempt to try and provide a global view of the ecosystem’s

security health requires data. To help better understand how
secure open source is and what we can all do to make it better,
Snyk distributed and analyzed a survey that was filled out
by more than 500 open source maintainers and users. We
also looked at Snyk internal data based on more than 40,000
projects, as well as information published by Red Hat Linux and
data we gathered by scanning millions of GitHub repositories
and packages on registries.

This report summarizes those findings.

TABLE OF CONTENTS THE STATE OF OPEN SOURCE SECURITY

At a Glance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 3

The Open Source

Landscape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 4
Adoption
Risks and Impact
Security Posture of Open Source Maintainers
How Many Vulnerabilities Are There?

The Open Source

Security Lifecycle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 9
Discovering Vulnerabilities
Releasing Fixes
Notifying Users

Adopting Published Fixes

The Future of
Open Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 18
For more information: https://snyk.io | contact@snyk.io
THE STATE OF OPEN SOURCE SECURITY
There’s no guarantee of the security

At a Glance knowledge of an open source maintainer.

Only 16.8% of maintainers consider their security

know-how to be high, and 43.7% have never
conducted a security audit on their code.
The number of open source
packages indexed has exploded
in the past year.
PERCENTAGE INCREASE: A test of 430,000 sites showed
Rubygems . . . . . . . . . . . . . . . . . . . 10% that 77% of them run at least
Python . . . . . . . . . . . . . . . . . . . . . . 32% one front-end library with a
Maven . . . . . . . . . . . . . . . . . . . . . . 28% known security vulnerability.
npm . . . . . . . . . . . . . . . . . . . . . . . . 57%

The number of open

Once a fix has been released, maintainers need to
source application library
vulnerabilities increased by
notify users so that they can secure their applications.
53.8% in 2016. Already in 88% of maintainers inform users through release notes, while only 9% file for a
2017, they’ve increased by an
CVE ID and only 3% inform a vulnerability monitoring service.
additional 39.1%.

Vulnerabilities generally remain The National Vulnerability

undiscovered for a long time. Database (NVD) has

2.5
seen a large increase in
The median time from inclusion to discovery
for in application libraries: years vulnerabilities, but coverage
can be an issue.

PERCENTAGE OF VULNERABILITIES
COVERED BY THE NVD:

npm . . . . . . . . . . . . . . 11%
Once discovered, maintainers
generally react very quickly. Rubygem . . . . . . . . . 67%

The median time from when a vulnerability is

disclosed to when it is fixed: 16 days

The State of Open Source Security 3

The Open Source
Landscape
Open source as a whole is thriving. Both Forrester and Gartner have stated that
somewhere between 80-90% of all commercial software developers use open source
components within their applications. Organizations all over the world, from every
vertical imaginable, use open source code to power their business.

Adoption
The use of open source components is booming, no matter libraries by 32%, the number of Maven artifacts by 28% and the
which ecosystem you look at. number of npm packages by 57%.

Through September of this year, 6.3 billion Python packages Meanwhile, the number of public applications available on
have been downloaded using PyPi and over 87.3 billion Node Docker Hub is now over 900,000, up from around 460,000
packages using npm. a year ago.

In the last year (October 1, 2016, to October 1, 2017), the number Simply put, there has never been a wider variety of open source
of open source packages indexed has exploded. The number components available, and it’s never been easier for us to
of Rubygems has increased by 10.3%, the number of Python use them.

npm Packages Downloaded, PyPi Packages Downloaded,

Per Day Average Per Day Average
PER DAY AVERAGE, IN MILLIONS PER DAY AVERAGE, IN MILLIONS

400
25
375

350
23
325

300 21
275

250 19
225

200 17
175

150 15
NOV FEB MAY AUG NOV FEB MAY AUG
2016 2017 2017 2017 2016 2017 2017 2017

The State of Open Source Security 4

Percentage Increase in Total Packages Indexed
OCTOBER 2016 – OCTOBER 2017

60%

50%

40%

30%

20%

10%

0%
npm PyPi Maven Rubygems

Risks and Impact Spotlight on Equifax

Chances are if you’re using open source code, security is a top
One of the most notable breaches of 2017 was the one
concern. In Github’s recent Open Source Survey, 86% of users
suffered by Equifax, resulting in millions of records being
said security was extremely or very important. But there are
exposed. The breach was accomplished by exploiting a
natural risks with open source — you don’t know who you’re
known vulnerability in the Apache Struts2 package which
downloading from, and the security standards and know-how
made it possible for a remote attacker to send a malicious
of maintainers differs dramatically between the different open
request that would allow them to execute arbitrary
source projects.
commands.
Known vulnerabilities in open source components also makes
for a very attractive attack vector. Once they have been publically The timeline of the vulnerability is what stands out. The
disclosed, exploits are quick to follow. vulnerability was publicly disclosed, and fixed, on March
6, 2017. One day later, exploit scripts started to appear in
Consider the Struts2 vulnerability (CVE-2017-5638) from this year. the wild. Two months later, on May 13, the Equifax breach
It was disclosed March 7th, 2017. Over the next six days, Imperva began. It took another two months (until July 29) to detect
reported seeing thousands of attempted exploits, coming from it. This vulnerability went from public to active exploits in
1,323 different IP addresses from over 40 countries. one day, to breach in two months. It’s never been more
critical to prioritize open source security.

The State of Open Source Security 5

Security Posture Of Open
Source Maintainers
The same freedom that allows open source to thrive also presents

43.7% 16.8%
challenges from a security standpoint. There are no “rules” that
open source development must follow to ensure a secure delivery,
so the security posture differs dramatically from one project to
another. The challenge for open source maintainers is that they of open source of open source
maintainers maintainers
are often maintaining these open source resources in addition to
have never had a consider security
other day-to-day work, and so don’t have an abundance of time
security audit know-how to be high
and resources to put towards securing their projects.

While the vast majority of people contributing code to open

source are good actors, only 16.8% of the maintainers we Currently, no standard exists for documenting basic security
surveyed said they consider their security know-how to be high. information about open source projects, and ad-hoc use is
One method of reducing the number of vulnerabilities included minimal. Of the top 400,000 public repositories on Github,
in an application is to conduct regular security audits—whether less than 10,000 currently have such a file in place—around
manually or by hiring a pentester—to see what security risks may 2.4% in total.
be as yet undiscovered. Yet 43.7% of open source maintainers Lacking any public information can make it very difficult to
say they have never had a security audit done on their code, and assess the overall commitment to security from any individual
another 31.8% say they’ve only audited their code once or twice in open source package or project, as well as to understand how
the lifetime of the project. to disclose newly discovered vulnerabilities to the open-
source maintainers.

How Maintainers
Rank Their Security How Often Maintainers
Expertise Audit Their Code
Next to At least
nothing At least quarterly
1% once a year
11%
Low High
13%
26% 17%

Once or Never
Medium
56%
twice 44%
32%

The State of Open Source Security 6

How Many Vulnerabilities Are There?
Mistakes will happen. According to a study by Carnegie Mellon
University, for every thousand lines of code in commercial
software, there are somewhere between 20-30 bugs. And as
53.8%
bugs are created, vulnerabilities will inevitably follow. increase in the number of open
source security vulnerabilities
published in 2016
Known Vulnerabilities In
Application Libraries
The number of published vulnerabilities in application libraries
has been steadily increasing since 2009 and shows no signs
Open Source Vulnerabilities
of slowing down. Last year (2016) saw a 53.8% increase in the Published by Year
number of open source security vulnerabilities published (based
on the Snyk database which tracks npm, Maven, Pip, Rubygems 900
and Go), and this year has already increased an additional 39.1% 800
over last year.
700
The problem extends to the front-end as well. In a test we
600
conducted of over 430,000 sites, 77% of them were running at
least one library with a known security vulnerability in place. 500
400

Known Vulnerabilities In 300

System Libraries 200
Looking at Red Hat Linux itself, we see the opposite trend. The 100
number of vulnerabilities impacting Red Hat Linux has been
0
steadily decreasing since 2012, dropping by 62% since then.
2007

2008

2009

2010

2011

2012

2013

2014

2015

2016

2017
Red Hat Linux Vulns
by Year REGULAR
CRITICAL

400
In a test we conducted of over 350
430,000 sites, 77% of them 300
were running at least one 250
library with a known security 200
vulnerability in place. 150
100
50
0
2007

2008

2009

2010

2011

2012

2013

2014

2015

2016

The State of Open Source Security 7

Trends in Severity
Raw vulnerability counts are one thing, but it’s fair to question downloads, as well as high severity vulnerabilities found in Java
whether or not they’re actually impactful. A high severity packages based on how prominent those packages are with
vulnerability found in a library with only a few downloads would our customers. In both cases, we found that the number of
inflate these numbers somewhat artificially. high severity vulnerabilities with high impact has been steadily
increasing. So far in 2017, we’ve seen a very similar trend
We took it a step further and looked at high severity
in growth.
vulnerabilities found in npm packages with over 50,000

Critical Java & Node Package Vulnerabilities

90
80
JAVA

70 NODE

60
50
40
30
20
10
0
2013 2010 2014 2017

Vulnerabilities in Docker Containers High Severity Vulnerabilities in

System Libraries
Containers face a similar challenge. Containers provide great
convenience by pulling all the libraries, packages, settings and Once again, Red Hat Linux vulnerabilities paint a different
more into a pre-configured environment. picture. The number of critical vulnerabilities impacting Red Hat
peaked in 2012 but otherwise has stayed mostly consistent from
But as with anything else,
year to year.
if they’re not kept up to
date, known vulnerabilities 76.6% Red Hat Linux seems to be finding some level of stability. While
tend to creep in. Of the top of the top 1,000 that is not the case of application libraries—where vulnerability
Docker containers
1,000 most popular Docker counts and severity is increasing—it does make us optimistic that
have known
containers, 76.6% have known vulnerabilities better security is achievable with a little bit of work.
vulnerabilities, and 62.3% of
them contain at least one high-
severity vulnerability.

The State of Open Source Security 8

The Open Source
Security Lifecycle
There are a lot of steps involved in the lifecycle of an open source security
vulnerability—from discovery through final adoption of fixes. Each part of
the process is important in its own way, and ultimately plays a role in the overall
state of security.

Discovering Vulnerabilities
How vulnerabilities are discovered and how long
they go unnoticed.

Releasing Fixes
The time it takes from disclosure to when a
vulnerability is addressed.

Notifying Users
How users are made aware of fixes to vulnerabilities.

Adopting Published Fixes

How quickly users adopt fixes once they’re published.

The State of Open Source Security 9

Discovering Vulnerabilities
The first period to look at is how long it takes for a vulnerability to be discovered after
it has entered the library.

The median time from when a vulnerability was introduced As a result, maintainers say they learn about vulnerabilities in
(included in a formal release) in an application library and when a variety of different ways. The vast majority of vulnerabilities
it was publically disclosed is 2.53 years (924 days). Studies have are discovered by someone outside of the project—only 25% of
repeatedly shown that for Linux vulnerabilities, on the other maintainers say they’ve discovered a vulnerability themselves.
hand, the time from introduction to public disclosure is around Open source maintainers are just as likely to receive a private
five years. This amplifies the importance of frequently conducting disclosure (31.4%) as they are to have a public issue filed on their
security audits—it’s very likely that there are numerous other repository (30.3%).
vulnerabilities that have just not yet been disclosed. Formally
Maintainers who have a public facing disclosure policy in place
auditing code is an important step for maintainers to take to
are far more likely to receive a private disclosure than those who
ensure the security of their projects.
do not. About 21% of maintainers with no public disclosure policy
have been notified privately about a vulnerability, compared to
How Do Maintainers Find Out 73% of maintainers with a disclosure policy in place.
About Vulnerabilities? There may also be some confirmation bias in play. While only
How these issues are disclosed and addressed are critical 13.5% of maintainers with a disclosure policy in place say
characteristics of the project’s overall security. In an ideal world, they’ve never had a security issue to their knowledge, 32% of
vulnerabilities should be reported to maintainers privately, letting maintainers with no policy say they’ve never had a security issue
them fix it before the world learns about the flaw. to their knowledge. While this could be the case of maintainers
putting a policy in place only after they’ve first had a security
In practice, the process of vulnerability disclosure doesn’t always issue reported to them, given the complications involved in
go smoothly. In part, this is because public facing disclosure disclosing without the guidance provided by a disclosure policy,
policies are few and far between. 79.5% of maintainers said that it’s just as likely that many vulnerabilities have been found and
they had no public-facing disclosure policy in place. This lack not disclosed.
of clear communication about disclosure makes it challenging
for researchers to report vulnerabilities in a private and
responsible manner.

Vulnerabilities: Vulnerabilities:
Inclusion to Disclosure Disclosure to Fix

5.9 years 94 days

Maximum time from inclusion to disclosure Maximum time from disclosure to fix

0 days 0 days
Minimum time from inclusion to disclosure Minimum time from disclosure to fix

2.5 years 16 days

Median time from inclusion to disclosure Median time from disclosure to fix

The State of Open Source Security 10

Releasing Fixes
The next period to look at is the “days of risk”: the time it takes from disclosure to
when a vulnerability is addressed. The moment a vulnerability is publicly disclosed,
the risk rises dramatically and continues to increase until the vulnerability has been
fixed and you can take action. For this, the picture is much rosier.

Handling Vulnerabilities How Quickly Could Maintainers

With Urgency Respond to a Vulnerability?
Open source maintainers are very eager to
Longer than
respond to security vulnerabilities as quickly Within a a month
month
5% 1%
as possible. 34% of maintainers said they
could respond to a security issue within a
day of learning about it, and another 60%
said they could respond within a week.

We see this reinforced by the response to

the most impactful npm vulnerabilities
we saw this year. The median time from Within Within
disclosure to when a fix has been included a day a week
in a formal release was 16 days. 34% 60%
Similarly, the majority of vulnerabilities
in Red Hat Linux are also fixed soon after
disclosure.

In 2016, 69% of Red Hat Linux

vulnerabilities were fixed within a day of
their public disclosure, and 90% were fixed
within 14 days of their public disclosure. Percentage of Vulnerabilities with
In fact, the pace of fixing has been steadily Known Fixes Available
improving since 2014.

Ruby

Rate of Fixing
While the cadence for fixes was Node

pretty good, the reality is that not all

vulnerabilities will be fixed. Looking
Maven
at the Snyk database, the number of
vulnerabilities with available fixes (once
you exclude issues like malicious packages)
Python
varies from ecosystem to ecosystem.

0% 25% 50% 75% 100%

The State of Open Source Security 11

 Spotlight on Nokogiri and LibXML
Sometimes the chain of dependencies can put open source While the vulnerability was published back in November
projects in a tough spot. This is the case for the massively of 2016, libxml2 has yet to incorporate a fix. This has left
popular Nokogiri library. Nokogiri uses the libxml2 library to Nokogiri in a tight spot where the vulnerability of the library
allow users to easily parse and extract data from XML, SAX, it depends on has ended up leaving it in a vulnerable state.
Reader or HTML documents. Nokogiri has tried to dissuade users from falling victim to the
attack through making the default configuration as secure as
Unfortunately, libxml2 has a vulnerability that can make it
possible, but until libxml2 addresses the issue, Nokogiri will
easy for an attacker to conduct an XML External Entities (XXE)
remain vulnerable.
attack (an attack that leads to issues like denial of service and
private information disclosure).

16.1%
Most of the time, fixes aren’t backported to other version
streams. Only 16.1% of the vulnerabilities in the Snyk DB have
fixes backported to other versions streams. The situation is
pretty much the same across ecosystems, except npm where
backporting is particularly rare: only 4.1% of npm fixes are applied Vulnerabilities in the
to other version streams.
Snyk database that have
The lack of backporting makes it hard for many to upgrade to the
new fix, as moving to a new major version of a library requires
fixes backported to other
time and effort to make any updates necessary to conform to the versions streams
changes the library made.

Percentage of Fixes Backported to Other Version Streams

npm

Ruby

Python

Java

0% 10% 20% 30%

The State of Open Source Security 12

Notifying Users
After a vulnerability has been addressed, users must be made aware quickly so that
they know what steps to take to secure their applications.

How Do Maintainers Tell Users About Security Issues?

(RESPONDENTS WERE ABLE TO SELECT MULTIPLE RESPONSES)

25%
88% They Don’t

Release Notes
10% 34%
88% File a CVE Deprecate
the Version
of maintainers
inform users through
release notes 3% Inform a Service
Like Snyk or Ruby Sec

The majority of maintainers, 88%, say they inform users through

the release notes if there has been a security issue and about 34% Spotlight on Next
of maintainers will deprecate the latest vulnerable version
to encourage adoption of the fix. Next, a framework for server-rendered React applications,
was discovered to have a directory traversal vulnerability
Of significant concern is the fact that an alarming 25% of this year. The vulnerability has been in Next since its initial
maintainers say they do not do anything to inform their users if release in October of 2016. The vulnerability was disclosed
there’s a security issue. Without any communication to the user May 31, 2017, and on June 1, Next released a new version of
about the vulnerability, it’s highly unlikely that users will quickly the library with a fix in place.
adopt the latest fix. Instead, the vulnerable version is likely to stay
in production long after users could have been protected from it. Not only does Next deserve credit for their rapid
remediation, but their response was equally applause-
One step not taken very often is the process of informing a worthy. While many times a security fix receives a one-liner
database or vulnerability monitoring service. Ideally, each in library release notes, Next took the opposite approach.
of these vulnerabilities winds up in a database of known In the release notes for the fixed version, they provided
vulnerabilities for consumers to peruse. Only 3% of maintainers detailed information about the vulnerability, how to
say they inform a service, such as Snyk, about the vulnerability. address it, who was impacted and where to stay up to date
on further security issues that may arise.
Finally, 8.9% of maintainers say they file for a Common
Vulnerabilities and Exposures (CVE) ID for the vulnerability–
a small percentage that hints at some of the trouble being
encountered by CVE.

The State of Open Source Security 13

CVE, CPE, and NVD
The U.S. Government created and sponsors the Common
Vulnerability Enumeration (CVE) list—a free dictionary of
This federated approach to
vulnerabilities. The CVE is an attempt to provide a single maintaining the vulnerability
destination for known vulnerabilities—not just for open source
and application dependencies, but also for consumers to peruse.
database is effective, but
CVE itself is a list, not a database, and contains minimal
many vulnerabilities are
information about the various vulnerabilities it references. still missed.
Providing more information is the National Vulnerability
Database (NVD). The NVD pulls from the CVE list (though
not always right away) and provides more information about the
11% 67%
npm vulnerabilities in the Rubygem vulnerabilities
Snyk database that are in the Snyk database that
covered by NVD are covered by NVD

CVE By Year

10,000

7,500

5,000

2,500

0
2001

2002

2003

2004

2005

2006

2007

2008

2009

2010

2011

2012

2013

2014

2015

2016

2017

vulnerabilities—from remediation details to providing a Common This federated approach to maintaining the vulnerability database
Product Enumeration (CPE) that helps to pinpoint which is effective, but many vulnerabilities are still missed.
product or application contains the vulnerability and a Common
Comparing to our open source vulnerability database, CVE/
Vulnerability Scoring System (CVSS) score to provide some
NVD coverage varies dramatically depending on the language
indication of the severity and characteristics of the vulnerability.
and ecosystem. For example, NVD covers only 67% of Rubygem
Overall, adoption of the NVD has been positive. Since its launch vulnerabilities and only 11% of npm vulnerabilities.
in 1999, the NVD has grown to over 81,000 vulnerabilities and
The other challenge CVE/NVD faces is the pace. While a CVE may
shows no signs of slowing down. Already in 2017, over 8,500
get applied relatively early, it frequently takes a long time for that
vulnerabilities have been added to the database—more than any
same vulnerability to make its way into the NVD and get a CVSS
other year in the history of its existence.
score and a CPE.

The State of Open Source Security 14

53% of the application library vulnerabilities were public
(whether in a vulnerability database, library release notes or
another mechanism) for four weeks or longer before being added
to the NVD. The long tail, in this case, is very long. 28.9% of
vulnerabilities were public for longer than half a year, and 9.4%
for longer than a year before being found in the NVD. ...most open source
Part of the reason why CVE lags behind is that most open
maintainers don’t
source maintainers don’t participate in filing CVEs when new participate in filing CVEs
vulnerabilities are discovered. As discussed before, when we
surveyed maintainers only 8.9% say they have filed a CVE when
when new vulnerabilities
a vulnerability was found. This will continue to be a challenge, are discovered.
unfortunately, for any attempt at a federated approach to
vulnerability management.

How Long Were Vulnerabilities Public

Before Being Added to NVD/CVE

0–1 week

1–4 weeks

4–8 weeks

8–12 weeks

12–16 weeks

16–20 weeks

20–24 weeks

24–28 weeks

28–32 weeks

32–36 weeks

36–40 weeks

40–44 weeks

44–48 weeks

48–52 weeks

52+ weeks

25 50 75 100

The State of Open Source Security 15

Adopting Published Fixes
The final timeline to look at is how quickly users adopt fixes once they’ve been
published. This can be challenging, as users must both learn the fix exists, and then
make sure the new version doesn’t break their application. In other words, this can
take some time.

According to our survey, developers use a variety of methods In fact, 38.7% of users don’t use tooling to help keep their
to keep their dependencies up to date—including occasional dependencies up to date. This inevitably leads either to situations
sweeps to bump versions (46.9%), using tools to alert them to where dependencies are not updated as frequently as they
vulnerabilities (41.6%), using tools to alert them to new versions should be, or to situations where a lot of strain is put on the
of dependencies (37.2%) and word of mouth (8.6%). development process.

Surprisingly, 16.3% of users say they don’t update their In the absence of tooling, an organization that takes security
dependencies. And while at first glance, the number of seriously must manually verify and validate new versions
users taking advantage of tools to help them manage their of dependencies to ensure its up-to-date and free of known
dependencies seems alright, there’s a lot of overlap. Quite a few vulnerabilities. In the face of the rapid rate of change within
users use both a tool to alert them to new versions and a tool to the open source community, this manual approach becomes
alert them to security issues. a troublesome bottleneck and is unmaintainable.

How Do Users Keep Dependencies

Up to Date? 38.7%
(RESPONDENTS WERE ABLE TO SELECT
of users don’t use
MULTIPLE RESPONSES)
tooling to help keep their
dependencies up to date

42%
47% Use tools to alert them 16.3%
to vulnerable of users say they
dependencies don’t update their
Occasionally dependencies
do a sweep to
bump versions

16%
9% 37% They don’t
update
Update when
they overhear or Use tools to update
someone points
out on new version of
dependencies

The State of Open Source Security 16

Download Numbers of Vulnerable
Library Versions
The pace of adoption tends to have a very long tail. Consider From May of 2016 through July of 2016 (the three months before
the popular Python “requests” library. The “requests” library the vulnerability was addressed), vulnerable versions of the
is is one of the most popular Python packages with just under “requests” package made up ~99% of all downloads. In August
12,000,000 downloads per month over the past year, and it was 2017, the month where 2.11.0 was released, vulnerable versions
hit by an HTTP Request Redirection vulnerability in 2016. Given plummeted to 56.6% of all downloads. After that initial burst,
its tremendous popularity, we can zoom in on the versions being however, the long tail kicked in. In September 2017, 22.4% of
used to give us an idea of how quickly users adopt fixes. all downloads of the “requests” package were still vulnerable
versions, despite the fix coming just over a year prior.

Vulnerable versions of Python’s “requests”

downloaded as % of total

100% Vulnerability Addressed

75%

50%

25%

0%
July October January April July
2016 2016 2017 2017 2017

The State of Open Source Security 17

The Future of
Open Source
Open source is booming, and there is quite literally no sign of it slowing down. But
while the benefits of open source are by now well known, knowledge of the risks are
still a work in progress. But that’s primed to change.

It’s clear we have some room for improvement, but it’s also If you’re pulling open source
clear we have a lot of opportunities to do so. It’s easy to see that components into your application, there
maintainers are eager to make their projects more secure and
are a few things you can do as well:
that users want to make security a priority in their open source
consumption. It’s just a matter of ironing out the wrinkles a bit. 1. Use a tool to automatically detect known vulnerabilities
in your third-party components so you can fix them as quickly
If you’re a maintainer, take three simple as possible.
steps to get started: 2. Contribute back. Most of the time, maintainers are working
1. Make sure your project has a public facing disclosure hard on open source projects in addition to their day-to-day
policy so that anyone who finds vulnerabilities can quickly report work. Rolling up your sleeves and helping address issues is one
them to you. of the best ways to ensure your favorite project stays healthy
and secure.
2. Run regular audits and security checks against your
codebase to make it easier for you to catch vulnerabilities before 3. Report vulnerabilities as responsibly as possible. If
they become public. you find something amiss, look for a private way to tell the
maintainers about it. If there’s no public disclosure policy, see
3. Make it clear to users of your project that you care if you can discretely inform them through email or some other
about security. Have detailed information that is clearly form of communication.
presented to them when a security issue is addressed, so they
know exactly how to proceed.

Securing open source is not something that will happen

overnight. As we’ve seen in this report, there are many
different considerations and factors that come into play.
But together, with all of us making a concerted effort to
take baby steps to improve our security posture, we
can improve the state of open source security, and in
the process, ensure that it remains a thriving and
vibrant ecosystem.

The State of Open Source Security 18