CI/CD / Culture / DevOps / Sponsored / Contributed

‘DevSecOps Insights 2020’: Who Really Owns Security in DevOps

6 Mar 2020 6:00am, by

Snyk sponsored this post.

Liran Tal
Liran is a developer advocate at Snyk and a member of the Node.js Security working group. Liran is also the author of Essential Node.js Security, a core contributor to OWASP NodeGoat project and loves to dabble about code, testing and software philosophy. Sign up for free at Snyk.io to find and fix vulnerabilities in open source libraries and containers.

DevOps is a fast-moving space, but sometimes in the race to the finish, there are steps that can be overlooked — security could well be one such step.

In Snyk’s DevSecOps Insights 2020 report, we identified a few areas where there might be security missteps. It’s become almost a cliche saying “security is everyone’s business,” but the reality on the ground is often somewhat more nuanced.

One of the big topics that we looked at is the issue of responsibility. Typically, you might assume security professionals are responsible for security; but that’s not what we found. In fact, in the report, 48% of respondents still feel that security is a major constraint on the ability to deliver software quickly, according to data we incorporated into the report from Puppet.

When that many respondents agree security is a major concern when trying to deliver software quickly, it means we need to scale up security to enable fast delivery of security fixes. The key to doing that is developers, as they ultimately fix security issues in an application’s source code. This also aligns with our survey that found 81% of respondents noted that they think developers should be responsible for the security of their own code.

Application code security isn’t the only question our survey addressed, as applications generally still need some kind of service or infrastructure to run on. When asked who they think should own the security of infrastructure, 61% responded that it’s the responsibility of the security team.

Looking beyond just who should be responsible, we also looked at what application security approaches organizations are taking as part of their DevOps pipelines.

What’s Being Tested

Developers today are using a combination of different approaches to audit code. We found that developers conduct both manual review (79%) as well as make use of automated security testing tools (65%).

When testing, 57% noted that they test known vulnerabilities in open source code dependencies. While that’s a majority of respondents, it’s still not a great number and implies that 43% don’t scan for those issues, which could be putting their organizations at grave risk.

Adding further insult to injury, only 14% of respondents reported that they test for known vulnerabilities in container images. The lack of scanning in container images is something that is a real concern. The
“Snyk State of Open Source Security Report 2019” revealed 44% of Docker images that survey respondent organizations had scanned had known security vulnerabilities for which there were newer, more secure base images available.

The Snyk 2019 report “Uncharted territories: The untold tale of Helm Chart security” also provides additional clarity on the risks of not scanning container images. In that report, we found that 68% of stable Helm Charts contain a container image with a high severity vulnerability.

Why DevSecOps Matters

With DevOps, automation is a primary component of the process throughout the continuous integration (CI)/continuous deployment (CD) pipeline.

The concept of DevSecOps is about integrating security into DevOps, but our research found that this doesn’t happen as often as it should. Unfortunately, 38% of respondents indicated that they don’t integrate automated security scanning into their DevOps pipeline.

Organizations that lack an integrated approach to security find their ability to deliver software quickly hampered. The “2019 Puppet State of DevOps” report found that 48% of surveyed developers reported that security is a major constraint that slows their ability to release software.

That constraint could generate friction between security and deployment teams when they need to collaborate, across all levels of DevOps maturity, according to the Puppet study.

So what should be done? We have a few ideas:

  1. Embrace security integration. When teams are siloed with their activities and overall goals unaligned, they create tension and friction that manifests in security missteps.
  2. Security as a shared responsibility. Having a sense of shared responsibility across the organization contributes to a security-first mindset.
  3. Executing well on DevOps is key to DevSecOps. When organizations exhibit a strong level of DevOps tooling and culture adoption, they are well-positioned to further enable security practices and DevSecOps.

At the end of the day, it’s important that security isn’t an afterthought or something that’s bolted on at the end of the process. For security and DevSecOps to work, it needs to be an automated and integrated part of the process.

Feature image via Pixabay.

A newsletter digest of the week’s most important stories & analyses.

View / Add Comments

Please stay on topic and be respectful of others. Review our Terms of Use.