The State Of Cloud Native Application Security With Simon Maple

[00:00:15] ANNOUNCER: Hi. You’re listening to The Secure Developer. It’s part of the DevSecCon community, a platform for developers, operators, and security people to share their views and practices on DevSecOps, dev and sec collaboration, cloud security and more. Check out devseccon.com to join the community and find other great resources.

This podcast is sponsored by Snyk. Snyk is a dev-first security company, helping companies fix vulnerabilities in their open source components and containers, without slowing down development. To learn more, visit snyk.io, S-N-Y-K.io.

Welcome back to The Secure Developer. On today's episode, Guy Podjarny, President and Co-Founder of Snyk is joined by colleague Simon Maple, Field CTO. They discuss the findings from Snyk’s recent report, The 2021 State of Cloud Native Application Security, covering how cloud native adoption has changed the way organizations defend against security threats, including the most common types of security incidents and concerns teams have, as well as how developers are not only taking on more security responsibility but embracing this new ownership. We hope you enjoy their conversation, and don't forget to leave us a review on iTunes if you enjoyed today's episode.

[INTERVIEW]

[00:01:35] Guy Podjarny: Hello, everybody. Welcome back to The Secure Developer. Today, we're going to have an episode that focuses more on data than opinions. To do that, we have Simon Maple, who is the Field CTO here at Snyk, and together with Matt Jarvis, who is a Senior Developer Advocate on the Snyk team, has published just now a report called The State of Cloud Native Application Security or The State of CNAS. In it, we surveyed a whole bunch of people. We're going to dig a lot more about how they see their application security and cloud native app sec state.

Simon, thanks for coming onto the show here to share your findings.

[00:02:13] Simon Maple: Yeah. It's an absolute pleasure. It's always nice to join The Secure Developer, so thanks for having me.

[00:02:17] Guy Podjarny: We get a chance for me to ask you questions this time around unlike the year end show.

[00:02:23] Simon Maple: I know. Or maybe at the next year end show I'll ask you questions about my answers from this session.

[00:02:28] Guy Podjarny: We will see. I don't know. It depends. We'll see how well you do and we’ll find out if that would be desirable or not. Uncover here, just for those who want to follow along and maybe look at the report itself as we discuss it, we created a bit of a short link for it. It is snyk.io/TSD-cloud-report, just as a link shortener for you to get to the report itself. We’ll remind you at the end of the episode as well.

With that, Simon, tell us a little bit about this report, like who did we survey in the first place? A little bit about the demographics.

[00:03:05] Simon Maple: I mean, historically, in the past, Snyk has done many of these state of security style reports. So we've done state of open source reports and so forth, state of – in fact we did one of them around Docker and containers last year as well. This year, we decided to broaden that slightly so that we covered various different aspects of the more modern application security platform, so really everything from the application security, all the way through to container security and infrastructure as code.

The types of the people that we actually surveyed, we set it just under 600 people between February through to April in 2021. We actually had a really nice wide range of respondents, which is really great that people are willing to spend that time. It's clearly something that is important to a much broader set of roles, rather than just the usual set.

So yeah, we're looking at about just under a quarter of people who are responding are software developers, we had around 16, 17% of security folks, around 15% architects, 12% DevOps folks, and then a mix of other roles in there, including management team leads, project management. So we had a really good mix throughout the company, so it's a nice broad, established set of results.

[00:04:14] Guy Podjarny: Yeah. That's excellent. I mean, 600 people as well is also a pretty sizable number. It's always impressive that indeed people are willing to invest their time and share this type of information. At the end of it, as a community, we will all benefit from having a bit of a picture of where we stand and where do we need to improve. Still one more step, we have these 600 folks from this wide variety. What's their tech stack like? What did we learn about? Are they cloud native? Are they not?

[00:04:43] Simon Maple: Yeah. We put a couple of questions in there about how much of their deployed production environment contains cloud native or cloud deployments. This was really interesting because in the past, you see some surveys that kind of ask whether people do use containers or serverless, and some people who just use one lambda or one service function will say, “Yes, I'm using serverless in my environment.” But the question we asked was really to what extent were people using serverless or containers or indeed deploying, using infrastructure as code in their environments.

So this gave us some really interesting information where we can see on average across all respondents, the 57, 58, just rounding up to 58% of people's production environments were deployed on containers. The mean average for serverless is 21%, so really strong maturity being shown here in production environments.

