The State of Open Source Security 2020

So...is Open Source Security Still a Thing?

You bet! We’ll show you why open source security matters now more than ever.

As expected, the trend of incredible growth in open source development ecosystems continues.  Github reported in its State of the Octoverse report, that more than 10 million new users joined GitHub last year bringing the total number of developers on their platform to over 40 Million.  And this holds true for the diversity of development ecosystems - from npm, to Maven Central,  Ruby and more. 

Data is knowledge, and by sharing data aggregated from multiple sources we hope to make it possible for developers to improve their open source security posture, as early as possible in the development lifecycle.

Snyk is proud to announce the release of our State of Open Source Security report for 2020!

This report sheds light on the current security posture of open source software and reflects on open source security concerns, trends in vulnerabilities across packages and container images, and also examines the practices employed by maintainers and organizations in securing their software.

Key takeaways from the report:

Open source adoption

Open source ecosystems continue to expand, led by npm which grew over 33% in 2019, now spanning over 1,300,000 packages to this date.

The majority of open source vulnerabilities continue to be discovered in indirect dependencies:

• npm - 86%

• Ruby - 81%

• Java - 74%

Open Source Security Culture

• This year the responses showed more focus on shared responsibility:

  • 85% of users feel developers are responsible for open source security

  • 55% security teams

  • 35% for operations

• Only 15% of our survey respondents implement Security champions programs, widely recommended in OWASP Software Assurance Maturity Model (SAMM)

Vulnerability trends

• New vulnerabilities down by 20% across the board

• Cross-site scripting vulnerabilities were the most commonly reported.

Container & orchestration challenges

• Official base images tagged as latest include known vulnerabilities

• Over 30% of survey participants do not review Kubernetes manifests for insecure configurations.

• Requirements for security-related resource controls in Kubernetes are not widely implemented.

5 Open source security trends in 2020:

1. Improved security mindset and culture within organizations

2. Reduction in the number of new vulnerabilities across the most popular ecosystems

3. The most-reported vulnerability types do not correlate to the highest impact on software projects

4. Using official images for containers is not a replacement for regular security hygiene

5. Vulnerability remediation timelines do not match well with expectations from the community

Open source security: cultural shifts showing real progress

When talking about DevSecOps, the core concept is the culture of shared responsibility across development, security, and operations engineering. That’s why one of the most exciting insights this year is seeing a real, tangible shift in attitude regarding who is responsible for security practices within the organization.

This year the responses showed more focus on shared responsibility for security with 85% saying developers, alongside 55% and 35% for operations.

Critical toward shifting to a true DevSecOps culture is establishing programs that reinforce shared responsibility within organizations. While the trend seems to be heading in a positive direction, the data still indicates that many have not yet implemented these practices. In our survey, 47% of respondents said there are no specific programs in place to drive such shared responsibility. 

Security champions programs, widely recommended and defined as a key practice in the OWASP Software Assurance Maturity Model (SAMM), are only implemented by 15% of our survey respondents. Cross-functional collaboration in stand-up meetings was equally uncommon at only 15% as well.

New vulnerabilities down by 20% across the board

One of the particularly surprising findings in this year’s report, and certainly a trend to watch for the future was the number of new open source vulnerabilities reported in open source packages.  After seeing numerous spikes in vulnerabilities across ecosystems in last year’s report, it’s great to see a drop in new open source vulnerabilities reported across the most popular software development ecosystems.

While there is no specific data point that could be identified to explain this change, an optimistic view suggests that this could be an aggregate of various improvements, including better awareness among developers, improving organizational practices, and advanced open source security tools in pipelines. While we’re hesitant to declare this a victory for secure coding, the trend is one we’ll be keeping a close eye on.

This trend is particularly notable when you take into account the exponential growth of these ecosystems in general. The open source landscape more than doubled in some ecosystems, yet the growth of vulnerabilities is not showing matching growth. This is certainly something worth paying attention to for the future.

Vulnerability prevalence doesn’t correlate to impact

Every single year cross-site scripting (XSS) is in the top three in terms of prevalence of reported vulnerabilities. This is despite the fact that XSS has been a widely-discussed open source security concern since it was included in the first OWASP Top 10 in 2003.

However, while more XSS vulnerabilities were reported in open source software in 2019 than any other category of vulnerability, the number of projects impacted by those vulnerabilities is relatively low.

