31% don’t track application dependencies and 38% only track direct dependencies

Written by:

January 28, 2020

0 mins read

We recently conducted a study on the adoption of DevOps and DevSecOps. In this article, we review the state of organizational readiness for DevSecOps adoption, how DevOps maturity impacts security integration, and we go over the lessons learned on security posture of the teams that embraced DevOps

Download PDF DevSecOps Insights 2020

Organizational readiness for DevSecOps adoption

As we look into the way engineers audit their code bases, we see a strong adoption of automated security tooling, according to the Snyk State of Open Source Security report 2019, with 65% of respondents confirming that observation. It is also important to point out that, even when automated security tools are employed, 79% of the respondents still use security code reviews.

As teams embrace automated security tooling they also recognize that the negative impact the embedment of the tooling in a CI pipeline has on build time, worsens the experience and feedback loop for developers.

We found that 57% of respondents test for known security vulnerabilities in their open source dependencies while a significantly lower percentage perform static application security testing (SAST).

This is often the result of the latter involving high runtimes for this kind of security testing and also the fact that it results in a high percentage of false positives which then require manual review.

While a little over half of the respondents confirmed they test for known vulnerabilities in their application's open source dependencies, only 14% perform a similar test in container images during a continuous integration pipeline. Is it possible that respondents aren't aware of the security tooling available to them that mitigates this gap? Another option is that with most security tooling, you only get a report of which vulnerabilities exist in the container image, but fixing the actual problem, is entirely up to you.

As a source of comparison, Snyk Container provides actionable advice in the form of alternative container images that when used, they reduce the number of vulnerabilities, and minimize the overall security exposure.

Switching a base image for a docker container is an easily executed action that results in a high return on investment for security. In fact, based on scans performed by Snyk users, the Snyk State of Open Source Security report shows that 44% of docker image scans had known security vulnerabilities for which there were newer and more secure base images available.

Container security expands to more thanjust Docker container images. It impacts Kuberentes with real security issues in the form of vulnerabilities found in Helm charts. The Snyk 2019 report Uncharted territories: the untold tale of Helm Chart security, revealed several risks in this area:

68% of stable Helm Charts contain an image with a high severity vulnerability.
Updating to the latest published images, reduces the number of vulnerabilities for 64% of the stable Helm Charts.
6 images (out of a total of 416) account for half of the vulnerability instances.

When security is the application itself, or its vehicle — for example, container images used to deploy the application — then we found that developers play a key role in owning the responsibility of security for their application. How does this differ when we discuss the responsibility for the security of the infrastructure? Surprisingly, all the parties contributing in a DevSecOps environment, are almost evenly accountable for the responsibility of the infrastructure security.

Check out our new Open Source Security Report 2020. This report reflects on open source security concerns in 2020, trends in vulnerabilities across packages and container images.

Continue reading our DevSecOps Insights 2020 study:

Download PDF DevSecOps Insights 2020