We can really say that companies, big and small as well, it wasn't limited to what you would expect, maybe more startups and medium and small companies to adopt quickly, enterprises as well really pushing on the cloud native deployment.

[00:05:54] Guy Podjarny: Yeah. I mean, that's awesome. I think, I know in the report we talked a little bit about sort of enterprises versus medium-sized organizations, small organizations. But it seems like this stat was fairly consistent across the different profiles.

[00:06:07] Simon Maple: Absolutely. I think that's a really strong sign of maturity. Two things really, I mean, what you would normally see, and this is kind of like my opinion rather than the data showing this, but what I've seen is when you see newer technologies, and we’re not saying containers is that new these days. But when you see newer technologies being introduced into the industry, you will see very early adopters take that on. Yes, you will see some enterprises trialing these kinds of things, but it's really some of the smaller companies that are much more agile, much quicker to adapt who will rely more on these kinds of technologies.

It's good to see that, but what I really enjoyed is the fact that we're not just asking if people are using these technologies. It's what percentage of their deployments, and to see enterprises and medium companies so high in that usage in the deployment of production environments is really important to show this is a mature deployment now in our industry, so it's a key step for me in showing how mature cloud native and cloud technologies are in our industry.

[00:07:06] Guy Podjarny: Yeah. No, absolutely. I think it's really insightful. I think we probably need to acknowledge that the folks that are very far along the container and cloud native adoption curve probably didn't participate in the survey, the ones that they might not be people that found out about sort of Snyk initiated a survey. But still even within the base that have responded to it, the fact that we're pretty much getting the same numbers around containers and serverless and infrastructure as code adoption across organization size I think is a telltale sign. It’s not the reality that we've seen last year. I think it's a pretty big leap.

[00:07:43] Simon Maple: One of the other questions that we did ask was why people are moving into containers because I think this is a really interesting stat. A lot of the responses that came back were very focused on deployment velocity and ease of management. So the decisions, as you would expect, is really all about that kind of like maintenance and being able to deploy fast.

Interestingly, security was, around a third of people said one of the main reasons of moving into containers was improved security, which is really interesting. Moving into cloud native and containers can, of course, introduce some more security, different types of issues, but it can also fix a number of others. So it's good to see that security is actually, for a third of people, one of the main reasons why they moved into cloud native technologies.

[00:08:31] Guy Podjarny: Yeah. That is – Containers offer a certain amount of agility that does benefit security a fair bit, but that's not really their primary claim to fame when it comes to security. Definitely, it tends to go the other way around. So I guess this establishes a little bit, size of the demographic, who we spoke to, what their sort of cloud native adoption state is. Let's dig a bit into what we learned about security. What's on people's minds when it comes to security concerns? What bubbled to the top?

[00:09:01] Simon Maple: When we asked people, first of all, “How important is security to your cloud native strategy?” Overwhelming response was that it was important to people. 99% of respondents came back saying it was important, and I think it was 83% said it is very important to their cloud native strategy. So whether or not people are moving to the cloud native environments because of security, it is clearly an important factor into their deployments.

Going into their concerns as to the areas of why it's important on where they need to focus, we had a good spread of concerns. We asked about incidents and concerns. If we focus on concerns first, we had a good spread, but it’s interestingly not necessarily the more complex, the higher level attacks that people are most concerned about or, in fact, where most incidents come from. It is more around the security, the general security hygiene of applications and deployments. The two top vulnerability types or security issue types were misconfigurations and known vulnerabilities. These were two of the key areas that people found most incidents, actual incidents, security incidents that they had to deal with. Over half of respondents suffered from either a misconfiguration or known vulnerability incidents, which is so significant.

Of these, the survey data showed that misconfigurations were, by a significant way, the biggest area of increased concern. So we asked questions about where your concern increased, where it decreased, and it was very significant that people were much more concerned. We split this data a little bit as well, whereby based on how much of people's production environments, as we discussed before, people were using cloud native technologies, either containers or serverless, we took the upper quartile of that and a lower quartile of that to see who were the high adopters of cloud native technologies and who were the low adopters.

The high adopters were much more significantly concerned about misconfiguration, but it wasn't necessarily something that was too different. People who were still adopting, misconfiguration is still a concern for them and an increased concern, going from a more traditional pre-cloud environment to a cloud environment. That was a key aspect.

