Misconfigurations, known unpatched vulnerabilities, and Cloud Native Application Security

Two weeks back, we published our annual State of Cloud Native Application Security report. If you haven’t seen it yet, here’s a TL;DR. We surveyed nearly 600 developers and security professionals to see how the shift to cloud native (digital transformation) has changed their security posture. Then we parsed the results, gleaned valuable insights, and put them in an interactive webpage.

We were able to get a lot of great takeaways from the results, and here are some that I think tie together quite well:

1. Almost all respondents agreed that as cloud native adoption increases, security needs to be built in standard.

2. Respondents with highly automated pipelines were twice as likely to incorporate security testing throughout the development lifecycle.

3. Developers see themselves as an integral part of security.

These items show a clear path to DevSecOps, with the success of security hinging on developer involvement and process automation. Unfortunately, an indicator that many organizations aren’t quite there yet is a postscript to #1: Even with the agreement that security needs to be standard, over half of respondents suffered from a misconfiguration or known unpatched vulnerabilities in their cloud native applications.

To break that down further, the top two incident types — by a distance — were misconfigurations (45%) and known unpatched vulnerabilities (38%). Combining the two, 56% of respondents experienced a misconfiguration or known unpatched vulnerability incident involving their cloud native applications. That number is even higher, though, as 18% of respondents didn’t answer that question due to its sensitive nature. When we adjust for the 82% response rate to that question, 69% had a misconfiguration or known unpatched vulnerability in their cloud native applications.

Based on these significant findings, it appears that while developers are doing more (Sec and Ops), they aren’t able to properly manage increasingly infrastructure-based responsibilities. This isn’t to say that developers are incapable, just that workload has increased and expertise requirements have broadened, and it’s time to reevaluate this new cloud native developer landscape.

"With misconfigurations and known vulnerabilities being the top concern and incident driver, we need to rethink how dev teams should prioritize security work. When a developer is responsible for securing the full cloud native app, it’s often more important they tackle these security hygiene concerns than the vulnerabilities in the app’s custom code which most security programs start with."

Couldn’t have said it better myself, Guy. Fortunately, both of these problems can be resolved by implementing developer-first security tools that can, 1) identify security vulnerabilities holistically through all parts of the development lifecycle, and 2) provide context and prioritization for the vulnerabilities.

Vulnerabilities can’t live in siloes, and more than that, they can’t be prioritized based on their silo. Misconfigurations in infrastructure can leave an application wide open for attack even if the application code is well-secured. Developers need tools that can find all vulnerabilities and misconfigurations throughout code, dependencies, containers, and infrastructure, and then provide them with a full-scope, prioritized list.

Prioritization means taking a look at the severity of the vulnerability, the maturity of any attacks, and the visibility to attackers. If a vulnerability is potentially severe, but it’s only accessible if attackers get through multiple other layers of security, lower the priority. If 100 vulnerabilities can be fixed by a single based image update, raise the priority. There is no way a developer can fix every vulnerability, so they need to be able to know what to focus on.

Security tools need to be able to provide this sort of full context because we can’t expect every developer to be a security expert — it’s just not a reasonable expectation. Instead, developer-first security tools need to act as a trusted security expert that sits in every developer’s toolbox. The barriers to security need to be lowered as much as possible to keep cloud applications and infrastructure safe.

Anyway, that’s going down the rabbit hole of just one item covered in the State of Cloud Native Application Security report. If you’re cloud native already, or just thinking about making the shift, I’d highly encourage you to check out the report. You can also listen to Guy and I break the report down on a recent episode of the podcast The Secure Developer. If you read the report (or listen to the podcast) and decide you’d like to contextualize and prioritize your Cloud Native Application Security, sign up for Snyk for free.