Application Security Benefits of DevSecOps with Mobb CEO Eitan Worcel

This is Textron tv. Hey guys, thanks for the throw. I'm here with Atan Cel, who's CEO of Mo, and we're talking about, well, SecOps, it's a great idea, but for whatever reason, we're struggling with it and we're not making as much progress as maybe we should.

Todd, welcome to the show. Thank you. Hi, thank you for having me.

Mike. You've been around the block a few times. Fundamentally, what is the problem?

Because everybody gets out of bed with the right intentions, but for whatever reason, we still keep making the same mistakes over and over again. Yeah, I think, I think, um, I mean, as you said, everyone has the, the, the right intention in heart with Shift Left and SecOps, and the intention is to be able to fix earlier, right? Uh, the old notion of DevOps was to help companies compete and run faster and deliver new capabilities faster.

The old concept of SecOps was to do it while keeping it secured, but present, SecOps missed a bit. The point about doing it fast, it, it puts a lot of gates in front of developers, and that's where it misses the boat a little bit. Is the issue that the, when we shift left, the cognitive load for the developers becomes too high.

So is there some way to do this that maybe leans left without fully shifting left, if that makes sense? Well, I think it does. Um, developers, like most developers like to do more like the independent, not like, not to need to wait for it, for security, and for all of those when they want to deliver new capabilities, but at the same time, they don't necessarily have the skills to do that, and the amount of work landed on them is too much, is too high.

And my take is security got us to the point where developers need to do more with a lot of more problems handing to them, and technology needs to be there also to help them address all those, um, additional loads. We've seen the rise of platform engineering, which at the end of the day seems to be about how to manage DevOps workflows at scale. Will we get better at this whole thing because we're gonna centralize more of the management of the process?

It's an interesting question. Um, I mean, overall, all the time we will get better and developers will get better and smarter. And I mean, until 10 years ago, five years ago, we didn't have the DevOps engineer, the SRE, I don't think that the same will apply for security in this case because, um, unlike the infrastructure, the it, that it was enough for one person in a group to do that with security, every developer may introduce vulnerabilities.

So every developer will need to have the capabilities to fix those vulnerabilities. And so I don't think it will be a new role, by the way. I think it will be new capabilities that will be provided to developers to fix those issues, to address them.

What is the fundamental issue with the developers? It seems to me that, um, cybersecurity in general was an elective for a lot of the training that they took, and most of 'em didn't take the elective. So, um, do we need to just fundamentally go back in and retrain these people?

Or can we get to a level of automation where they need to know hardly anything because the tools will be that much smarter? I mean, I would want to believe that there is a way to train all developers. I had, uh, interesting discussions.

So I learned computer science back in 1999. Um, security was definitely not in the curriculum, but even these days when I speak with young college students, they don't learn that, as you mentioned, it's, it's elective and most of them don't do that. You can't go and train the millions and millions of developers out there now on how to write security code.

I wish there was an option because if they write secure code from the get go, there won't be any problems. Um, we, we need to have, well, at the same time, there won't be business for myself and others. Um, but technology should come there to help.

At the same time, people need to understand that technology will not be able to address everything. It's not that now developers can write whatever they want and the tools will make that code better and secure. Uh, they could, the tools will be able to help a lot, but developers will need to have the conscious on how to write secure code to some degree.

And there are things that you will never want security technology to fix automatically. There are some changes that requires architectural changes and I dunno about you and then people that you talk to. I don't want anything automatically change my architect, the architecture of my code or the architecture of my house or the architecture of anything.

Um, just a small things. That's just the things that can be done automatically. Makes sense.

Um, I feel like the process is broken and the reason it's broken is it goes something like this developer a downloads a component from somewhere and it has vulnerabilities in it, and then we go fix that particular vulnerability and then developers, B, C, D and E go download the exact same thing over again and we gotta go fix that exact same vulnerability over and over again. So, um, it, the whole rinse and repeat cycle of this is driving people insane. So how do we kinda, like, once we fix something once, how do we make sure we can keep it fixed there forever?

Yeah, and I'll see yours and I'll, and I'll add to that even, right? Developers are known to work by copying code. So they will copy code from Buffer overflow, maybe, uh, sorry, stack Overflow, not buffer overflow fully, uh, stack Overflow, uh, Google even chat.

And once it's in their code, other developer sees in the code and they replicate that code multiple times. So you will have the same bad patterns in your projects multiple times. To your point, we introduce, let's say signal injection and one of the static analysis tools found that signal injection and the developer fixed it, but they have hundreds of other places in their code that now it happens.

