DevOps Chats: Analyzing WhiteHat Security’s DevSecOps Survey Results

Alan Shimel: Hey, everyone, it’s Alan Shimel, DevOps.com and Security Boulevard. You’re listening to another DevOps Chats.

We have a really good chat for today. I’m joined by my friend Eric Sheridan from WhiteHat Security, and WhiteHat recently did a survey that Eric’s gonna talk about that I think really, you know, for some of the questions at least, get to the heart of the whole DevSecOps movement and who cares about security, how are we doing with it, et cetera. But let me bring Eric on first. Eric, are you there?

Eric Sheridan: Yes, I am. Hey, Alan—thanks for having me.

Shimel: Fantastic. It’s our pleasure to have you on. Eric, just before we get started, maybe a quick, you know, your title at WhiteHat, and maybe there are people out there who don’t know WhiteHat, give them a little background.

Sheridan: Sure, sure. So, my name is Eric Sheridan, I’m a Chief Scientist over here at WhiteHat Security. And at WhiteHat Security, we’re very much focused on enabling organizations and people to build more secure software. And, being in that position, that gives us a unique perspective when it comes to supporting development teams, whether it be the DevOps, agile, or waterfall—whatever are the methodologies or principles that may guide that team, at the end of the day, we’re focusing whatever it is we can do to help you all build software securely.

Shimel: Fair enough. And Eric, in terms of your own personal background, just so people who wanna, you know, know who’s talking, can you give me a little bit of your history, of your—you know, how you got here today?

Sheridan: Absolutely. I actually started out in application security as a consultant for maybe five-plus years, where I was focusing on things like code review, penetration tests, threat modeling, training. And one of the things that allowed me to excel in that position was my development background. So, I’m also actively developing software, I build tools, and that gave me a unique perspective on the security challenges facing development teams.

So much so that in 2011, I actually co-founded a company called Infrared Security, whereby I was building a static analysis or a static application security testing technology that was eventually acquired by WhiteHat Security. And so, I joined the team at WhiteHat Security from there to help product ties on a lot of the hands-on experience I’ve had over the years in an effort to very much automate a lot of the security testing and the guidance that, before, just took days and weeks, right?

And so, I—goodness, 15-plus years in this space, it’s flying by, but having a good time doing it.

Shimel: So, just another newbie.

Sheridan: Yeah, [Laughter] just another newbie, exactly.

Shimel: Excellent. So, Eric, can you give our audience maybe a little background on the survey that you guys did?

Sheridan: Absolutely. So, at Developer Week Austin, which was this past November, we implemented something we call the Developer Security Sentiment Study. And in this study, we actually went around to a little over 100 developers, put them on the spot, and asked them some direct questions, some pointed questions around application security.

And it was pretty interesting. The results were pretty interesting and that’s, you know, I tried to boil it down into three themes, with the first being that there is a clear, that developers see the importance of security, but that there is a skill shortage. So, if I could just throw out a couple of numbers—75% said they worry about security, 85% say they mark it as important, but barely half of everybody we interviewed actually had any dedicated security staff in their team or their organization.

So, you know, the DevSecOps movement is very much resonating in that development teams, they see the value of security, but at the same time, you know, the investment into dedicated security people? We’re still seeing a skill shortage in that market.

Shimel: Okay. There absolutely is. There’s always—and there’s projected to be a skills shortage for years to come. Eric, so, if you had to boil it down, you know, give us the three top things, though, and maybe also include what you kinda were—what most surprised you.

Sheridan: Sure. So, the three things that, if I had to boil it down to were around there being a skill shortage that, as a result, we’re scanning faster, but the third being that we are inundated with results and we’re not acting fast enough.

And so, the part that’s—perhaps I’m jaded, none of these seem to surprise me too much these days—but the skill shortage was very clear, right? And in response to that, what we’re seeing is security teams and security tooling trying to fit more appropriately to support fast-paced CI/CD, DevOps types of environments. And, you know, looking at the results, about two-thirds of all the developers that we interviewed say they run automated security testing at least once a week, a third of which said they run at least once a day. And compared to five years ago, even, that’s a pretty substantial jump. So, from an automation and operation standpoint, that’s a plus.

