The State of Open Source Security 2020
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. The report leverages data collected from over 500 respondents to our annual survey, Snyk’s vulnerability database, aggregated data from scans against hundreds of thousands of projects, and data about open source packages across the three most popular repositories: GitHub, GitLab, and BitBucket.
A number of key trends emerged as we analyzed the data for this year’s open source security report. The most significant findings include:
- improved security mindset and culture within organizations
- reduction in the number of new vulnerabilities across the most popular ecosystems
- the most-reported vulnerability types do not correlate to the highest impact on software projects
- using official images for containers is not a replacement for regular security hygiene
- 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 from this year’s report is seeing a real, tangible shift in attitude regarding who is responsible for security practices within the organization.
Last year, when asked the same question ‘who is responsible for the security of the applications within the organization?’, more than 80% stated that developers carry that responsibility, yet less than 30% felt security or operations teams also had a role to play. However, this year the responses showed more focus on shared responsibility with 85% saying developers, alongside 55% and 35% for operations.
Given the somewhat surprising results related to open source software security in last year’s report, we decided to look at the attitudes around infrastructure security this year as well. While taking into consideration that not all respondents may be doing DevSecOps at all, or may even be using emerging technologies such as containers and cloud native technologies, 64% of respondents indicated developers have a role to play, while 56% indicated security has a role and 56% also indicated operations needs to play a part in securing the environment. This is an increasingly promising distribution of security responsibility across disciplines.
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.
These improvements are encouraging signs for the future. They seemingly indicate that increasing awareness and participation in the security of software being delivered. However, there is still room to see this shared responsibility become a more pervasive attitude and practices for achieving this shared responsibility more widely applied.
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.
Test your applications for known vulnerabilities
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.
For a second year, we analyzed the security of the ten most popular official container images. What we found were results that were 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, while 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?
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