Most applications today are deployed with vulnerabilities, and many are never patched

TechRepublic’s Karen Roby spoke with Manish Gupta, founder and CEO of ShiftLeft, about cybersecurity in the development process. The following is an edited transcript of their conversation.

SEE: Social engineering: A cheat sheet for business professionals (free PDF) (TechRepublic)

Karen Roby: We’re driven by software, of course, everything we do and everything’s moving to the cloud and things happen so fast, the rate at which things are changing and updates. I mean, it’s mind-boggling, Manish, when you really think about it. And, unfortunately, with this form of delivery and the speed, security is that one really important piece, that is left behind. Before we talk about what can be done, how do we change this, fix this, how vulnerable are we? With security being left out of the equation oftentimes when it comes to software, where are we seeing that we are vulnerable?

Manish Gupta: Indeed. An important statistic that comes to mind is 95% of the applications that are deployed, that are shipped are vulnerable for at least some time during a year.

Karen Roby: Wow. That’s a strong number.

Manish Gupta: It is indeed. Sixty percent of the vulnerabilities we find were never fixed.

Karen Roby: So, we’re just hoping and praying that someone doesn’t take advantage of that. Right?

Manish Gupta: Yeah. I suppose the important part here is to embrace the truth that companies live to please their customers, to satisfy the requirements, to grow the top line. And security to the extent that it asks that business to slow down so that security can somehow help make the business more secure, are we surprised that security always gets left behind? We shouldn’t be. We’ve been doing this for almost 20 years now. That is why I started the company ShiftLeft, which is shift-left. The notion that in order to just continue to produce software with all its vulnerabilities we deployed in production and then hope that the deployed solutions, such as firewalls and antivirus, would somehow magically protect this application is fundamentally wrong. And that we have to get better at writing software more securely, and that can only be done if we can shift security left and do this as fast as developers want to write code.

SEE: SolarWinds attack makes us distrust the software we buy (TechRepublic)

Karen Roby: Let me back up just a little bit. Before we talk about the developers specifically and what they need to do, give some examples. Where are we seeing that this vulnerability has really cost us or costs companies, just a couple examples?

Manish Gupta: Oh, there are so many. Of course, the famous attacks, breaches of the recent past, let’s start with SolarWinds, which was, of course, a fairly complex attack of its kind. But in the last five years, whether it was Capital One, whether it was Equifax, and so many other software companies that get breached. But also some of our laws, in order to be able to share publicly when a company gets breached, are so lax that many of the breaches that happen, the public is never made aware.

But I’m sure, if you are in the audience, or you yourself, Karen, if you avail yourself of some of these software-centric innovations out there, I’m sure every so often you probably get an email, “Hey Karen, we were breached. Your password is now being stolen. We recommend you go change it.” And this has happened so many times, State Farm, Allstate. It’s hard to actually come up with a company that has not gone through it than to actually come up with a company that has been breached.

Karen Roby: I think people, I don’t want to say they’re numb to it, but it’s kind of like, “OK, got another notice. I got another email. You need to change this.” I mean, that’s just kind of commonplace, unfortunately.

Manish Gupta: Yeah, and that is the sad part. I suppose this does parallel the five stages of grief. We’ve come to accept it. I think therein lies a stark difference between grief, which has already happened, and security incident that has not yet happened. We can strive for better. We can strive. Of course, we’ve seen application-level attacks like Equifax and Capital One, and more recently the SolarWinds.

I was talking to a CISO the other day, and he said it really nicely. He said, “Manish, SolarWinds attack is like poisoning the well. We trust, for example, our water supply. Very similarly, we trust our software vendors. You and I, as consumers buy software. We just, of course, never ask a question. We deploy it in our machine and we give it all kinds of rights. Well, enterprises do the same thing. Now, if that very trust that we place in software can be broken, can be compromised, this also leads to apathy, indifference? That’s a pretty scary place to be. I, for one, definitely want to strive for better.

SEE: How the SolarWinds attack may affect your organization’s cybersecurity (TechRepublic)

Karen Roby: Yeah, most certainly, and I guess that’s the question is. If the train’s barreling down the tracks and these companies, like you said, is the bottom line and satisfying customers or stockholders or whomever it may be, so how does security get worked in to say, “Oh, wait a second. No, no, no, no, no, we’re getting ahead of ourselves here.” How do we change that?

Manish Gupta: If you break the problem into its very ingredients, there are the following things. One, speed, of course, as we just talked about. We used to get one software release in six months. Now we get a hundred feature enhancements in a given day from highly agile companies. So, clearly, speed is very important. Gone are the days when we could run a code analysis scan once a week and throw it over the wall to developers. Once a week is already too late—once a day is late. And so what that means is every time that we make a change, as developers change code, there is a likelihood of a vulnerability being introduced. And as soon as a scanner sees a change, it needs to scan and provide the information to the developer saying, “Hey, whatever you just changed caused this vulnerability to take place.” Speed of scanning becomes super important, but this has other advantages. We have found that if a developer is informed right away of certain vulnerabilities that his work has caused, they are able to fix that vulnerability with 70% efficiency compared to historical models.

The second part is, I did my four-year undergrad in computer science. I never took one cybersecurity course, and that’s just the nature of the problem. The world demands a lot of developers. There’re going to be, like, 25 million of them. They’re all studying computer science, programming, software development, but no one takes a cybersecurity course. And therefore, another very important persona is application security; that is their area of expertise. But historically we’ve not had the collaboration between developers and AppSec. Both are equally important to get this problem fixed, and so tools that have not catered to establishing collaboration haven’t really advanced the goal post.

That’s what we are trying to do at ShiftLeft, is the very platform, the very workflows are built for collaboration. So, if you’re a developer, software development, and I’m in application security, every time you write software, instead of me coming to you after the fact, I’ve already put down my requirements as rules in your software development practice. And so it’s speed; it’s accuracy. If I continue to come to you with a whole bunch of false positives, I’m crying wolf. Sooner or later, you’re going to start ignoring me. That is important. And finally is the workflow: How can we collaborate in order to let you run fast to develop features, but also become more secure?

Also see