This episode of Security Boulevard Chats is with Cybric, CTO and co-founder, Mike Kail. Mike is no stranger to the security and DevSecOps community. Before Cybric, Mike had exec positions with Netflix and Yahoo, among others. Mike and I had a good conversation about “is DevSecOps a real thing?” What and who is holding back greater adoption? You might be surprised what and who is the answer.
The streaming audio of our conversation is below and the transcript of our conversation is below that.
Alan Shimel: Hey, Alan Shimel, Security Boulevard here for a Security Boulevard Chat, and I’m joined by my friend Mike Kail, CTO and cofounder of Cybric, which is “cyber” and “fabric.” Hot new security startup. Mike, how are you? And welcome to Security Boulevard Chats.
Mike Kail: I’m great, Alan, and thanks for having me.
Alan Shimel: Great. It’s our pleasure. So, Mike, first of all, before we jump into what I wanted to talk to you about, for our audience who aren’t familiar with Cybric, other than it’s a contraction of “cyber” and “fabric,” can you give us a quick elevator pitch on what you’re doing there?
Mike Kail: Absolutely. So Cybric, the SAS platform that we developed, is an automation and orchestration engine that seamlessly embeds security testing from code commit to application delivery. So, instead of coming out with another static-code analysis tool or scanner or dynamic app-sec tool, what we’ve done is architected this cloud platform that we can converge all of the existing open-source and commercial tools into a policy-driven framework that integrates from the far left, at your source code repo, such as GitHub or Bitbucket, at the artifact build with your CI platforms, such as Jenkins or CloudBees, and then at the far right, we replicate your application environment and run the dynamic scans, such as OpenVAS, Metasploit. You know, name your favorite dynamic app-sec tester – we can run those in parallel as well. And we do that against a fully-replicated copy of your production application, so we never affect production performance, corrupt data, or do anything else malicious against the live site.
So that’s kind of the, probably, one-and-a-half-, two-minute elevator pitch on what we’ve done. You know, the term “fabric” we use sometimes as part of the continuous security delivery fabric, where we tie together all of the existing disparate tools and give the CIO and CSO that single pane of glass view into the continuous security assurance and risk posture.
Alan Shimel: Got it. Got it. So let’s talk a little bit – well, before we do, Mike, I just wanted to also mention you guys have recently raise some more VC money, doing expansion, and Cybric really kind of seems to be catching some momentum.
Mike Kail: Yeah, the momentum has definitely increased. In June, Gartner listed us in their Cool Vendor report and then, since then, we’ve been listed in a couple of their Hype Cycle papers around application security testing and orchestration, as well as the vulnerability correlation sector. And then we’re working with our first handful of official customers and have a healthy pipeline – a proof-of-concept’s in flight, as well as our marketing team driving top of funnel.
So, definitely, I feel the momentum kind of shifting. I think it’s a good time. The term “DevSecOps” that we were talking about earlier is getting more and more tech credibility, I think, and people are understanding really the cultural shift and transformation that’s needed, you know, above the technology.
Alan Shimel: Absolutely. So, Mike, that brings us right into what I wanted to talk to you about today, and that is sort of “To DevSecOps or not? That’s the question.” And we were discussing off-mic, prior to recording, kind of the – some of the pushback that you get using the term “DevSecOps,” especially with – not from the developer community or even the CIO, but more from your hardcore security and CISOs, who – you know, and it may be a cultural thing of where the disconnect is, but what’s your opinion on that?
Mike Kail: I mean, first of all, full disclosure, I’ve been and we at Cybric have been using the term “DevSecOps” pretty standardly, and, you know, there’s religious conviction around whether it’s “SecDevOps” or “rugged DevOps” or “DevOpsSec,” depending on which group you’re talking to and their view of the landscape. You know, irrespective of that, I think people need to start thinking about like, “What’s the common goal?” If you look at one of the core tenets of the DevOps culture, which is collaboration, what can we all collaborate and improve to drive the business forward, instead of fighting our turf wars internally between DevOps and SecOps and other teams?
So I think security needs to start being part of the software development life cycle and embedded in there, and we can use “DevSecOps,” “SecDevOps” interchangeably – it’s not an order ranking; it’s about the full integration and interoperability between the teams. And I think that’s what we should start talking about, instead of getting into this deep discussion that –
Alan Shimel: Labels.
Mike Kail: – that starts getting people’s feelings hurt or they taking hard stances. That’s never a good outcome for the business.
Alan Shimel: You know, my attitude is “Call me whatever you want. Just don’t call me late for dinner,” but you’re right, Mike, and I think, whatever you wanna call it and whatever the label is, more importantly, as you say, security needs a seat at the table. Security needs to be involved earlier. And here’s the real, for me, Mike, the real kind of money shot, is we need to be automating security into the whole software development life cycle. Right? And I don’t really care at that point what you wanna call it, but security automation into the software development life cycle is paramount, I think, to us really doing a better job securing stuff.
Mike Kail: Absolutely. I mean, that’s our core thesis at Cybric. And, you know, the whole “seat at the table” conversation – I’ve said flippantly in the past like, “If you want a seat at the table, pull up a chair and we can start collaborating.” And we, as a industry, love to talk about this well-published shortage of cyber engineering talent, so that just screams for the need for automation and orchestration and allowing the security engineering team to be part of the SDLC but do so efficiently. I mean, it’s much like if you look at the old world of “make files” versus now Jenkins and Jenkins files, what Jenkins did to automate builds more fully. We need to have the same approach with security.
Alan Shimel: I agree. I agree. I think that what we are seeing is – you know, it’s funny, Mike; I used to think that all security people desired a seat at the table and wanted to be better integrated into the IT infrastructure in general, but I’ve come to the conclusion that there’s a segment of our industry, the security industry, that kind of relishes their “otherness,” if you will. Do you know what I mean? They take pride in the fact that they are separate and apart, and there’s good reason for it because everyone else is not as smart, not as important, not as – just not as –
Mike Kail: Well, I think the industry didn’t do that cultural divide any favors.
Alan Shimel: No.
Mike Kail: I mean, security typically has been sold on fear, uncertainty, and doubt. If you look at literally every marketing brochure, it’s a dark picture of a hacker in a hoodie sitting at a keyboard, you know, and this probably dates back to WarGames in the ’80s.
Alan Shimel: Yeah, no.
Mike Kail: We’ve glamorized this underground character, where security really needs to have business acumen and help drive revenue and keep product and security assurance high.
Alan Shimel: Yeah. Well, you know, I think it does go a lot back to the WarGames stuff, right? So, when I first got into security, there weren’t colleges offering degrees in cyber security or security. You know, you ask most people why they got into security, either they were the network guy and their boss made them do the security too or a very typical response we used to hear, when we were doing persona kind of research, was “Well, I really like to break things.” Right? “I always wanna figure out how to break things.” And somehow that translated to being a good hacker and hence a good security.
And, you know, I think, for people my age or people who have been in the industry as long as me – I’m not saying you’re old, Mike, but maybe as long as you – you know, that’s fine and dandy, but when we look at people coming into the industry today, I think they come with a different education, a different outlook, a different mission. Right? I think their mission is to be part of the bigger organization. What do you think?
Mike Kail: Yeah. And I think, you know, this term “white hat” hacker has really helped and we’ve started to make that a more visible role, and the fact that they can actually do good by protecting and playing offense on the security side and really trying to level the playing field. And I think they also – they’re starting to take much more of an engineering approach than just a “breaking things” approach.
Alan Shimel: Yep. That’s true. I think they need to act more like engineers and not just breaking things. So, Mike, let me ask you – I guess this begs the question of “Well, what do you think the future holds here then?”
Mike Kail: I mean, we placed a big bet on automation orchestration and then, not to use buzzwords loosely, but, as we get more and more data into our system, building out the machine learning model as we see vulnerabilities and how they were remediated, powering automated remediation or self-driving security. So now imagine a developer checks in code, we run a scan, we find that there’s a cross-site redirect error, we can create a branch in GitHub, fix the code, issue a pull request and even approve that later on, but, I mean, we’re starting to do this already. But, you know, automating some of the more mundane manual tasks that engineers, whether they’re security or not, have to do is where the future’s going.
Alan Shimel: Got it. Got it. I don’t disagree with you and, by the way, that’s the same future I think we see in development and IT in general – a lot more automation orchestration. So, Mike, let me –
Mike Kail: I mean, I think you have to have this repeatable process that mitigates human error and human configuration error.
Alan Shimel: Agreed. Mike, we’re almost out of time, actually, already – I didn’t realize how quick this was gonna go – but let me ask you a question. Are you appearing, speaking, presenting anywhere? Is Cybric exhibiting anywhere soon?
Mike Kail: Yeah. Thank you. Yes, I will be speaking at DevSecCon in Boston, September 11th and 12th.
Alan Shimel: Yep.
Mike Kail: Andre Bezdedeanu is our director of engineering – he’ll be speaking at the ISC2 Congress in Austin in late September. I believe it’s the 26th through 28th.
Alan Shimel: Great.
Mike Kail: And, at that same time, I’ll be speaking here in the Bay Area at the Structure Security event.
Alan Shimel: Oh, very cool. Very cool. That’s – you know what? I’ll speak to you off-mic about that. Sounds great. It sounds like things are going great at Cybric. Here at Security Boulevard, as we get going, we’re interested to hear more about it and we’ll keep a close eye on it. But thanks for being our guest on Security Boulevard Chat today.
Mike Kail: I appreciate it, as always, Alan. Thank you.
Alan Shimel: All right. Mike Kail, CTO, cofounder of Cybric, on Security Boulevard Chats. This is Alan Shimel and we hope to see you soon on another chat.