Veracode’s State of Software Security 2024 with Chris Eng

This is Textron tv. Hi everyone. Welcome back here to Textron tv.

Um, I'm happy to have a good friend of mine back with us, uh, here to discuss the latest research from our friends at Veracode. He's Chris Ang. Chris is the Chief research Officer at Veracode, and has been for a long time.

I, I know Chris probably longer than either of us want to admit. Uh, Chris, welcome, welcome back. How are you, my friend?

I'm doing great. Thanks for having me. Good.

It's good to have you here. Um, so Chris, I, look, I think most of our audience is very familiar with Veracode. They're one of the pioneers in the AppSec market, and you know, and I, as I mentioned, you and I know each other back, I think from the at stake days through all the various iterations of Veracode and Yeah, corporate overlords and all that good stuff.

But in, in, in case, I don't know, maybe someone out here is new or they don't know Veracode, why don't you, how would you describe Veracode to them? Yeah, we're, we're a software security company and we're trying to, I mean, we help our customers with software security at every stage of the lifecycle. So everything from like the educational aspect for the developer through fixing, uh, detecting and fixing issues as you're coding to doing static dynamic and software composition scanning as you're getting rage, deploy, uh, penetration testing after that.

So everything you can think of sort of in the, in the SDLC, you know, we've always talked about integrating security at every stage, right? And so we're all about doing that in an automated way at scale. Um, and it's, and it's taken a long time to get there, but it's, uh, I think the industry is realizing that you can't just, you know, you can't just think about this later.

You've gotta integrate it at, at every possible stage. I get it. Absolutely.

And, and, and of course you're being very modest, but you know, Veracode is not just a software security company. You guys have really, uh, help set the trail, if you will, or cleared the trail or made the trail, especially around application security, AppSec and, and stuff like that. Um, and is going back, I guess, is Veracode been around 20 years?

Is that fair, Chris, around that? Not quite, but we're getting pretty close. It was, it was 2006.

Yeah, its gotta be, yeah. Yeah. Okay.

And yeah, I was Gonna gonna say 2005, something like that. It was The whole, yeah, the whole motivation, you know, for me coming over was like, I was sitting there doing pen, uh, penetration tests for customers, one off, you know, two weeks at a time. And, you know, that just doesn't scale.

Uh, and so when you start thinking about what does scale, how do you take, you know, the increasing amount of software that's being written by every company out there and, and scale that into a real program with process and tooling around it where you can, you know, test your software and, and, and make security testing, you know, as ingrained as quality testing or, or, or all the other things that you have to do to produce software. The only way to do that was to bring automation to it. And, uh, and, and the, the thing for us in 2006 was like, well, let's put it in the cloud.

Um, we didn't have that word yet, but, um, yeah, you know, it was, let's, let's put it in the cloud and, and get out of this, this mentality where you, you've gotta give people the, you know, the, the software to install and maintain and have computers for, and let's just, you know, let them upload stuff and we'll, we'll handle that part of it. And, and that was what's really allowed a lot of big programs to scale over the years. And then we get a lot of great data out of that, which is kind of, you know, how we ended up writing this, this report You Like the bi the byproduct of which is the state of software security report every year.

Right? Right. See a lot of that data, You see what's happening right across different industries, different languages.

Um, are things getting better or worse? Where are the concentrations of, of, you know, bad news and good news? And, um, you know, first 2010, we, we thought like, well, let's, let's put something out there for the industry.

The report had a, a data set of 1500 applications, which was, we're like, wow, 1500 applications. Like, that's huge. Uh, this year's report has a million.

Yeah. So just A little bit different, a little bit more scale, And you can learn so much by just like, number crunching that data and, you know, starting to, to, to ask some probing questions of like, what's happening out there. Of course, we do that hand in hand with, with, uh, our friends over at Entea who have the, you know, the data science, security data science background to be, to be able to really, um, to dig into some of the complicated things that we wanna do.

So it's, it's been a really cool journey, um, getting, getting to do this every year and, and having, like I said, an increasing amount of like, really rich application security data every year. No doubt about it. com, they could download That's right.