[00:11:15] Guy Podjarny: Yeah, so interesting. We're sort of saying misconfiguration of our infrastructure is a concern. I guess it’s always been the concern, sort of the picture of the wrong port being open on the firewall or something of that nature. The concern around this, around having misconfigurations in your own environment has increased, whether you are a high adopter or a low adopter of cloud native. I guess this might be like all the headlines. As cloud comes along, every other day, you see some S3 bucket that remained open or some CapitalOne style breach.

[00:11:50] Simon Maple: Absolutely, yeah. I mean, we see in the news all the time misconfigured IAM roles, misconfigured S3 buckets. I think there's a number of reasons behind why these things happen. I think, first of all, it's easy and quick to create these configurations. It's really, our technology has enabled us to be able to spawn up these configurations very, very quickly. However, misconfigurations are as much of what we don't add into our config as what we do. Very often, whether it's adding something into a security context, as simple as adding a user directive into a Dockerfile. But by not doing these, we will add these misconfigurations in.

I think it's also the switch of responsibility in terms of who are touching these different artifacts. A lot of what we're seeing here with Terraform scripts, Kubernetes, config with Dockerfiles, this is moving across to developers more and more, and we see developers touching these kind of artifacts, these kind of conflicts. Unless we get the education right and unless we get that security awareness, that security knowledge right, just getting something working and getting something out there isn't good enough. We need to make sure that all the holes are plugged, that we have good visibility into what is a misconfiguration. I feel we are accelerating much faster on our ability to make these updates and make these changes than we are our security visibility and security knowledge into these.

I feel that that is one of the biggest areas which causes concern. When we think about the concerns, they’re, first of all, right areas to be concerned because we see the actual incidents with misconfigurations is the highest style of incident across cloud native applications. So people are right to be concerned about them. As you say, yeah, these are the kinds of misconfigurations and incidents that cause headlines. Companies, different industries, they’re right to be concerned because they don't want to be the next person there making the headline.

[00:13:41] Guy Podjarny: Yeah. I think that correlation between incidents and concerns is really interesting. So we asked them about which incidents, and you're saying misconfiguration I guess the top one, top two in both the concerns and the incidents that people have experienced. What's number two then, misconfiguration? Is there – What’s the other one that top the incidents list of actually being breached?

[00:14:05] Simon Maple: Yeah. Incidents, that's a fair gap actually. So we have, yeah, misconfiguration at 45%. We have known unpatched vulnerabilities sitting there at 38% of people having incidents. Then we jump to 20%. So there's a significant gap between those two. And secret leaks, which is, again, another area which we see concern. Other questions about why these secret leaks may occur. We also have data leaks by insider. This is an interesting one, people who have high adoption of cloud native technologies, we see around a 2-2.5 times increase on the number of incidents by data leaks by insider. Again, this could be back to what I was talking about previously with different people doing different things in their roles now, doing things they didn't used to do 15, 20 years ago. It’s easy to get it working by making these, adding this conflict and adding this into code but harder to maintain and harder to keep secure.

[00:15:02] Guy Podjarny: Yeah. Overall, I would say a positive statement that people are concerned about the things that they are actually experiencing. It would have been more of a problem if we had a bad correlation between what people have, kind of at the top of their minds, versus those others. But the fact that misconfigurations and kind of unpatched systems, both kind of top the charts in both actual incidents they've experienced, and their concerns is a positive thing.

We often don't talk about the benefits of empowerment, and I think the data actually shows this as well. It shows how, in the sort of high adoptions of cloud natives, you see teams not being as concerned about the quick of being able to roll out a fix or to respond to a risk. They rely on their agility. They're more positive about it. They're not worried about not being able to move fast.

But as you point out, people are handling secrets or handling data that they might not be used to. It’s also just less centralized and kind of more distributed because of the empowerment. As a result of that, they're more worried about data leaks and secret leaks, which I guess also makes sense, right? It's nice to see sometimes when the data aligns with the logic, as you might say.

Okay, so these are some security concerns. I guess kind of a little bit more as a meta, as an overarching sentiment, as people adopt cloud and kind of cloud native, are they generally kind of more reassured of security or are they more concerned about security? What did we see?

