2017 The State of Open Source Security

The open source landscape is massive 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.

Back To Top

Section 1/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 businesses.

Adoption

The use of open source components is booming, no matter which ecosystem you look at.

NPM Packages Downloaded per day average, in millions

November, 2016 December, 2016 January, 2017 February, 2017 March, 2017 April, 2017 May, 2017 June, 2017 July, 2017 August, 2017
217.1350915 194.2504784 223.1589162 258.49997 296.6753137 284.8085511 318.2758515 350.8741529 349.0866298 384.7504021

87.3 Billion Node packages were downloaded using npm between January 1 and September 30, 2017

PyPi Packages Downloaded per day average, in millions

November, 2016 December, 2016 January, 2017 February, 2017 March, 2017 April, 2017 May, 2017 June, 2017 July, 2017 August, 2017
18.77362653 17.33965084 19.97595223 22.40701539 23.21045481 22.2363891 22.05154506 24.19185367 24.09178432 24.56304603

6.3 Billion Python packages were downloaded between January 1 and Sept 30, 2017

It's not just downloads that have been on the rise. From October 1, 2016 through October 1, 2017…

  • The number of Rubygems has increased by 10.3%
  • The number of Python libraries has increased by 32%
  • The number of Maven artifacts has increased by 28%
  • The number of npm packages has increased by 57%
  • The number of public applications available on Docker Hub is now over 900,000, which is up from around 460,000 a year ago

Risk and Impact

Chances are if you’re using open source code, security is a top concern. In Github's recent Open Source Survey, 86% of users said security was extremely or very important. But there are natural risks with open source—you don’t know who you’re downloading from, and the security standards and know-how of maintainers differs dramatically between different open source projects.

How Often Have Maintainers Audited Their Code?

Never Once or twice At least once a year At least quarterly
43 31 13 11

16.8% of maintainers we surveyed said they consider their security know-how to be high.

Vulnerabilities

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 bugs are created, vulnerabilities will inevitably follow.

Open Source Vulnerabilities Published Per Year

2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017
4 7 4 29 52 85 201 396 420 646 899

53.8% increase in the number of open source application library security vulnerabilities published in 2016

Red Hat Linux Vulnerabilities Per Year

Regular vulnerabilities Critical vulnerabilities
2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017
254 315 383 357 327 374 344 312 195 142 37
18 40 48 54 52 89 48 31 56 47 12

65% decrease in Red Hat vulnerabilities since 2012

Critical Java and Node Vulnerabilities Per Year

Java vulnerabilities Node vulnerabilities
2013 2014 2015 2016
13 32 42 88
4 7 19 30
Back To Top

Section 2/3 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

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

2.89 years is the median time from when a vulnerability was introduced to when it was publicly disclosed
75% of vulnerabilities are not discovered by the maintainer
79.5% of maintainers said that they had no public-facing disclosure policy in place
21% of maintainers who do not have a public disclosure policy have been notified privately about a vulnerability
73% of maintainers who do have a public disclosure policy have been notified privately about a vulnerability

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. For this, we zeroed in on the nine npm package vulnerabilities that impacted the most applications in 2017.

Maximum time from inclusion to disclosure: 5.9 years
Minimum time from inclusion to disclosure: 0 days
Median time from inclusion to disclosure: 2.5 years
Maximum time from disclosure to fix: 94 days
Minimum time from disclosure to fix: 0 days
Median time from disclosure to fix: 16 days
  • 34% of maintainers said they could respond to a security issue within a day of learning about it, and 60% said they could respond within a week
  • 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
  • 86% of the application library vulnerabilities in the Snyk database have a fix available
  • Only 16.1% of application library vulnerabilities have fixes that are backported to other version streams

Notifying Users

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

How Do Authors Tell Users About Security Issues Respondents gave multiple answers

88% Release notes

34% Deprecate the version

25% They don't

10% File a CVE

3% Inform a service like Snyk or RubySec

How Long Vulnerabilities Were Public Before Being Added to the NVD

The National Vulnerability Database (NVD) is an attempt to provide a single destination for vulnerability information, but faces a few challenges around pace and coverage.

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
75 88 28 13 2 18 14 1 7 13 8 22 10 5 32

53% of the application library vulnerabilities were public for 4+ weeks before being added to the NVD

28.9% of vulnerabilities were public for longer than half a year

  • Only 11% of Node.js vulnerabilities are covered by NVD
  • 67% of Rubygem vulnerabilities are covered by NVD

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.

How Users Keep Dependencies Up to Date Respondents gave multiple answers

47% Occassionally do a sweep to bump versions

42% Use tools to alert them to vulnerable dependencies

37% Use tools to update to new versions of dependencies

16% They don't Update

9% Update when they overhear or someone points out a need

Vulnerable requests Downloads

The requests library is is one of the most popular Python packages, with just under 12 million downloads per month over the past year. In 2016, it was hit by a vulnerability. Given its tremendous popularity, we can zoom in on the versions being used to give us an idea of how quickly users adopt fixes.

May, 2016 June, 2016 July, 2016 August, 2016 September, 2016 October, 2016 November, 2016 December, 2016 January, 2017 February, 2017 March, 2017 April, 2017 May, 2017 June, 2017 July, 2017 August, 2017 September, 2017
99.45 99.46 99.5 56.63 44.21 45.78 42.93 40.27 38.92 37.48 33.39 34.56 31.22 30.08 27.19 25.88 22.44

22.4% of all downloads of the requests package in September 2017 were still vulnerable versions, despite the fix coming just over a year prior

Back To Top

Section 3/3 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.

Take Action

It’s clear we have some room for improvement, but it’s also clear we have a lot of opportunities to do so. It’s easy to see that maintainers are eager to make their projects more secure and 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.

Do You Maintain Open Source Code?

  1. Make sure your project has a public-facing disclosure policy so anyone who finds vulnerabilities can quickly report them to you.
  2. Run regular audits and security checks against your codebase to make it easier for you to catch vulnerabilities before they become public.
  3. Make it clear to users of your project that you care about security. When a security issue is addressed, clearly present your users with detailed information so they know exactly how to proceed.

Do You Use Open Source Code?

  1. Use a tool to automatically detect known vulnerabilities in your third-party components so you can fix them as quickly as possible.
  2. Contribute back. Most of the time, maintainers are working hard on open source projects in addition to their day-to-day work. Rolling up your sleeves and helping address issues is one of the best ways to ensure your favorite project stays healthy and secure.
  3. Report vulnerabilities as responsibly as possible. If you find something amiss, look for a private way to tell the maintainers about it. If there’s no public disclosure policy, see if you can discreetly inform them through email or some other form of communication.

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.