A Report, right? com/s oss, which stands for State of Software Security. I mean, you can get there from the front page also, but Yeah, they can read it.

Um, yeah, we released it actually, um, just a few days ago. Fantastic. Fresh off the prices.

Alright, so Chris, let, let's start with, you know, what are the big, what are the big insights from this year's report? So this year what we chose to focus on was security debt. Um, and you're hearing a lot about security debt lately, I think in, in, in conversations, just in terms of what's piling up, you know, and how difficult is it to kind of get on top of that, um, security debt as a concept?

I think I, I always like to compare it to, to credit card debt or, or any sort of financial debt, right? Where, um, if you accrue it and you don't pay it down, uh, it gets more expensive to fix later, right? You, you know, in in finance world, it's interest in, in, in software world, it's just sort of the complexity of software and the, you know, crusty old code and things like that.

Um, and technically I think, you know, anything that you, any flaw, um, or vulnerability that you know about in your software that you choose not to fix, once you know about it, that becomes security debt, right? You've decided to defer it. Um, for the purposes of this report, because we're doing calculations and whatnot, we're defining security debt as anything that you know about and haven't fixed for, um, at least a year.

So that's a pretty, like, that's a ample amount of time, right? So it's kind of fair to say, like, yeah, you've let it slide into, into debt at that time. And so what we find is security debt is all over the place.

It's endemic, it affects every application, uh, every industry, every language, um, size of application, size of company doesn't really matter. Um, and, and, and you, and you, you just kind of find, find it, um, everywhere. Um, and you find that 71% of organizations have security debt.

Um, about 45, close to half of that of organizations have what we call critical security debt, which is laws and vulnerabilities that are of a, you know, a high or critical severity that you've let slide past that time. So it, it's pretty bad. Companies are letting this pile up and, um, you know, over time that that really, really accumulates.

Sure. Um, you know, to me, security debt is like dark matter, right? It may make up 80% of the universe, but we can't see it, smell it, touch it, but we see its presence based upon like its gravitational pull right?

On regular matter or whatever. So, you know, in my mind, security debt has a similar kind of thing because it's there. We may choose to ignore it, and many organizations kind of bury their head in the sand around it, but nevertheless, the gravitational pull of it prevents us or slows us down from doing things that we know we need to do.

Right? And, and I think in the case of security debt, it's almost sort of a ticking time bomb too, though. 'cause sooner or later those chickens come home to roost as, as the saying goes, right?

And, and someone's gotta pay the price. Um, That's yeah, that's exactly right. Um, you don't, I mean, nobody, like most people would rather go and write a cool new feature, right?

Than go and, and fix some security issues. And on a day-to-day basis, you don't, you don't feel the security debt there unless, you know, unless you've got, you know, a security team pounding at your door or something. But, you know, you really feel it when there ends up being a large industry impacting event like, um, you know, like a heart fleet or a, a log for J or something along those lines.

And that's where the security debt really comes back to bite you. Because if you've allowed yourself to kind of get that far out of whack, like with a, with a, with an open source library, for example, if I'm up to date, if I'm only, you know, a month out of date and some big vulnerability comes out, it's actually very quick for me to just go patch that with the, with a fixed code, nothing's gonna break. It's a really easy fix.

If I'm five years outta date, imagine I, I can't just jump to the latest version, right? Right. I have to kind of go step by step, um, you know, go from five years outta date to four years outta date, take the next major version, make sure that nothing broke as a result, because I'm making such big changes to the code.

When you can make small changes at a more frequent basis, um, you know, you, you, you, you lower the chance that you're gonna break anything. And that applies to pretty much any security fix that you're gonna make. I think the longer that you let it go, and also if it's current, if it's recent in your memory, if you're working, if you just fix it when you find out about it, you're already working on that code, right?

As a developer, you don't have to go unearth it from some branch from a year ago and figure out what, what was I doing at that time and what, what does this code actually do? And kind of get back into that mindset. You're already working on it, but it's a, it's a muscle, right?