[00:16:29] Simon Maple: One of the questions we asked is whether people have an increased concern over security in general when they adopt cloud native or whether it's decreased or whether it hasn't changed. This is significant as well. Organizations are nearly four times more likely to have an increased rather than a decreased concern over their security posture. I don't think necessarily this is because the technology itself has huge holes or anything like that. It's all about how it’s implemented and it’s all about how it's used. This shift, technology is easy to move from one to the next, okay? It's just an implementation detail. I’ve generalized that very, very and simplified that very, very much.

But in comparison to people moving technologies and people learning, it's a big job for any workforce to be able to say, “We're going to entirely move across to a container stack. Not just to learn containers but to shift the way the organization works.” This is a key concept in the idea of digital transformation; it's the company and the organization that needs to change, much more than the tech.

Yeah. I think a lot of the concern isn't necessarily about the tech but about how the organization deals with that tech, whether that organization is set up, both in the way their teams are configured and organized, as well as the way that their processes and the way that their mindset is set up to deal with these new issues that can appear. So a much, much stronger leaning on the increased concerns, rather than decreased. 20% say it hasn't changed and around 7% don't know, haven't noticed any concern.

[00:18:11] Guy Podjarny: I guess that makes sense as well because cloud native is – At the end of the day, it's a change, right? So you're kind of, there's more unknown, you fear the unknown, so your concerns about security and how you'll handle it, as you point out. Are you going to be equipped with it or not? Decreasing it, I guess, is when you go to something that is more rigid, that is more locked down. But going to cloud native is not going locked down. It's going agile. It's going flexible. It's going distributed. I mean, I think it's a reasonable response, and it’s interesting to kind of relate it to that third that actually moved to the cloud for security reasons or at least with security as a motivator.

Let's maybe shift gears a bit from the problem to the solution. All of those are concerns or the incidents that people have experienced, where they're going to invest. What have we sort of learned in terms of ways in which people try to tackle these concerns and these risks, you know, get better at protecting themselves?

[00:19:07] Simon Maple: We asked a number of questions around this, and one of the key areas which really showed a strong correlation, not just with cloud native adoption but also with many of the aspects which we would like to see, like how fast people can fix critical vulnerabilities, how much people can test, how often people can test. It all centered around automation and deployment automation. This is key to the success of a really strong cloud native adoption and program that you can securely test in a pipeline.

Of everyone who responded, 95% of those use automation to some extent. Interestingly, only 33% fully automate the deployment pipeline, which I guess now comes down a little bit to what people believe fully automated is, a pipeline, an automation, a deployment pipeline that is very low touch or touch-free from a developer pushing code. This will very much depend on what automated testing and checks exist through that pipeline.

But we saw some really, really strong value that can come for that. Some examples of that include, first of all, when people test, and this is something that you would, in a fully automated deployment pipeline, expect that that would exist more in areas of that pipeline. For example, CICD and other areas like that. Absolutely, yeah, people who were entirely automated, 73% of them had security testing within their CI system, as you would expect, whereas people who were not automated only 28% had that in their CI environment.

However, when we look at areas that don't necessarily need to be automated or, in fact, it's extremely hard to automate, so local development, for example, IDEs, CLI, a developer effectively running tooling on the CLI, for example. This was very interesting to me, we saw almost twice as many people who were entirely automated also tested in local development tooling.

This is a place that is very hard to police, very hard to force because you don't have that automation locally on the developer’s machine necessarily. So it's really strong to be able to correlate the fact that as people entirely automate their pipeline, people get more and more used to security testing in general, and are more likely to actually test earlier. I would like to think that that would actually be because wherever you test in your pipeline, it's going to get back to the developer essentially anyway. So it's in the developer’s interest to make life easier for themselves to test and make sure that the fixes that need to go in, go in before their code enters the pipeline.

So it's a really strong correlation between full automation or strong automation, and developers taking it upon themselves to run security testing locally. Equally, in source code repositories, almost three times as likely to test for security in your source code repository if you're fully automated versus not automated, so really strong correlations that we're seeing there.

