Subscribe to the InfoTech eNewsletter

infoTECH Feature

December 28, 2017

The State of Open Source Security Going into 2018

By Special Guest
Hardik Patel, Digital Marketing Consultant, Developer, Editor of News for Public

The year is coming to an end, and along with a number of Hot Tech Trends gaining momentum, the open source landscape continues to grow and diversify. It is important to evaluate the state of open source security in order to know where we stand and what can be improved. This article will provide you with the basics.

Growth and Popularity

Between 80 and 90% of all commercial software developers use open source code in their work to power their businesses.

At the beginning of the year, an average of about 230 million NPM packages were downloaded per day. By August, this figure grew to about 380 million.

PyPi packages also grew in popularity, reaching almost 25 million downloads per day in August.

From October 2016 to October 2017, the number of Rubygems increased by 10.3%, Python libraries increased by 32%, Maven artifacts grew by 28%, NPM packages increased by 57%, and the number of public applications on Docker Hub grew from about 460,000 to over 900,000.

Risk and Impact

With open source code drastically increasing in availability and popularity, security is becoming a top concern for many developers. Github’s recent Open Source Survey found that 86% of users consider security extremely or very important. Because you don’t know who you’re downloading from and the quality of maintenance can differ significantly between projects, there is a natural risk involved in using open source.

A majority of maintainers surveyed by Snyk admits to never having audited their code. At the same time, 16.8% of maintainers consider their security know-how to be high.

Equifax suffered one of the most notable breaches this year, resulting in the exposure of millions of records. Hackers exploited a known vulnerability in the Apache Struts2 package which made it possible for remote attackers to send a malicious request which allowed them to execute arbitrary commands.

This vulnerability was publicly exposed and fixed on March 6, and it only took one day for exploit scripts to appear. The Equifax breach took place two months later, from May 13th to July 30th. The timeline highlights the importance of prioritizing open source security, as Equifax could have prevented the catastrophic breach.

Mistakes are inevitable. According to a study by Carnegie Mellon University, there are somewhere between 20 and 30 bugs in every thousand lines of commercial software.

Open source vulnerabilities published per year have increased from under 100 to over 900 in the last five years. In just the last year, there has been a 53.8% increase.

The Open Source (News - Alert) Security Lifecycle

Many steps take place in the lifecycle of vulnerabilities in open source security, including discovery, release, creation of fixes, and final adoption of fixes.


It takes a median of 2.89 years after a bug is introduced for it to become publicly disclosed. 75% of these vulnerabilities are not discovered by a maintainer. 79.5% of maintainers do not have a public-facing disclosure policy in place.

Release of Fixes

The maximum time from the inclusion of a bug to its disclosure is 5.9 years, and the minimum is 0 days. The median time is 2.5 years.

The maximum time from the disclosure of a bug to the release of a fix is 94 days, the minimum is 0 days, and the median time is 16 days.

User Notification

While most authors will notify users of security issues with their code by releasing notes (88%) and/or deprecating the version (32%), a stunning 25% do not notify users.

The National Vulnerability Database, or NVD tries to mitigate this problem by providing a single destination and source for vulnerability information, but it suffers some issues with pace and coverage.

It often takes too long for vulnerabilities to become public on the NVD. Namely, 53% of the application library vulnerabilities were live for four or more weeks before being added to the NVD, and 28.9% were public for over six months.

Some vulnerabilities are not included at all. Only 11% of Node.js vulnerabilities and 67% of Rubygem vulnerabilities are covered by NVD.

Adopting Published Fixes

Finally, how quickly do users adopt fixes once they are published? The challenge here lies both in learning about the fix and making sure the new version does not break their application.

Statistics show that:

47% of users occasionally 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% don’t update

And 9% update when they hear someone else point out a need

The Future

While the benefits of open source are continuing to become more well known, universal knowledge of the risks is still developing. There is much room for development in terms of prioritizing the discovery and fixing of bugs, and especially the circulation of valuable information. From the statistics summarized here, it is clear to see there are many opportunities to make this happen.

For maintainers, it is crucial to have a public-facing disclosure policy, run regular audits and security checks, and make it clear to users that security is important to you.

For users, is is extremely important to use a tool that automatically detects known vulnerabilities in third-party components, help maintainers address issues when you can, and report vulnerabilities as responsibly as possible.

About the Author: Hardik Patel is a Digital Marketing Consultant, Developer, Editor of News for Public and professional Blogger. He has 5+ years experience in Development, SEO, SMO, SEM, Online reputation management, Affiliated Marketing and Content Marketing.

Edited by Mandi Nowitz

Subscribe to InfoTECH Spotlight eNews

InfoTECH Spotlight eNews delivers the latest news impacting technology in the IT industry each week. Sign up to receive FREE breaking news today!
FREE eNewsletter

infoTECH Whitepapers