Application Security Debt – Jeff Martin, Mend

This is texturing TV. Hey guys. Thanks for the throw.

We're here with Jeff Martin who's vice president of product for men. I'm gonna be talking about what goes on with application security these days and all things vulnerabilities Jeffrey. Welcome the show.

Nice to meet you. Nice to be here. I should say I've met you many times.

It feels like you know, we kind of don't talk about this enough, but there's a significant amount of technical debt when it comes to application security out there. A lot of folks will build and deploy applications that kind of tell themselves. They'll get to some sort of vulnerability that they know about eventually a lot of times they don't know about them and they don't even know the exist and nothing gets done at all.

So yeah as they used to say back into vernacular or are we cruising for a bruising here and things going to get worse? You know, it's funny. I was I was talking about this repeatedly for the past month or so.

Yeah, things are gonna get worse. We have I think a bumpy time ahead especially with some of the economic pressures and companies that aren't as mature with their app SEC Mayview security as a cost center. So I think that not only is Just our general maturity in the application security discipline a little bit insufficient right now.

I think in the next year or so we're gonna have a lot of cost pressures that are really gonna force people to prioritize but they're spending money on So what is the fundamental problem? I mean, I don't think people get out of bed the morning and go. Oh, let's go build an insecure application.

So where does everything kind of break down? So I think there's two big avenues for that. The first is just increasing complexity.

Our applications are becoming more and more complex. So fundamentally, especially with the rise of things like Cloud native you end up really stitching together an application. It's a dynamic configuration of a bunch of services and containers and deployments all running together.

I'd like in it to instead of building a car You know putting together a bill of materials putting them all together and then driving it down the road nowadays. The cars parts are changing as you're driving them. And that just creates this huge complexity problem.

It's hard to even keep track of all the pieces never mind the security of all the pieces. And then the other Avenue is frankly. It's still a relatively.

Let's say compared to Quality a relatively immature discipline that hasn't been fully automated hasn't been scaled in the same way that other kinds of application risk have been. As we go along does the relationship between the security teams and the developers need to change or is it changing or you know are these two cultures that are just never going to come together and do we have to just throw everybody in a room and lock the door and see what happens? So I do look I think there's been traditionally a little bit of a Handover throw it over the wall.

It gets thrown back. You know, you didn't I think that's changing and I think it's changing for a few different reasons but to the big ones one cybersecurity professionals are becoming thin on the ground. There's not enough of us.

And so developers are having to take on some of that responsibility. And so it's getting democratized a little bit just due to scarcity of professionals who can focus. And then the other reason is I think everybody hates that throw the throw it over the wall.

Throw it back. It's kind of a lose-lose for everyone. and Just to be very blunt about it.

It can turn into a lot of finger pointing or they're slowing me down. So both sides are actually coming together. I do think long-term.

It'll start collapsing into each other and the rules will become a little bit more. Cybersecurity provides guidance and education and stops being a blocker. As the developers pick up the security burden themselves, and so security becomes an enabler not a blocker.

Truth be told a lot of developers, you know use that excuse about productivity as a reason not to be so good at security, right? They're basically saying, you know, this is somebody else's problem and I got to write all this code quick and I got to meet all these deadlines. So the question is is can we build applications at the rate that we are on maybe even faster and build them securely.

It's funny because they developers are after all the kind of engineer and there's that old engineering maximum, you know, do you want it fast cheap or good pick two? And the fact of the matter is that's not sufficient anymore. I think they tend to view it that way, right.

Oh, look I can do it. Really I can spend a ton of money and do it quickly. But I you know, I'm gonna sacrifice good.

quality and security I think slowly everybody is realizing that the definition of good software includes secure software. It's right up there with does it do what I mean it to does it function. And the excuse of it slows me down.

Isn't any it's not a good excuse anymore. It's stopped being a good excuse a little bit ago in the same way that I can't say. Oh you want the software to work?