How can they replicate that knowledge? How can they replicate that fix to other locations and prevent the next developer to copy the wrong code, either internally or externally? Um, I mean, you don't want to have Gates preventing developers to write code.

Even if they paste that code. You need to have the capabilities to quickly find it and fix it. And that's the problems.

Um, SecOps is a lot about findings those problems fast. You can do it on a PR level, you can do it while you type your code, but as you mentioned earlier, developers didn't learn how to fix that code. So they are facing a problem now in front of them, Hey, this code is bad.

This code is un insecure or unsecured, um, and how can they address it? How can they fix? And now in reality, they will spend hours now on trying to figure out if it's real problem and if it is how to fix it.

And it's, it's, it's hard to watch. I, I did some sessions with developers I asked them to fix, and it was really hard to watch how they scrimmage, how, how they're stuck and they don't know what to do. Um, to your point about generative ai, and maybe it'll get better, but right now it seems like the most popular one is trained on a general purpose platform, essentially.

And it pulls in code from everywhere and comes up with some recommendations and some of that code contains vulnerabilities and we need to watch out for that stuff. But I talked to other folks and they're like, yes, it contains vulnerabilities, but ultimately there are fewer vulnerabilities 'cause the developers are that bad in the first place. So is it an improvement or not?

So it's interesting. I mean, when, when we started, it was before Chad G PT came to life and the world suddenly, uh, is on fire because of that. With, with all the possibilities.

And we started to investigate, can we ourself use OpenAI and chat g PT to, in our technology to automatically fix stuff. We did a research, we just now published it because we were waiting for the latest update in, in, in OpenAI to see if, if changes anything. So to your point, we gave it to fixed vulnerabilities from known applications.

We didn't try to do something really hard on it, and we did a lot of pre-processing to help it work. There were at least one case. I remember when, um, we asked AI to fix vulnerability, uh, command and in the fix introduced a new vulnerability and no SQL injection.

So, so yes, AI is, is great to some things, but um, also something very interesting that we, we realize only now, even when we fix a code with our technology, or even manually when we fix a code based on best practice, it doesn't mean that the security scanner will identify that code is fixed, and that is due to limitations in those technologies in the SaaS engine. So imagine you're as a developer using ai, fix the code whether, and let's even assume that the fix is good, the fix solves the problem, but the tool will still report that there is a problem and they still need to go and triage the issue. And, and that can take anywhere between 10 minutes to an hour.

So they still spend time. So still SecOps doesn't deliver on its promise of going fast. And when you think about it even more, Mike, um, if you introduce security and now your DevOps becomes slower with SecOps, you hurt your business.

You make it harder for the business to compete and move fast, and businesses go out of business when they can't compete. Um, I think this is a bigger problem. Even the security sometimes I think there's a little bit of a debate going on that says, can we build applications securely quickly or do we need to slow down?

Yeah, I saw a lot of that debate. Um, so my, my answer for that is, if you slow down, and I, and I challenge people with that, when you think about the biggest companies in the world today, Mike, they all got breached and they're still the biggest companies in the world. Think 10 years ago, 20 years ago, who were the biggest companies in the world and did they get out, got out of business?

Did they get outta business because they were breached or just because they failed to compete? Moving slower puts your business at a higher risk versus the security breach, sadly, 'cause I am tired of getting all those letters in the mail. Your information was part of a data breach.

Um, the technology need to save us from ourselves in, in this case because the technology got us there. Um, so what's, what's your Sense, what is your sense of the bad guys these days? Are they getting better at targeting our software supply chains?

Are we starting to see more of this malware embedded into various open source components or wherever it might be? How smart are they? Well, you need to remember all the time the, the job for the bad guys easier because they can, they need to only get right once, right?

You may have the good guys need to protect their organizations, their business, their applications from every potential thing. Bad thing that can happen. The bad side only needs to get one thing right?

And, and yes, I, I do believe that with the help of the ai, they can write exploits faster, not necessarily be more sophisticated, but they can write exploits faster. They can send them out faster so they get a wider net, um, to the same problem that appeared in the past. They're, they have have better weapons to take advantage of it.

And I don't, I don't think it's more sophistication. I think it's just easier for them to amplify what they could do before and go faster. So the same problems in the past, just easier just going to be exploited more.

Who ultimately is responsible for all this. 'cause historically, the cybersecurity team at least has focused on spending on things that they control, like firewalls and the network and endpoints. And they kind of assume that the developers were doing something about application security and the developers assume that the security guys were doing something about it.