[00:22:19] Guy Podjarny: I think that's a really interesting observation of people who are at the core, right. There's probably a little bit of a correlation versus causation thing here, right? You can sort of hypothesize on one hand that teams that are most mindful have invested in fully automating their pipeline and putting security, and there's probably some of that. Then there's probably some of the opposite, which is, once you institute more security automation in your pipeline, people know that problems will arise. They will be found in the pipeline. They've kind of experienced this once or twice. They're now kind of more conditioned, more inclined to actually not get to that place, but rather run the test locally as well and avoid the problem in the first place versus putting something in, breaking the build, getting more disruptive, and still needing to come back and do it. Versus ones that think, well, if they missed it. It’s not even thinking, right? If they missed a problem, it disappears into the ether or they learn about it at best maybe a month or two later. You don't really get that conditioned behavior of that muscle memory of, “Hey, I should have tested it before I checked it in and it immediately broke.”

I'm curious, Simon. Have you seen differences between organization sizes here with regards to sort of pipeline automation or how much security testing is done?

[00:23:30] Simon Maple: I would actually say they're pretty similar. Of course, when we look at the different company sizes, we have to also think about what resources people have at that stage. We're not just talking here budget, but we're talking how much time people have to, in fact, add this automation as well. As you look at the larger companies, yes, you would expect companies and teams to have fully established security teams, potentially DevOps teams, people who are dedicated to running and pushing this kind of automation, whereas in the smaller teams, the startups, you'd expect, effectively, the developers, or indeed, as you know, Guy, the CEO to do a lot of that work as well. [inaudible 00:24:07].

[00:24:08] Guy Podjarny: When we’re smaller now, that’s what had to be done.

[00:24:10] Simon Maple: Absolutely. At that stage, when you're a small startup company. Not, of course, now, I mean, Guy, when was the last time you touched some code, Guy?

[00:24:18] Guy Podjarny: Yeah. I don't know that I want to answer that. Not recently. Not recently.

[00:24:22] Simon Maple: What's great to see is in the teams that you would expect them to have the time and the dedicated people, people who are hired for this role, you'd expect them in the medium and enterprise companies to be able to adopt that automation style environment. As you would expect, as well, small startups companies, they're more agile, it's in their nature to equally save their time because they want to be making sure that they're doing the feature work and the automation actually, while it takes a little bit of time upfront, it will save time in the long run, and it allows them to be much more agile in their deployments and quicker to release to market. So it's great to see the enterprises, as well as the startups and the medium companies moving to that automation model.

[00:25:07] Guy Podjarny: I oftentimes sort of use this analogy of how much you care versus how hard it is. For anything in life, there's how much you care to do it versus how hard it is. When we talk about incentivizing people to do something, you either work on things that help them care more or you work on simplifying it, making it easy for them to do it. It’s interesting whether that's the force in play here.

As a small company, you're less resourced, and so that's maybe a little bit hard. You might also not be as mindful of it. Maybe you don't think about yourself as a target as much. You're not maybe trying to address various compliance. You might not care as much. But when you do apply it, it's probably a little bit easier from a technical implementation because it's just fewer moving parts. In the enterprise, you care more and you maybe resource more. It might be more complex. But at the end of the day, those  forces even that out, so it's interesting to see that.

[00:25:59] Simon Maple: Absolutely. One other takeaway that I can see here from the data where we look at the different sizes of companies versus when people test in their pipelines, we can see that the enterprises and the larger organizations are more likely to have a broader distribution of where they test. So they have a stronger representation in production, compared to a smaller organization.

The smaller organizations will much more heavily rely upon earlier testing, quicker feedback loops, testing in source code repositories and in their local development environment. So there is a stronger push from the more agile, I would say, smaller companies in leaning into that shift left earlier in security testing.

[00:26:47] Guy Podjarny: Testing is all good and well. At the end of the day, once we’ve found an issue or want to fix it, what have we seen about how well people handle actually doing something about the vulnerabilities they find?

[00:26:57] Simon Maple: Yeah, absolutely. There's two pieces there in terms of how fast you can find and then, secondly, how fast can you fix the critical thing, right? It’s easy to find things fast. But if you're doing nothing with it, it doesn't matter whether you find it within a day or a month. You need to be able to act upon that and actually make an impact. So let's start with almost like more of the auditing, how frequently people test.

There are some really significant, as you would expect, differences between not automated and entirely automated organizations. People who are entirely automated will test continuously or daily, and I guess this really depends on how many times people will go through their automated pipeline. But almost 70% of people who are fully automated will test continuously or daily. In comparison to people who are not automated, that drops massively down, 17 times in fact, down to around 4%. So only 4% of organizations and respondents that are not automated will test continuously or daily.