That's gonna Slow Me Down. It just doesn't track. You know definition of work includes being secure.

Developers would also sort of expect that a lot of these issues are gonna be handled by the platforms and the CI/CD pipelines and all this stuff is gonna get automated and it should just fix the code when I you know, it's a low level trivial thing. So, you know, how automated are we getting into the point where maybe we don't have to trouble these developers with this, you know, Teskey little security issue. Yeah.

I wish it worked that way because no I mean look even as a tool vendor myself, I will tell you tools can't solve everything right now. They're it's too hard of a problem set. You can't automate away all the security you can't.

Basically hit an easy button and then everything you deploy secure. It is a discipline and it has to be checked. um that said there is a lot going on on the platform side.

You know, when I deploy into Google cloud or AWS or Microsoft azure. There's a lot of secure security features that are present there and it does create this odd handoff of what's my problem as a developer versus the problem and Contracting out as part of my cloud services at least for modern applications, but now there's no easy button still the fact that matter is the main things that we can automate right now. Um with some few exceptions is the detection of issues.

SAS findings SCA findings, you know misconfigurations and only recently have we been able to automate things like prioritization of those issues and remediations and as somebody on The Cutting Edge of Auto remediation I can tell you it's not a cure all yet. We're probably good five years 10 years away from that. So you don't think AI is going to come along and save us all from ourselves anytime soon.

But no kind of in general period but also specifically in the abstract space computers are very good and AI is very very good at handling Big Data quickly and deriving insights from it. But the fact of the matter is security is not quite just that deterministic like every other form of risk management. It requires judgment calls and what you find is acceptable risks.

And fundamentally the main people were protecting against other humans not computers. Do you think we need to retrain all the developers and I ask the question because yeah, if you're in college and you're studying to become a developer or where else you're going Securities and elected it's not a requirement and you know anything that's in elective is pretty much not taking by people who are in a hurry to go to work. So, you know, maybe is the fundamental flaw here is that we just allowed security become an elective for all these folks.

Yeah. Funny I think the biggest problem and I touched on it briefly. is code quality isn't an elective.

It's part of how your topic code. Your code needs to work. Your code also needs to be secure.

It needs to be part of the basic education of all developers. And I think a lot of companies are beginning to do that. schooling systems and how we train developers prior to actually working an Enterprise's is not and smaller medium sized businesses You know, they're just doing the best they can without much of a focus on it.

But at least the big Enterprises are doing a lot of on-the-job type training and that's why I think the role of a cybersecurity professional in those organizations is really turning into things like education, but boy, it would be nice if everybody was as educated on secure code as they are in writing quality code coming out of school. Well speaking of that. We have all these wonderful SecOps processes that people are trying to build there is a sermon is given everybody knows their head in agreement and then they go off and do whatever it is.

They normally do I'm And I guess the question I'm trying to drive at a little bit is do we need to find a way to kind of make that stick in a way that is a cultural change. And what does it take to do that besides standing up in front of everybody and say thou shall so I think it actually goes back to an earlier question. Yes, which is are things going to get worse or better or where are we going?

I think we're probably still a couple of shocks to the system big breaches big violations cyber warfare something that sort of wakes everybody up a little bit. But I actually see this happening already on the Enterprises the really big ones they know. That it's just a matter of time before there's a shock to the system and they're doing the best they can to prepare.

by creating decent practices and doing education, but the fact of the matter is until it becomes very apparent to people. The monetary and other kinds of risk. That they're taking on by not.

Having it being fully secure. I think that Frankly, it's going to continue along the way it is for a little bit. We're probably a shock or two away.

That said there's a lot of people like, you know, obviously advocating standing up and saying Thou shalt just my experiences thou shelf works a lot better when it's Thou shalt because look at this problem over here that just happened. We don't want to happen to us. All right, we've seen those so called wake up calls many times in the past already and each time.