The part that was a little unfortunate and close to being surprising would be the fact that we’re not responding—we, as people who are stakeholders in application development, are not responding fast enough. If you look at the WhiteHat Stats Report just as one example, you’ll see that the average time to fix and the number of days it takes to fix a critical securities vulnerability is 139 days.

Shimel: Wow.

Sheridan: And so, that was very alarming to me. And that’s just something you know, we pulled from Stats Reports and is supported by similar reports from other players in this industry.

But I bring that up because the other piece that we were able to garner from this developer week study is 70% of the developers that we spoke to said they had no application security certification, whether it be in their current job or their previous job. And that was really unfortunate for me to hear, as somebody who claims to—you know, states that their purpose is to support development teams. Because here we are finding vulnerabilities at an increasingly faster rate to overcome a skill shortage using automation and tools, but at the end of the day, we can produce results incredibly fast, but if we’re not supporting the people, development teams to be aware of these issues through things like training, then what is the value of finding those results so fast?

And so, I guess that’s the part that I was slightly shocked and a little bit concerned about was, you know, 70% of the developers not having certifications, but I view that as an opportunity as well, right? There’s a pro and con to every data point you have, and the opportunity, the pro is, to make more progress in helping teams build more secure software, there needs to be a greater emphasis on people, and the best way that I’ve seen to do that is through awareness training through security training, and I see that as an opportunity to really help, enable development teams that clearly view this as important to be able to respond more quickly to vulnerabilities that are being pushed out as an increasingly faster rate by all these various tools and forms of automation.

Shimel: Agreed. So, if you don’t mind, let me give a little color commentary here. You’re right, we don’t have enough security people and it is a skills gap and even if we did, I don’t know if we’re ever going to have enough budget to have enough security people where we have, like, a dedicated security person for every developer team. I just don’t think it’s in the cards.

Sheridan: Yeah.

Shimel: I think it’s prohibitively—business model-wise, it’s prohibitively expensive.

Sheridan: I agree. Yeah, it is expensive, and it’s not scalable. And at an age where we’re focused on reducing costs and being increasingly more scalable, that solution just doesn’t play.

Shimel: Right, that doesn’t work. So, now we—so, now we realize, okay, so, we need to take a security person on each team out of the equation, which means we need to, number one, automate as much as possible about the security, but number two, we need to make these security tools usable by non-security professionals; a.k.a., the developers, the DevOps teams, the QA people, et cetera.

And that seems to be where the market is headed, right? That’s where a lot of success teams are going.

Sheridan: Yeah.

Shimel: But it creates for an interesting, you know, power-play—I don’t know if power-play is the right word. So, here’s the deal—the tools are automated and made to be used by non-security people.

Sheridan: Right.

Shimel: But yet, the security team still has to approve them and the budget for these things comes out of the security budget.

Sheridan: Right. And so, yeah, there’s an interesting dynamic at play there between the development teams and the security teams. And, increasingly, security teams are finding that as they go to, you know, shift left, using that phrase—to define vulnerabilities early, to provide that automation early or to support development teams—the development teams, rightfully so, have a greater say in what technologies will or will not work for them.

And so, if you’re a CSO or you are a Director of Application Security or in some way, shape, or form responsible for acquiring these tools to facilitate this automation—you know, you may have the final say in terms of writing the check, but if you wanna be successful, your champion needs to be the development team.

And what I’ve seen really work with organizations is, a security team will go in, evaluate a few solutions, whether they be manual, automated or a mix of both, and sort of maybe select three or so that fit their needs from a, whether it be compliance or a security perspective. And then present those to the development teams, and effectively say—look, you know, we’ll cover the budget for this. We want you to derive value out of this. This meets our needs for what the goals we’re trying to achieve. What works best for you with these solutions to make sure that you can continue to hit your milestones from a product perspective?

Shimel: Mm-hmm.

Sheridan: And so, that’s the kind of state that we’re in today, increasingly so. There are a handful of organizations out there—there’s a number that’s coming to mind, it’s like 10% or less, and that’s probably from a conversation with some analysts—where development teams are deciding and paying for and budgeting for security solutions.