Yeah. And it is muscle memory. com about 10 years ago, right?

And look, the whole technical debt thing was, was a big issue that DevOps was helping to address, right? Is a lot of organizations just kind of tick the can down the road. Yeah.

And, and, and like you said, eventually it becomes such a big hurdle to get up to speed, to get up to par, that you just can't do it in one fell swoop. Now it takes time and more effort, and it, it, it's not that any one little thing is fatal, it's the totality of it, right? Yeah.

That really weighs in, you know, as I said, it's like dark matter. It starts, you know, it starts morphing and pulling and pulling at the, the, the, the fabric of your, of your stuff. Um, so what what's the answer here Though?

Yeah, there are, there are some things that, that can be done. Um, and one of the areas that we spent a little time investigating once we kinda looked at the, the nature of the debt and the volume of the debt is what are application teams actually, what kind of, what kind of effort are they actually putting against this? And so if you think about, for example, what's my average monthly fix rate?

Like if I have a hundred flaws in any, any given month, how many of those flaws am I actually fixing within that timeframe? Like, what is my capacity as a team? And so we've defined capacity in that way.

What's your, what percentage of the known vulnerabilities you have? Are you actually getting after month, over month? Obviously you want to be fixing faster than you're creating them, otherwise you, you get into more debt.

But what you find is that most teams are not dedicating a lot of capacity to this. Um, about two thirds of them are, are dedicating like 3% capacity. Um, I think, uh, if, uh, you know, there, there's, there's a, there's a, a chart in the, in the report that kind of shows what that looks like, but it's a small, it's like we're talking single digit percentages a lot of the times.

And so, okay, that's, I mean, not ideal from a security perspective, but you're balancing a lot of things, right? You're balancing new features. You're, you're balancing non-functional requirements, uh, other tech debt, right?

You o you, you're keeping, you're keeping your stack up to date. All these other things that you have to do at a software developer. So let's just say that your capacity is what it is.

Let's say you don't, you can't change that, even though that you, you can, but it's a business decision and it's a lot more complicated than that. So given the past capacity that you do have, are you as a team using that capacity in the best possible, most efficient way, right? Am I getting after the highest risk items, knocking those off at least?

And it turns out that largely, um, they are not, teams are not. So you would expect that you'd work on the most critical issues first, and once you kind of got through all those, you'd work on the, the medium severities and the lows. Um, but when you look at a plot of the, the sort of the lifetime of those types of issues, you, you find that they're all being addressed at roughly the same rate.

You see, there's a chart that has these lines and they overlap because, um, there does not seem to be a prioritization there. And so that's one thing that's, that's actually really easy to get after is, is prioritize the security work a little bit better. Um, because if you have only got a certain amount of time to work with, uh, you really should be spending on the things that present the most risk to the business.

Not, you know, what, you know, what you just feel like working on. Uh, and we can't really tell why it is that, that developers are choosing to fix the lower severity items first. Sometimes.

Um, I think, I think a lot of that just has to do with convenience. Um, I'll fix what's in front of me right now, uh, because it's there, which, you know, hard to fault that, or, or I'm gonna fix this because it's the most recent thing that popped up in a scan, so like, it's fresh and I'm just gonna go off that one. But in order to really get after this from a security perspective, you've gotta, you've gotta, you've gotta kinda level it up a little bit and be thinking about how does the overall bucket of flaws that I know about affect the risk posture and, and, and go at it in a more prioritized fashion.

The other thing you can do other than increasing capacity is, is just, um, um, getting better at, uh, at, at fixing the flaws themselves, right? If I can, for example, if I can learn how to fix a SQL injection problem in five minutes instead of 30 minutes, I'm just making those numbers up. It takes a little longer probably, but, um, then I've effectively increased my capacity, um, because now I can tackle six times more in the same amount of time.

And so getting better, whether that's through education, whether that's through sort of generative AI assisted type fixing, uh, oth any ways that we can make ourselves better at the task at hand, um, effectively increases our capacity, um, and allows us to chip away at more of the debt. So those, those are, so those are some things that teams can do. Absolutely.