So nobody wound up doing anything about it. So are we getting better at figuring out who's in charge of this mess? I mean, everyone wants to say everyone's responsible and it takes a village, but when everyone's responsible, no one is responsible.

Mm-Hmm. At the end it's a security, it's a security job. It's their budget, it's their responsibility.

This is what they are trained to. It doesn't mean that they're going to fix it. So it's their responsibility to figure out who, how to make the, the right thing.

How, how would the developers and the businesses take the right choices? Um, I hear about different approaches. It's, it's, but it's never the gate.

It is never the gate. Uh, when you put a gate, you alien elevate your developers, especially because sadly, security scanning is not the most accurate, um, not the most accurate technologies in the world. They will call out issues based on the scope that they are looking at.

Um, they're missing anything outside of that scope. So a developer will look at the results that blocked their build or blocked their pull request, and they will sense that that is not an exploitable finding because there is some other mitigation outside of what the security tool saw that prevents that from happening. Um, it's, it's going to take a village because they will need to work together, but it's a responsibility of the security.

There is no question about it from my, in my head at least. Do we have a massive mess to clean up? Because we have all these applications running in production environments, and I think last time I looked into this, maybe three to 5% of the vulnerabilities that are in those environments have actually been exploited, which means the bad guys have a lot of work to go do if they feel like it, they can find all kinds of things that are in there.

So do we need to go back in and either rewrite all those applications or rip and replace 'em? So yes, on your first question, we have a problem. Um, think about any large organization that you, that it's out there.

Um, the very big ones, they have backlogs of millions, millions of, of triage vulnerabilities. And with number that numbers that I'm hearing about five hours to fix a single vulnerability, it will never be addressed in manual approach, right? The businesses will run outta businesses in that case.

So if you have an application that is 10 years old or more, um, I bet that you have hundreds of thousands if not more vulnerabilities there. Now, are you going to rip and replace? No, because again, you're going to lose business.

There needs to be, you need to apply automatic remediation. Yes, I know I'm talking from my book, my own book, but, but we are not the only technology that is out there, um, that supports it. And if we can automatically find things, there are things that we can automatically fix and we should start using it.

Companies should start using it all Right? That automatically fix things. That's a big conversation for some folks because the developers are like, well, I don't want you to automatically fix something.

You're gonna break something. And, but the security people are like saying you don't have time to fix it. So we wind up not fixing it at all, even though we know it's there.

So how do we find some middle ground? Yeah, and that goes back to the, to this interesting discussions that I have with people. Developers will copy code from Stack Overflow without thinking twice from Google, without thinking it's twice from charge PD.

They will think twice, but they will still copy it and letting security tool that knows how to write security code, do it for them, they cringe. Um, the approach needs to be, first of all, developers can use the tools that they're used to having more unit testing and regression testing that they're already using used to that. Uh, so that will help protect them.

Um, I, there is no reason for me to believe that a developer will make a CHI code change in code that they're not familiar with and have much better chances for not breaking the application versus in a, um, a very good automated tool. And I think that like, like with zero trust, you need to verify before you trust it. So look at the code change.

Let's say it's not fully automated. So instead of me spending five hours, I see the code change and it takes me an hour to val uh, sorry, a minute to validate it. It's not automated.

Uh, but once I did it once, twice, 12 times on the same issue, maybe I will trust it and I will let it run automatically again with the regression testing, with the unit testing to protect my, the, the issue. Do you think we should make developers sign some sort of document that says that they have been informed that there was a vulnerability and they decided that they didn't wanna date the application because they're afraid of breaking it, but then they have to assume their responsibility? So I have a, a good friend of mine, he used to be the head of product security in, in the insurance company, and he was tired of all the exceptions that people were asking.

And he implemented in that organization that if you want an exception for not fixing something, the executive needs to go into the tool and market. It's not by email. They need to go into the tool and market and a month later, if it's still open, needs to go into a market.

It it, it makes it painful enough for the executives. So the developer started to fix it. Is it better?

Um, to your point, it's not fair that the CISO that is responsible of everything doesn't have the mandate to force developers to fix it. So maybe that will help. Maybe that will deter people from stop from not fixing.

Um, I don't see it working actually. I dunno. We should, but I don't think it'll work.

People don't want that responsibility. All right folks. Well, if you think about it, maybe the enemy that we need to confront first is the one that we wake up every morning and see in the mirror, and then we'll go from there because it seems like the bad guys are just taking advantage of us and we're letting them do it Anyway.

Hey aan, thanks for being on the show. Thank you. Thanks for having me.

Bye-Bye. And back to you guys in the studio.