On the flip side, 60% of people who are not automated will test monthly or less frequently. So even the finding of the issues when you're in an automated pipeline is so much more valuable to actually raise those and get that visibility into your application and into your environment. That, for me, was a really core metric about the importance of that visibility in an automated system. I feel like that was one of the keys.

[00:28:22] Guy Podjarny: Yeah, absolutely. Sort of DevOps and automation. I guess that, again, comes back to that third of respondents who talked about moving to kind of cloud native and embracing it for the purpose of security. It's really around that more automation, more automated pipeline offer an opportunity to now embed security controls into those pipelines now that they're established. If they're not established, it's a much heavier lift to create some form of automated security tests without security delivery pipeline in the first place.

[00:28:50] Simon Maple: Absolutely, yeah. Also, automation is great for an education in terms of, if you don't have automation and you rely on developers and other teams to do this much more manually, things will get missed. You have far lower confidence in the reliability, the stability, the repeatability of something going through a pipeline. That automation will run the same as it will every single time you push something through. So that confidence you can have is far stronger, indeed, as well.

The second piece really is about the fixing, which is the core to this issue. How fast, once we know we have a critical security issue, can we fix? This is, again, overwhelming in terms of the results that we saw with over 72% of respondents that had high levels of automation, had an average time to fix critical vulnerabilities of less than one week and just over a third, 36%, having an average of one day or less to fix a critical vulnerability. When we compare that to people who are not automated, we see less than a third can fix a critical vulnerability within a week, and only 8% can fix a critical vulnerability in a single day or less.

I think there's a couple of reasons for this. By the way, this isn't necessarily from when a critical vulnerability appears or is known publicly in a package you use. This is from when the organization knows about it. From the time you're aware of your critical security issue, how fast from then can you fix it?

As we talked about previously with when you're automated, you have that confidence, you can push out to production quicker, faster, these are the folks who are typically pushing daily, they are much more agile and much more reactive to be able to update the production environments much, much faster. But also, as we saw previously, they are already using the tooling. The developers are already much more involved in that. Ttesting in their IDEs, testing in the CLIs much, much more frequently, much, much more consistently. So it feels like the understanding that the organization have of these kind of tools, the results, the testing locally, all of that will really help in the speed at which you can test and fix.

[00:31:06] Guy Podjarny: I love the kind of meta learning for the security industry, which is, I think when we talk about embracing the CICD and cloud and cloud native empowerment, it's scary from a security perspective because things move fast. You can have the approach with insecurity of saying the safest thing is to change nothing, right? It's just sort of [inaudible 00:31:24] from the Internet, right? Sort of don't – We got to like a steady state. Let's not rock the boat. This notion of moving to a fast paced, automated environment, where empowered teams can ship software and do it again and again and again is the reason we're afraid.

That very same tool is also the savior. By being able to ship fast and deliver fast, we can integrate a security test and find about problems faster. We can fix problems faster, and the data kind of backs that up. It's interesting, the sort of two sides of the same coin and appreciating the opportunities that embracing cloud native introduces are at least as strong, even from a security perspective, as the concerns that they introduce. It’s great to see the data from different facets kind of shows both the perspective, as well as the opportunity.

[00:32:17] Simon Maple: Absolutely. I think one other interesting stat that came out of this was the number of people that responded that they don't know how long it takes to fix a critical security issue. People who are automated, it was as low as 8%. Almost 28% of people who were not automated, didn't know how long it took to fix a critical issue. I think it's that visibility into what is expected, what can be done. That expectation of what happens when a security vulnerability comes in, it’s showing that general security hygiene across the teams that is much lower as well in these organizations.

[00:32:54] Guy Podjarny: Absolutely. You can't optimize what you can't measure, right? So you have to improve that. Let's kind of wrap up the report summary with people, right? We talked about concerns. We talked about organizations, how well they handle things. Who is it inside the organization that is taking ownership of these types of concerns? What have you learned here?

[00:33:15] Simon Maple: Yeah. This is always that fun question, right? I mean, when we think about anything from DevOps or DevSecOps, so much of the success, it's such a critical part to make sure that the organization is well set up to run with that kind of processes and practices. When we look at who owns security, again, we see a broad range of answers in terms of who the different personas, roles we’re saying should take that. But two that we pulled out specifically are responses from developers and responses from security.

