81% believe developers should own security, but they aren’t well-equipped

Liran TalFebruary 26, 2019

Welcome to Snyk’s annual State of Open Source Security report 2019.
This report is split into several posts:

Maven Central packages double; a quarter of a million new packages indexed in npm
88% increase in application library vulnerabilities over two years
81% believe developers should own security, but they aren’t well-equipped
Open source maintainers want to be secure, but 70% lack skills
Top ten most popular docker images each contain at least 30 vulnerabilities
ReDoS vulnerabilities in npm spikes by 143% and XSS continues to grow
78% of vulnerabilities are found in indirect dependencies, making remediation complex

Or download our lovely handcrafted pdf report which contains all of this information and more in one place.

DOWNLOAD THE STATE OF OPEN SOURCE SECURITY REPORT 2019!

Open source security ownership

We set out to find who in practice owns the security responsibility of an application or library today, as well as who users think should take ownership for security.

According to 81% of respondents, developers should own the security of their application code, sending a strong statement about the involvement and engagement level that is expected from developers, and supports the strong DevSecOps movement which many are adopting today.

Who is responsible for security?

A healthy approach to embracing security as part of the SDLC is to integrate it within the entire development lifecycle, from design to production. This significantly differs from the more traditional one-off phase of security testing that occurs periodically and doesn’t fit the modern, fast-paced software delivery model. However, processes and guidelines may not be enough. Education, friendly tooling, and engagement with R&D teams and stakeholders are just as important to the healthy adoption of security practices within an organization.

Discovering vulnerabilities

It takes a great deal of knowledge, experience, and a sharp eye to properly code review for potential security vulnerabilities within one’s own code. As this isn’t a straightforward task, if carried out at all, it suggests that vulnerable code may stay dormant for a long time until it is picked up by anyone.

37% of users don’t implement any sort of security testing during CI

Teams that practice DevOps or have a mature CI/ CD pipeline may find it easier to introduce security testing as part of their build automation, yet we find that almost 40% of users don’t implement any sort of security testing during their CI runs. A reassuring note however is that more than half of them are at the very least testing for vulnerabilities in their open source dependencies.

Another finding in our research is that teams that build security into their work also do better at continuous delivery. A key element of this is ensuring that information security teams make pre-approved, easy-to-consume libraries, packages, toolchains, and processes available for developers and IT operations to use in their work. — Nicole Forsgren, Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations

Security testing during CI

Finding out about vulnerabilities

From the user’s perspective, it is interesting to gain insights into how they learn about vulnerabilities in their application dependencies in order to respond to potential threats as they are discovered.

A worrying 27% of respondents stated they do not have any proactive or automatic way to find out about newly discovered vulnerabilities in their applications. Only 36% of users confirmed that they use a dependency management or scanning tool to help surface vulnerabilities.

How do developers find out about vulnerabilities

Snyk stats

In the second half of 2018 alone, Snyk opened more than 70,000 Pull Requests for its users across Maven, RubyGems and npm ecosystems to remediate vulnerabilities in their projects.
Out of all the dependencies in a scanned Java project, Snyk provided a remediation path to fix vulnerabilities that were found in 60% of them. It’s not always possible to fix remediation
paths when there is no compatibility between a direct dependency and a fixed version of an indirect dependency. The Snyk Security team can provide custom patches to fix some of these situations.

Time to adopt security fixes

How long does it take users to adopt new releases that provide security fixes to known vulnerabilities? We turned to Python’s PyPI registry and its websockets package for an example to see how popular vulnerable releases continued to be used even after a vulnerability fix was released.

The websockets project is a fairly popular and well-maintained package, dating back to 2013 and showcasing regular releases to the present day.

In August 2018 a denial of service vulnerability was disclosed to the community, affecting versions 4.0 and 4.0.1 of the package. At the time of disclosure, newer versions already existed on the registry that provided the security fix, however looking at the download counts for the vulnerable versions, a long trail of users still fetch vulnerable versions of websockets can be seen.

By December 2018 we’re still tracking 11k downloads of the websockets package that contain the vulnerability, even though there is a fixed version available as a major upgrade with websockets version 5.0.

Downloads of the vulnerable PyPI websockets package in 2018