And so, you know, with the Sec coming in between Dev and Ops, to become DevSecOps is one thing. I’m not much of a fortune teller, but I wouldn’t be too surprised if we see that increase where development teams start to account for budget and select the security solutions that work for them, particularly when it comes to integrating within development tooling and processes.

Shimel: Excellent. I agree, I agree. You know something, though, Eric, and this is—it’s an interesting thing, and we spoke about it off-mic earlier. You know, there’s really sort of two tribes, and it’s a really interesting comparison when you look at answers from one to the other. So, when you look at the security people and what it is they hope to accomplish and how and then you speak to the developers in DevOps and what it is they hope to accomplish and how, they all want the same thing. We all want better security. We want more secure applications. We want—no one wants to be the victim of a breach or a vulnerability or what have you.

Sheridan: Right.

Shimel: But our attitudes of what’s the best way to accomplish it, though they’re much more in line than when they were, let’s say, five years ago even, could still a little calibration.

Sheridan: I would agree with that. You know, calibration can come in the form of just something like DevOps or DevSecOps. It’s one of the—the key value propositions I see is sort of the coming together of diverse teams to meet some common objective, and through a collaboration and discussion and an understanding of each team’s needs and goals, we can have better solutions.

So, I think you and I were talking about some of the needs and goals of the security team, right? They would make some claims that, you know, maybe the development team does not know about security or does not care about security, which we’ve demonstrated is clearly not the case. At the same time, the development team may feel security is too complex or it’s holding them back and that they can’t use the tools. And now, through the developer survey that we have here, we’re seeing that’s no longer the case, because they’re adopting more of these tools.

And so, yeah, just understanding each other’s perspective and goals can really help for a better relationship here. And at the end of the day, to build more secure software, we cannot live in silos. We cannot throw guidelines over the wall and expect anybody to read them or act on them. And I think what’s encouraging is, through initiatives like you’re doing here, Alan, with DevOps and some of the initiatives I see going on in the industry—that bridge is being established and that connectivity is growing. It just takes time. Change is hard, and it just, it’s not an easy thing to do.

Shimel: No, it isn’t; no, it isn’t. But hey, man, we’re getting near the end of our time and I don’t want to end this thing on a downer. I think we both agree we’ve made progress. There’s work to be done and even, you know, just getting developers involved as you said has not necessarily brought down the average time to fixing a vulnerability, but we need to do something.

But we’re making progress. You know, maybe I’m a glass half full kinda guy, but I do believe in that.

Sheridan: Well, Alan, I appreciate you saying that, that you’re a glass half-full because I sometimes joke that I’m a glass half-empty, so there’s a nice balance with our dynamics, here.

Shimel: Alright—there we go, a [Cross talk] balance.

Sheridan: Yeah, but if I had to take the glass half-full approach, I would say that it’s very encouraging for me to see so many development teams view security as important and their willingness to adopt automated security testing technologies. I mean, two-thirds of the developers that we interview, testing at least once a week? Several years ago, that would be unheard of. And so, that’s great.

And so, now, the next challenge is, how quickly can we act on the results? And that’s a great opportunity for us to mature this space even further.

Shimel: Yep. Agreed. Hey, when we started this, Eric, before I started recording, I told you the time goes incredibly quickly. We’re just about out of time here, but with RSA coming up, I just wanted to get a quick kind of plug-in. You guys are gonna be at RSA this year?

Sheridan: Oh, absolutely.

Shimel: And people can come by and maybe speak to some folks there about some of the findings on this?

Sheridan: Yeah, that would be great. We would love to hear feedback and any personal stories or experiences that you have when it comes to implementing security, we’d love to hear it.

Shimel: Excellent. Eric Sheridan, WhiteHat Security, our guest here on DevOps Chat—thanks for joining us, Eric. Hope to see you soon. Well, we’ll see you next month at RSA.

Sheridan: Sounds great. Thank you, everybody. Thank you, Alan.

Shimel: Alright. This is Alan Shimel for DevOps.com and Security Boulevard. You’ve just listened to another DevOps Chats. Have a great day, everyone.

— Alan Shimel

Recent Articles By Author

• From CEO Alan Shimel: Futurum Group Acquires Techstrong Group
• KubeCon 2023: Not Your Father’s Tenable
• KubeCon 2023: Bridging the AppSec Tools Gap

More from Alan Shimel