On the other hand, less prevalent and less commonly understood vulnerabilities, such as prototype pollution, impacted a surprisingly high number of projects. In particular, two highly publicized prototype pollution vulnerabilities in the very popular Lodash and jQuery packages resulted in a much greater impact in terms of the number of projects affected.  Lodash alone is used by 4M+ projects on GitHub and, after reviewing Snyk’s data, 25% of projects scanned were affected by these prototype pollution vulnerabilities.

So how do we explain this?

There are a few factors that contribute to this seemingly contradictory data.  Given that there are so many reported XSS vulnerabilities, yet so few affected projects, it is logical to conclude that they are being discovered in less mature and less popular projects.

Meanwhile, vulnerabilities identified in highly popular packages tend to be more complex or less understood vulnerabilities. This suggests improving awareness and an overall improvement in package health for more popular packages—ultimately, a very promising sign.

Container security

The results are very similar to what we saw in last year’s research. Official images contain a significant number of known vulnerabilities. One particularly worrying example is the Node image that has 642 vulnerabilities, up from 580 last year—a nearly 11% growth year over year in vulnerabilities in one image alone. While that is an extreme example, other official images also contained significant vulnerabilities as well.

The Postgres, MySQL, and nginx images each contain more than 60 known vulnerabilities.  The concerning part is that based on web content, there seems to be a misconception among some developers that if it is an official container image, it is inherently secure. This simply isn’t the case at all. 

Using an official image is not a replacement for maintaining proper container security hygiene. Developers and organizations should certainly do the work to identify vulnerabilities within container images, as well as mitigate or remediate the container security vulnerabilities found.  Many of these container images contain libraries that aren’t even always required to support the software they’re intended to host.  A good container security practice is to use the leanest container image possible, with as few libraries as possible. In some cases, we see that using an alternative slim image can reduce the number of container security vulnerabilities by as much as 95%!

Vulnerability remediation, expectations versus reality

In our 2020 open source security survey, we asked about the expectation for remediation time for a vulnerability in an open source project. 47% responded that the expectation is that the vulnerability be fixed within a week (or less) of its discovery and nearly 18% said they expect a fix within a day. 

However, when looking at how quickly vulnerabilities are fixed in scanned projects we found a very different story around open source security:

• 35% of vulnerabilities were fixed in under 20 days

• 36% took 70 days or more to be remediated

• the average time to remediate a vulnerability was 68 days.

This demonstrates that organizations need to better align their expectations to improve their overall risk management.

When leveraging open source projects you need to be very cognizant of the SLAs with vulnerability fixes, particularly with individual contributor maintained projects. It’s crucial to manage expectations if you are using open source libraries in your projects. In order to ensure that these vulnerabilities don’t impact your business and projects adversely, you need to take extra efforts with tracking open source security metrics in the libraries you consume. 

Organizations should make it a practice to track metrics such as:

• days to remediation

• mean time to merging a pull request once an issue is opened

• time to fix the code yourself

This will provide you with a better understanding and reality check regarding the security posture of the packages you are leveraging.  In addition, if these metrics don’t meet your expectations, you should also be asking yourself questions such as:

• Are your developers helping package maintainers address issues by submitting pull requests?

• What percentage of packages are you actually doing this with?

• Is there a business case for helping to better maintain open source projects?

Final Thoughts

When reviewing this year’s data, it’s apparent that security within the open source ecosystem is improving, with a lot of positive changes in terms of awareness and remediation.

While the key statistics show that there is still work to be done—particularly when developers are becoming much more reliant on cloud native technologies such as containers and Kubernetes—it’s clear that strides being taken from a culture, process, package maintenance, and even developer tooling perspective are helping to move the needle on improving overall security posture and maturity within the open source security ecosystem.

To learn more and read the full report download the report here.

About this report

To better understand the open source security landscape, and what we can all do to make it better, we gathered information from a number of public and private data sources including the following:

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

• internal data from the Snyk vulnerability database, as well as hundreds of thousands of projects monitored and protected by Snyk.

• data about open source packages across the three most popular repositories: GitHub, GitLab, and BitBucket.

You can also download the report from the previous year - State of Open Source Security 2019

FAQ

Why is open source security important?

Open source is powering the digital transformation we are witnessing today and is used by companies of all sizes, in all industry verticals. Yet it also comes with risks. Acknowledging these risks is an important first step, but should be followed up with investment and maintenance of a well-articulated Open Source Security plan that includes continuous security testing and monitoring.

What is the risk of open source?

Developers are pulling in vast amounts of open source dependencies without any security control or visibility.