Like any debt, whether it's credit card debt, technical debt, or, or security debt kicking the can down the road is just never a, a great solution. And, um, you know, it easy for me to say, and, you know, but when people find themselves in this state, it's kind of usually too late for that. But you gotta start somewhere and, and, you know, there's no better day than today.

Chris, beyond technical debt, I, excuse me, beyond security debt, what other kind of big, you know, highlights from the report this year? That that is the, that is the bulk of it. Because it's such a big, it's such a big problem.

And we, we slice the data a lot of different ways, um, and, and kind of look at what's happening, uh, and, and the factors that that, that, that affect that. Um, we do have another section, uh, a section at the end of the report that kind of follows on some open source research that we, that we did last time. We started looking at what's, what, what was on GitHub and some of the characteristics that we thought might, you know, uh, lead to more risk.

For example, this, this was last time. So we looked at repositories and how often they were updated or, um, how many developers were on them. Um, those, those types of things.

And we, we pushed a little bit more into that direction this year, asking questions like, how, how much risk, uh, do you get out of using open source when you know there's only a single developer? Or like, if you look at the percentage of applications in a particular language that are using code from a single developer, right? There's a lot of libraries out there that are very popular that have one maintainer.

And so what does, what does that risk look like when you think about that in, in, in, in terms of the organization, if, if they introduce a bug, if their account is taken over, if they decide to disband the project. Like those, those types of things. Um, and then we looked at open SSF, which I'm sure you, you probably come across it at some point, but just sort of industry, um, work to kind of do many things, but they have a, this notion of a score that they put on, um, open source libraries that looks at a, a number of different factors to gauge sort of how secure that library is.

And it's more about practices than vulnerability counting, right? It's are they using, um, are there signs of dangerous coding patterns? Do they use branch protection?

Are there, do they use code reviews? Do they use SaaS against all these things that you, it's kind of almost like a maturity model type thing, right? And so we looked at the scores of, uh, of open source libraries that they've assigned scores to, and then we've looked at open source libraries that we see actually in use in real, um, real world applications from our customer base.

And we actually saw that, um, the libraries that we saw in use tended to have on the higher side of open SSF scores. Now, I'm not saying that people are using the open SSF score to decide what they wanna use, um, but there does seem to be a correlation there that people are leaning towards the, the libraries that have better practices. Um, and so that was, that's sort of a good sign.

It was, we, this, there's a lot of data there, right? Um, but we wanted to, to kind of see what that was that was looking like. So there's a whole section there on open source, what that looks like in the ecosystem, how, you know, the, the, the, the influence that individual developers have and, uh, and stuff like that.

So, um, worth the read. But, um, yeah, our focus was really, let's get into the security debt discussion that nobody wants to have. And, um, and, and let's have it, and, and honestly, um, I saw, um, Ollie Whitehouse over at the, uh, at the, the uk, um, uh, uh, uh, I'm forgetting the acronym now, right?

But it's their, it's their cisa basically. Mm-Hmm. He was saying like, one of the top priorities for the year, as he's concerned is like getting the security debt, um, conversation happening and figure out ways to get after that because it's just this looming, this looming problem that comes back to bite us every time, you know, every time something big happens in the industry.

So it's a conversation needs to happen. Yep. I, and I think it's a topic that we are gonna see throughout the year.

I hope to see some of it maybe at RSA where I usually see you. I usually see you. Yeah.

Yeah. Hopefully we'll see you there. com.

I'm sure there'll be links off the front page. Yeah, you'll, you'll find it. Yep.

Hey, Chris, as always, thanks for coming on and, and talking it up and, and informing us, enlightening us. Best of luck and, uh, come back. Well, if I, if I don't talk to you before, I'll see you in May, but maybe before That sounds great.

Thanks for the chat. Always a good conversation. All right, Chris saying, chief Research officer at Veracode here on Text Drunk tv, we're gonna take a break.

I.