This was very interesting because when we think generally, sometimes we hear a lot of people say, “Oh, developers don't want to take security. That’s not of interest to them.” But the data shows that if we just look at developers, developers will say that – Around 37% of responses from developers will state that developers should own the security of cloud native applications and the cloud native platform.

If you add that to DevOps and DevSecOps, which very often can reside in the engineering team, you look at that around 67, almost just over two-thirds of people would say it resides, the responsibility of security, application security would reside in the development and DevOps teams. That's a really strong ownership pool from the engineering teams and the development teams. There is not as much pushback as sometimes when you hear developers don't want to take much more. We’ve heard this from so many people. If you give developers a choice of, “Do you want to do the right thing or do you want to do this other thing?” developers will choose the right thing. Developers, it's in their nature to want to produce quality software and produce good software. Sometimes though, when the right thing isn't the easiest thing, that's when time challenges and different pressures can make us choose the other path.

So that in contrast to what people in security roles have said, 30% of people in security roles state that the IT security team should own the responsibility of cloud native apps. A further 23% of security people in security roles state that application security teams should own the security of the application. So over 50%, more one in two people in a security role state that it is a security team's job to own that responsibility. Less than 10% of security individuals state that it is the developer's responsibility. So the contrast there of developers thinking that they own over three times as much as security, shows that developers almost want to take this responsibility but it's more of the traditional view of security owning security that is holding up that transition more, so a very, very interesting split between the development opinion and the security opinion in this data.

[00:36:15] Guy Podjarny: Yeah, absolutely. We're seeing how, while sort of the cynical view in the security world is that developers don't care about security, they don't want to embrace security, this data suggests that developers want to take security, but security won't let go. People on the security side just didn't say like, “Look, there is someone there kind of waiting with open hands.” Looking, of course. They need to be supported, of course. Security teams continue to play a big role in making them successful, just like SREs and DevOps teams are critical for organizations to be able to successfully tackle the problem. But they're there. They think they should have more ownership over here. But security teams need to be kind of willing to let them and need to empower, so super, super interesting finding.

[00:37:03] Simon Maple: As time goes on, we will, of course, see this further shift and talking with Patrick Dubois about the maturity of DevOps and DevSecOps. One of the key aspects to that is around trust, and there are four areas of trust that need to be built up, and one of them is around care. When we think about what individuals in development organizations, so developers, what they care about, do they really care about security? Or are they really caring about pushing out their features and such?

When we look at one of the previous questions about whether individuals have increased or decreased concerns around security since moving to a cloud native environment, we actually see that developers, not only do they care, in fact 61% of developers have an increased concern around security moving to a cloud native environment. So not only do they care about the security challenges that exist in cloud native environments, that number was actually higher than the security organization. So I'm sure there could be a number of reasons around that.

Security was only slightly lower, I'll admit, on 57, but these are very similar numbers. It's great to see that not only do the developers want the responsibility, but they share that care. They share that passion about shipping secure code. I think that is one of, also the core areas that is required, is demanded really for the security team to more give responsibility, to give ownership, and to work closer with that development team to know that they genuinely care, and that they genuinely want to progress the security of their application. That's what will help the adoption and developers pulling more responsibility into that development process.

[00:38:48] Guy Podjarny: Absolutely. I think the report is full of great data. Again, if you want to check it out, it's on snyk.io/TSD-cloud-report. Simon, the report focuses on today. It’s aptly named State of Cloud Native App Sec. But I like to ask every guest on the show a little bit to think towards the future as well. So if you take out your crystal ball and you imagine when we run this same report, the same survey next year, what do you think would change the most? What would you anticipate?

[00:39:27] Simon Maple: Yes. That's a great question, and I think there are plenty of very obvious expectations that we would expect in a couple of years, Docker and container adoption to continue to increase. I think some of the stats that Gartner have recently released about what they expect in the years to come of container adoption, looks to be coming true from these kind of data points. I expect that to continue to grow as people in companies of all sizes adopt further.