They occur. Everybody stands up and says yeah this time for sure. It's the wake-up call and then about two weeks later everybody rolls over it's this news button again, so, you know the colonial pipeline for example.

Yeah, so I'm not sure these shocks the system. We're working in the way that they're we had hoped their intended. So I don't know is there's some other way to think about it.

I do think that they're having some results, you know, like a lot of the work like sisa is doing right now, you know something that was driven by the colonial pipeline, of course, but a lot of it in the works before the executive order on S bombs for federal purchasing that went out about a year ago now, I think there's some. realization especially on the federal level that we need to get better. and I do think those are slowly.

Driving us in that direction. You know, I've heard the word best bomb more in the last six months than I had in the previous five years. I think this is steps in the right direction that are driven by shocks.

But it is slow progress. I agree. It's a little frustrating right when you can see that.

Nobody likes to Cassandra, you know screaming at the sky is falling but you know, the fact of the matter is we under invest in cybersecurity both from execution and from training. Well most business Executives when they hear the phrase s-bomb probably think it's a new kind of type of cocktail somewhere. So the question I would ask you you make me want to go make that now just like figure out what's in it exactly and so the question then becomes, you know, what are we gonna do to get the business side to kind of drive this harder because that's the thing that the developer side will ultimately respond to So I mean as one of those business side people sometimes myself.

I will tell you we're driven by a couple of things one is requirements standards certifications. And I think a lot of those are going in that direction, but we're already there to some degree in the highly regulated Industries like Medical but that is slowly spreading out to generalize application development and same thing too requirements for the ecosystems. You play it, right?

You know, mobile applications actually have some reasonable security standards because if you want to be in the store for Apple, you have to have certain amounts of security. But the other part is customer demand and that's the part that I see really ramping up right now. We all sell our applications to somebody for the most part.

Whether it's another business or sometimes consumers. and the other stakeholders are beginning to demand security. And frankly the same way that the demand software works.

Um, you know solar winds whatever whatever we could say about the lessons learned from that. I think one of the big lessons was hey, you're dependent on your vendors for the applications that they provide being secure and there needs to be a minimum level of things like contractual agreements there. So I think there is a lot of business.

push towards this because look the two people I listened to the most on the business side are. The compliance and regulations that I have to comply with and the people give me money. And so as they eat a band more security and more transparent security.

You know, of course the business beside is going to listen, but I do think that's going to be a journey to take over the next three to five years. It's not going to be tomorrow. Do you think we've become Our Own Worst Enemy because we embraced agile programming and then we told ourselves that anytime there's an issue.

We'll rapidly fix it, but we never do and so then the problem becomes this, you know continuous life cycle of issues where vulnerabilities never get addressed and this is becoming part of the problem. So maybe you know, we need to tell ourselves that you know, we can't just experiment on the end users anymore. It's funny because it it goes back to another question you had earlier which was you know, are we kind of making things worse?

Um, especially like if you think about agile as I pointed out the complexity problems getting worse. So if you were going to try to make complexity a bigger issue, you would change things every single day or multiple times a day. Agile development introduces complexity complexity introduces risk It's just sort of fundamental to how we've decided to approach application development rapid development.

lots of changes Break It Fast Fix it fast the problem is I don't care what you're investing in cybersecurity. If everything keeps changing every day or multiple times a day. You end up creating a problem that you can never catch up to?

and I do think you know some of the more critical pieces of applications, you know. critical infrastructure, for example, they've begun slowing things down a little bit because security is just too important to risk. Just to increase the speed of feature delivery.

In general I bet that pendulum swings back a little bit towards slower more careful releases. Until such a time as we can get the automation to the level to support it for real. All right, you heard it here unless everybody opens up their windows and starts screaming.

I'm not gonna take it anymore tomorrow. We're gonna have some serious issues coming forward. So hold on to your hat just being on the show.

Thank you. Boy. I feel so negative.

There's a lot of good. All right back to you guys in the studio.