DevOps Chats: Security for Developers, With ShiftLeft
DevSecOps has become a real thing over the last few years. The big shift has been making security tools that developers can use. ShiftLeft has been one of the leaders in this movement, recognizing that security had to shift left (hence, the name).
In this DevOps Chats, I had a chance to sit down right before the holidays with ShiftLeft CEO Manish Gupta about how the shift to developers using security tools is helping to make applications more secure.
As usual, the streaming audio is immediately below, followed by the transcript of our conversation.
Transcript
Alan Shimel: Hey, everyone, it’s Alan Shimel, DevOps.com, Security Boulevard, Container Journal. You’re listening to another DevOps Chats. Welcome to our chat. It’s probably maybe the last chat of the year for me. We’ve had a great year of DevOps Chats, and I think we’re gonna finish it really strong.
I’m happy to be joined by an old friend of mine from the security world, Manish Gupta. Manish is the CEO of ShiftLeft. Manish, welcome to DevOps Chats.
Manish Gupta: Thank you, Alan. Looking forward to it.
Shimel: Yeah. So, Manish, what a great name for a security company, right, in the DevSecOps space, because at the end of the day, ShiftLeft is so much about what it’s about and what we’re trying to accomplish. So, you know, we’ve spoken before, I’ve told you this, it’s a great name.
But what’s new with ShiftLeft? What’s going on?
Gupta: Yeah, so ShiftLeft, we—you know, we are focused on sort of the application security, next generation in application security, because there are a lot of trends, right, I mean, which you speak of at DevOps.com and KubeCon, Security Boulevard, which is, developers are writing software faster, delivering capabilities to their end customers faster, and deploying workloads in the hybrid cloud. And in this new world, which is characterized by speed, we need application security that is built for today’s environment, that is (a) fast, (b) accurate, and built for developers, right?
And so, that is what we’ve been doing at ShiftLeft, and what is new is, now, we have launched sort of a self-serve code analysis solution which is free for developers to try. Because what we have seen is, you know, with developers, you don’t want to market to them, right? I mean, they’re very busy folks and they want to experience it. They don’t like getting calls from SDRs or read a bunch of marketing material. If they get interested, they just wanna try the solution out, and if they like it, they should be able to use it for free to a certain extent, and there perhaps comes a time, depending upon the size of the organization where it is appropriate to start talking about getting an enterprise-wide deployment. So, that is precisely what we’ve launched earlier this week at ShiftLeft.io.
Shimel: Absolutely. And Manish, really, I mean, this is just, you and I were talking off mic before we went live on this today—you know, we’ve both been in the security business for a long time, and let’s leave it at that. [Laughter]
Gupta: [Laughter] Yes.
Shimel: But the reasons we’re in the security business is—look, it affords a good living, I’m not saying it doesn’t. But really, in order to be in the security business and stay in it for as long as you and I have, it’s because, you know, fundamentally, we want to try to do something good about the state of security, right, all around. Every time I hear about another breach or I hear a story about someone who got phished in something, it’s like, a little piece of me dies, you know? What is it—every time you hear a bell ring, an angel gets its wings? Every time I hear about a breach or something, a piece of me is just upset. And if you’re in security, that’s the kind of posture you take—you shake your head and say, “We need to do better.”
And so, for people like us, Manish, this whole DevOps and DevSecOps and ShiftLeft kinda theory, it makes so much sense. But the fundamental piece of it that was, that needed to be validated and then done was making security everyone’s responsibility and showing that—you know what, developers care about security. Developers wanna develop higher-quality applications. Ops and SRE people want secure applications out there.
It’s not just security people who want better security. Other people care about security, and at the same time, a realization that security people aren’t just here to say no or to drag things down, we want businesses to succeed. We want great applications out there. We just want them to be done in as secure a manner as possible, and in order to do that, we need it to get to the point where we make security tools for developers so we can shift this further left in there. And that’s exactly what you guys are doing.
Gupta: Yeah, indeed, and I think you said it, right? One of the key concerns that I hear about security from the customers, industry at large, is that the rule and signature-based security that we have largely had for the last 20 years clearly hasn’t worked. And if everything around is us going to be driven by software, and software that is much more rapidly developed and deployed than historically it has ever been.
And so, we need to rethink security. We can’t continue to put crappy software out there and expect it to be protected by sort of legacy security tools. It has to start at the very source, which is applications, which is making sure that we are taking the time to minimize—not eliminate, because that’s not possible, but minimize security issues in our applications.
And you’re right—developers do want to provide such capabilities, do want to release applications that are more secure. But if we continue to ask them to do this with legacy tools that take hours to analyze a piece of code, clearly, developers can’t be using it, because we are asking them to also, in parallel, deliver features to their end customers ever faster.
And so, that’s one of the key innovations that we’ve done, which is to be able to analyze code very accurately, so we are three times more accurate than anyone else in the world, but also to be able to do it really fast. So, we can analyze about 200,000 lines of code in about 30 seconds—30 seconds.
Shimel: Wow.
Gupta: So, that’s what we are trying to do, right? Our vision is to be able to push code analysis to every pull request, right? So far to the left, every time a developer does a pull request, they should invoke ShiftLeft, and within a matter of seconds, get the results.
And so, the thing is, the goal is, before the developer switches context and moves on to whatever he has to do next—before that happens, at his fingertips should be, “Hey, John, based on this pull request, here are the three things that you need to go fix.”
Shimel: Absolutely. And that—and you know what? If we can empower developers at that level, not to talk down with them and say, “John, let me explain to you the complexities of GDPR and why this needs to be done,” just—
Gupta: [Laughter]
Shimel: – you know what I mean? People don’t wanna hear that from security folks. I even—sometimes, I think security folks say it to empower themselves, but if you could just say, “Hey, John, we can improve—you can improve the quality of your app doing these two or three little fixes here that we see,” of course, John’s [Cross talk].
Gupta: Exactly.
Shimel: Right? John wants it.
Gupta: That’s right, [Cross talk]. No, you’re right, and I think the—and that’s the other part, right? Is when, historically, application security was the domain of AppSec, the workflow was almost, AppSec would run code analysis, find hundreds of issues and then give them to developers, right? And it’s almost like talking down to developers, meaning—hey, the piece of software that you developed is so crappy, it’s got so many issues, right?
Instead, the notion needs to be a bit different, and especially in the way we develop software, where any given piece of software today uses so much of open source libraries and frameworks, there is the other aspect, also, which is not just perhaps mistakes that were made, but also, are you adhering to best practices?
So, let’s take a very simple example. So, let’s say in the world of Java, you’re using the Spring Boot framework. Well, Spring Boot framework has been around for a while, and so, as a result, there are lots of best practices that have been established that developers should adhere to when using Spring Boot. But, again, you know, we are asking so much of our developers. Can everyone adhere to those or is even knowledgeable about what those best practices are, and is adhering to them? Well, if not—well, that’s precisely what ShiftLeft can also to do is to tell you, with every pull request, “Hey, are you adhering to the best practices?”
Shimel: Mm-hmm.
Gupta: Right? So, again, you know, whether it’s called DevSecOps—
Shimel: Absolutely, and that addresses—yeah, no, but Manish, if I may, that addresses another inherent problem that we, you know, and ShiftLeft is addressing here. And that is, we don’t have enough security experts to go around. We don’t have a security person for every team to say, “Hey, this doesn’t address this issue” or, “This raises a problem with this governance or security thing,” right?
We need tools like a ShiftLeft that become force multipliers for the security team, so that we can operate faster, more secure, even though we don’t have one security person for every Dev team, even. Do you know what I’m saying?
Gupta: Indeed.
Shimel: Yep.
Gupta: You’re absolutely right. You know, we—there are all kinds of statistics as to how many millions of developers there are, and if, for every pull request, we needed a similar level of headcount requirement for security, we’re never gonna get anywhere.
Shimel: Nope.
Gupta: So, you’re right. I think we need to help developers in their own sort of workflow be able to do some security. And I think that—I mean, one part of the discussion that we’ve had so far is code analysis. But that is precisely one of the things that we focus on at ShiftLeft. We are of the mindset that—yes, during development, we should minimize security issues, but we also believe that we will never be able to eliminate all the issues.
And so, we do require protection for issues that we weren’t able to fix. So, let me take a very specific example. So, let’s say you did a pull request and there are three issues that ShiftLeft tells you you should go fix. Let’s say you, because of time to market urgency, you are going to be able to fix one but you can’t fix the other two. Well, what should you do at this time? You have no choice but to leave it in production and, what, cross your fingers and hope no one will attack you? Right?
But that is the other innovation at ShiftLeft where, because we precisely understand quote-unquote the attack surface of this pull request, meaning there are two vulnerabilities that aren’t fixed, we provide an ability to protect those two vulnerabilities in production. So, it’s really the end to end solution that makes what we do at ShiftLeft unique. And this code informed runtime as opposed to signatures, writing signatures, is the powerful notion of how we protect applications much more accurately.
But then the other facet also happens, which is, we take this run time information and help you prioritize code analysis results. So, again, I’ll use an example there. So, we give you three vulnerabilities, and the only way today you have, in the industry you can prioritize them is based on OWASP severity. Hey, this is SQL injection, they should be the highest priority. It does not take into account, at all, your unique environment.
And so, by taking production traffic, which is a best practice for QA, we can spin your workload, we can throw that QA traffic, and now, we can tell you, “Hey, out of these three vulnerabilities, the first one is really the most important, because it sees the most number of calls go to it.” Being able to do all of this in a matter of seconds to minutes is what we believe is going to make—advance, mature application security.
Shimel: Absolutely. I mean, and Manish, this was a similar thing we went through in the traditional vulnerability management space, right?
Gupta: Right.
Shimel: For so long, we—you know, back when I was at StillSecure, and you’re familiar, right? We had a vulnerability assessment and management tool as well as a NAC and, you know, we used to call the vulnerability VAM, we used to call it the bad news generator, because you’re [Laughter]—
Gupta: [Laughter]
Shimel: – although, you know, you would get a stack of 1,000 to 2,000 or more vulnerabilities that it found. And then, of course, we could prioritize them using the Miter and the Myst, you know, CVE guidelines. But it really didn’t take into account—well, this vulnerability might exist, but was it reachable? Was it exploitable? What was the workaround, right?
And so—and then delivering, we’re not gonna have enough time to fix all 2,000 vulnerabilities, but where can I get the most bang for my buck, right, in remediation.
Gupta: Exactly.
Shimel: And that kind of logic and that kind of security know-how needs to find its way into AppSec and into DevSecOps as well, and it sounds like that’s kinda what you’re doing with some of the newer ShiftLeft functionalities.
Gupta: Indeed. Indeed.
Shimel: Got it.
Gupta: You know, with the new world comes sort of newer problems, also, right? So, one of the things we are starting to hear about a lot is developers, again, because of the speed with which we are asking them to run their hardcoded credentials, their hardcoded secrets, right?
So, it’s not something that we ever talked about ‘til about a few years ago, but cloud sort of brings with it its own set of issues. And how—you know, so, it’s not just vulnerabilities such as SQL injections, cross-site scripting, but it was also, whether you call them best practices or business logic flaws such as—Hey, are you accidentally hard coding secrets and cannot attack or get to them? Right? Or are you, do you have some malicious code that is now part of your application because you used this open source library that some bad guy has deployed malicious code?
So, you know, broadly speaking—so, if we uplevel this conversation, source code or software, which is driving everything around us, is increasingly becoming its own attack surface.
Shimel: Yep. It is. But it’s also—you know, I don’t want to blame open source, but with so much of these applications really having, you know, 75, 80 percent or more open source components, it’s inevitable that that’s gonna happen at some level.
Gupta: Correct, right? I mean, in some circles, this is being talked about as the infection of the software supply chain, right? How do we maintain the sanctity of the software supply chain? Yeah, and I think one part of it is to make sure to give developers information at their fingertips, that—hey this library that you’re using has this vulnerability, so please use the latest version where it’s perhaps fixed. And that’s one set of problems that we have been looking at as an industry for quite some time.
But the next set of problems now are—you know, because you’re not just using one open source library, that open source library might be using another one, which might be using yet another one, right? So, now, you’re seven levels deep and, if I’m a bad guy, I’m trying to get into some of these sophisticated organizations—can I, over time, plant a back door in some open source library that is a child library for many of the broader ones and this way, land up being part of the attack surface in many of these organizations?
And so, all of this is gonna require that we inspect source code much more granularly for not just vulnerabilities, but also what we classify as business logic flaws.
Shimel: Absolutely. Very cool, very cool. Manish, you know—geez, the time goes so quickly. We’ve gotta wrap up.
Just, you know, it’s the end of the year looking forward to next year—you guys, are you at RSA Conference this year?
Gupta: Yes, we are going to be there.
Shimel: Okay, so, we will hopefully see you there. We’ll be doing video interviews all week on Broadcast Row. Perhaps we can meet in person and continue the conversation there.
Gupta: Yeah, I’d love to. Just don’t put me on video, I’m an ugly guy.
Shimel: Well, look, I got a face for radio, but if I can do it, you can do it.
Gupta: [Laughter]
Shimel: It is video, and it is live, so come dressed. But until then, Manish, for people who want more—want more money—who want more information around ShiftLeft and around, you know, what you guys are doing on DevSecOps, is it ShiftLeft.io?
Gupta: It is indeed ShiftLeft.io, and you should see a big sort of red button at the very top which says Free or Try or Log In—and yeah, try this tool out for yourself. See if it works. See if you’re able to, for example, detect hard coded secrets in your software that the attacker can get to.
Shimel: Absolutely, and that is—again, we didn’t even get into that, but with this whole open source free thing and who we’re selling to, the democratization of IT, having a free offering is kind of table stakes today that you must have. We’ve talked about it another time.
Anyway—hey, my friend, we’re out of time. Manish Gupta, CEO, ShiftLeft—thanks for being our guest on DevOps Chat today.
Gupta: Thank you, Alan.
Shimel: Thank you, and we’ll maybe hook up seriously in RSA in about two months, but until then, have a happy holidays, a happy new year, and to all of our listeners at DevOps Chats, have a great new year, a merry Christmas, happy holiday season, everyone. This is Alan Shimel, you’ve just listened to DevOps Chats.