A couple of things I would love to see, and I think will happen, is that people won't just adopt the technologies, but they'll adopt the correct practices that will require them to make best use of those technologies. We're talking about automated pipelines. We're talking about automated deployments. As a great part of having the confidence in those automated deployments, you need to make sure that security testing is at all parts of that pipeline. So I perceive the levels of automations increasing. That 30%, that third of people who are fully automated, I would expect that to grow in the next couple of years. As a result, that will – looking at the stats that show the amount of adoption in local development and IDEs - that as a catalyst will encourage developers to be more exposed, to be more visible to security practices, as well as processes and programs.

So I absolutely see more of that shift left and I would expect to see, in fact, companies and organizations doing more testing in their local environments and early in that process than they would in the later stages because it is so cheap and it is so valuable for companies to test and get early feedback. So I'd like to see that kind of a shift. It's not far away now. We're only 10, 15% away there now, so it only takes a little bit more to do that.

In terms of, with that automation, yes, we will absolutely see the speed at which people can react to be much, much faster. So it will be great to be able to see the speed of fixing critical vulnerabilities to be much, much closer to that one day. I would expect that one day or less to be much faster as fixing a critical security issue is just the same as fixing any other bugs. So security will be just another piece of that quality testing for a developer. It will be much more ingrained in the developer’s day to day life.

A couple of things that I would like to see before we jump on to people, the misconfigurations and the known security vulnerabilities. It's a really interesting one. That was very interesting to see, as one of the one of the big highlights of people are very concerned about it, and people are seeing more incidents. I think that misconfiguration in particular is a very hot topic right now in a very strong area that people are adopting quickly in IAC but need to make sure that that is done in a secure way. We're seeing the headlines. We're seeing companies look as to what they can do to fix these issues. So I think, I would expect this to actually come down in terms of being a concern and down in terms of – Well, maybe it will continue in the incidents as this is still growing. But I would like to see that actually come down and I'd like to – That may sound a bit weird, given that we're growing more and more into this space, but I think the security tooling and the abilities to test and understand where those misconfigurations are, I see that as such a core area of learning that that is something that will be dealt with in the next couple of years by organizations. They'll see that as a critical thing that they need to jump on and fix, and that will become less of a concern because more organizations are dealing with it and tackling it head on.

[00:43:09] Guy Podjarny: Yeah. I very much hope so. I mean, I think it's an area that would be just as important, so probably take a while to kind of rein in the chaos, but at least people will sort of feel like they're better equipped. Great predictions. Hopefully, many of those are kind of the trends we see ourselves headed to. I believe many of them, I guess there's a question a little bit if it's a next year's report or if it takes two, three, five years sort of for that to happen. But I think directionally, that's the path that we'd like to see and can actually happen.

[00:43:37] Simon Maple: Good call. Certainly not in next year's report, but maybe a few years that will be good to see. Yeah. How about yourself, Guy? What would you predict? What would you see in a couple years?

[00:43:47] Guy Podjarny: I think the shift in ownership is going to be the thing that drives the biggest change. You sort of see much more acceptance for product security, for this notion of letting go. Many more companies have a DevSecOps initiative that talks about moving things over. Now that people have a better appreciation of the problem, of the fact that there needs to be a shift in how we tackle security as part of how we modify our development, people are including the security transformation as part of their development or sort of digital transformation earlier in the process. If before we've sort of seen organizations first shift how they develop software, then realize security is a problem, and then maybe go off to address it. Now, there's a better industry knowledge to say, “Well, when you shift, as you shift, as part of that kind of new initiative, you need to include security.”

I kind of expect more and more and I see it on this podcast, with some of the smart people coming along. Clearly, the best people kind of come on here as forward thinkers. But still, you sort of see more and more of this mindset of security teams as empowerers, as multipliers to help developers and DevOps teams embrace it. I'd love to see that ownership piece that evolved the most.

Simon, thanks for coming on the show, for sharing all the data and, of course, kind of helping, you and Matt Jarvis helping create this report in the first place.

[00:45:13] Simon Maple: Absolutely. A pleasure to share it.

[00:45:14] Guy Podjarny: And thanks, everybody, for tuning in, and I hope you'll join us for the next one.

[END OF INTERVIEW]

[00:45:22] ANNOUNCER: Thanks for listening to The Secure Developer. That's all we have time for today. To find additional episodes and full transcriptions, visit thesecuredeveloper.com. If you'd like to be a guest on the show or get involved in the community, find us on Twitter at @devseccon. Don't forget to leave us a review on iTunes if you enjoyed today's episode.

Bye for now.

[END]