EP 278: The State of Open Source Security Vulnerabilities

com, Security Boulevard. You're listening to another DevOps chat. Joining us in this DevOps DevOps chat is Reese Parkins and Reese is a director of product at WhiteSource.

Reese, is that correct? That's right, Alan. Hi, welcome.

Thank you. And yes, good. Thank you.

So, Reese, our audience is pretty familiar with WhiteSource. We we work quite a bit with them. And of course, they are kind of become one of the bigger players and what's become known as the SCA or software, a composition analysis market.

And, you know, that's the fancy name. But, yeah, it's a lot about open source securing open source. Components.

Because sometimes when you say open source security, people think we're talking about. Security tools, which are open source. Yeah, that's true, yeah, right.

You know what I'm saying? Exactly. So, Reese, I don't know.

Maybe there are people who are. So you want to give a quick background on white sauce for maybe people who aren't familiar? Yeah, sure.

So, look. In general, the keywords are open source and security, like you said. But, you know, that costs a pretty, pretty wide net.

As already mentioned, the you know, the technical term, if you're into the kind of forest a Gartner approach is software composition analysis. You know, our our kind of tagline on our Web site, I actually really like it. And it says, Use open source freely and fearlessly.

And that's the way we try to distill it down because, you know, ultimately that's our goal. Obviously, there's massive benefits in using open source. There are some I wouldn't say downsides, but, you know, it's not a completely free lunch.

And so what we what we seek to do is to help our customers to, you know, to to use it freely and fearlessly, meaning that they don't have to hold back and they can realize all the benefits of open source and a view and avoid some of the, you know, the security pitfalls that are potentially there. Absolutely. Absolutely.

So recently, white sources recently. Published their annual report to state of open source security vulnerabilities. It's available for download on the wide search site yet or.

Well, yeah, that's right. Yeah, definitely. By the time anybody's listening now, it is available.

It's a 12 page PDAF. And yeah, it gives a summary of the both the state of affairs as well as we try to look into what has kind of changed. What's one of the trends.

Ok. So I guess you opened it with that. Talk to us.

What are the trends here we should be looking at? Ok, well, you know, the first you know, the headline number is really that the total and the growth. It's probably no surprise that 20, 19.

So a record number of reported vulnerabilities, an open source ballpark, it's around a 50 percent increase just short of it. So we're seeing five zero five zero. Yeah, compared to twenty eighteen.

So let's dig in on that. Is it because we're using more open source components so the pie is bigger, if you will? And so when we look at a bigger pie, of course, there's going to be the slices got bigger and the bigger pie.

Or is it? The you know, not the opposite, but another situation where we're just seeing more vulnerabilities per 1000 components or whatever. So the while the pie, maybe you've grown a little bit.

The the the slices have actually gotten much bigger or heavier. Yeah. You see what I'm saying?

Yeah. This is certainly an aspect of both. What we think it is is, is one of the things you said and one that you didn't mention.

So it is definitely the case. You know, the pie is getting bigger. There is more open source being produced than ever before.

It's not as much about how much pie we're eating, but how much pie we're making. Right. So there is more being more open source being put out than ever.

It means not just more packages, but packages are being released frequently as well. There's a lot of code added to it. So, number one, we've got the pie growing.

Number two is not as obvious, and that is that there are a lot more eyeballs on open source security. So it's more a matter of that. We are finding more problems.

Definitely more a case of that than we are creating more, you know, per thousand packages or something. It's really that we are getting better at detecting vulnerabilities. So in that sense, that's a positive spin on the fact that the number of vulnerabilities is going up.

Veracode.. Veracode.. You know, it's a positive spin.

But nevertheless, vulnerabilities have jumped up 50 percent in that. You know, it's hard. And, you know, there's a there's like a metaphor for that I like using about open source vulnerabilities because one of the kind of misconceptions about open source vulnerabilities is that they're all kind of like new, you know, and kind of like we both just mentioned then, like, oh, people are making more or we're finding more.

So it's the key point is that we're finding them, not necessarily when they're being made. So, you know, quite a lot of the ones that were found in twenty nineteen weren't necessarily created in twenty nineteen. It's just that those eyeballs and improved methods that we have in that sort of security research industry, that we are better at finding them now.

And the metaphor I use is that, you know, to to an open source user, when you find out that there is a vulnerability in you in one of your third party components, you know, it might feel like a flashbang grenade or something, but it is a lot closer to like an unexploded world war to bomb. I mean, these problems in the code can sometimes be sitting for many, many years. And then one day they are discovered not because then you, but because they were discovered.

And similarly, the first thing people need to do is to work out, you know, just how dangerous they are. Absolutely. You know, if so, I'm of a mixed, mixed mind set on these trees.

I've been in the vulnerability space since 2002. One of the companies I found, it's still secure. It came out with that vulnerability manager back then.

And I've seen you know, we've seen the pattern. Open source does present its own unique sort of circumstances. But quite frankly, that was always one of the.

Supposedly plus's of open sources that there were more eyes on the code. Yeah. That's why you inherently would be more secure.

And, of course, as open source use has blossomed. We found that, you know, inherently it's not more secure. It's not inherently less secure either.

Yeah. All right. I like that question because I have a hard opinion on that one.

So, you know, the first part is, you know, this this concept of eyeballs and I've said it myself already, in a way, it can be like a misunderstanding. You know, the original statement was, you know, with enough eyeballs, old bugs are shallow. And that kind of got translated into this idea that open source is inherently secure because as many eyeballs looking at it, the reality is there are many, many lines of open source code.

We have the total count of eyeballs that have looked at it is like two. So that is a misunderstanding. But the idea that open source is inherently more secure, it's close.

They're one of the product directors at GetUp! Recently said that open source is not more inherently secure, but it is inherently more secure both. And I think that's a really great way of putting it, because I like that.

Yeah. So when it's when it's all out there and as we improve the tools, it is inherently more secure a bowl. It's not that automatically we've got to work to get there.

Interesting. All right, let's let's look, kid. I think the other thing people have to also keep in mind when reading these reports and looking at open source components, it's this this is in some other company that's using open source or it doesn't only apply to small companies that are using open source.

All right. Ninety nine percent. And if I'm wrong about that number, tell me.

But, you know, 90 are high. 90 percent of all organizations use open source. Right.

I have included that for. That's the approximate figure. Yeah.

I mean, you could say number of projects that use it is low. But in terms of companies, it's around 99 percent because pretty much if you have a Web site, you're probably using some open source components in it. Yep.

So, you know, we we look. We look. Mean, the only reason to look with what came before is to help us look ahead.

Right. Right. And and those things are a little cloudy right now with all this Korona and Unkovic stuff.

But, you know, when we look at 20/20, Reese, what can we learn from from this report of twenty nineteen and what can we take with us going into the New Year? Yeah. So we're definitely seeing a really big change is a real step up in the research and reporting of vulnerabilities.

It's been a real shift and I think that the the data from like 2018, 2019, which we're looking at now and then from twenty nineteen to twenty twenty, I think we're going to see like some really interesting changes just because like we're looking a lot more. And in particular in the last twelve months we've seen a real realization of like automated security scanning. So, you know, there's a few, you know, companies in the space.

But for example, GitHub have done a great job with their security lab and what they call code jewel. And that lets security researchers, you know, look for, you know, a single type of mistake across like thousands and thousands of projects. So we're going to see a real ramp up of that.

To some extent, that could potentially be the low hanging fruit, but it's still good that these are getting caught and getting picked up. The other thing that we're seeing a trend in this also actually is another contributor to why the numbers are going up. Is that in the past?

You know, opensource, we haven't been the best as a as a community at, you know, correctly documenting and responsibly disclosing vulnerabilities when they created it. So this concept that, you know, you should inform the you know, the authors, owners or maintainers of code, you know, and give them 30 to 90 days to fix have the patches already available and then release them. That hasn't been how open source has rolled a lot.

That's partly because the people that might find them unfamiliar with that, you know. But this is getting much better. And I think that'll be one of the big changes you see in 2020 is will start to make a bit more sense of the chaos and see improved, kind of like formal reporting rates compared to previous years.

Absolutely. We say, you know, I'm going through the report a bit as as we're talking here. One of the things my one of my pet peeves with with open source news is.

We, as the report indicates, we've gotten better at finding open source vulnerabilities. We've gotten better at releasing new versions of open source components. That patch or fix vulnerabilities.

What we have gotten better at is stopping people from still using the old versions or even continuing to download these old versions of those components. Makes sense. Yeah.

Look, this is a great question. It's not covered in our report, but it's absolutely related. You know, so there is this pretty great company called CloudFlare.

I was going to say they're CDO and company, but they do many things. But they actually put out a blog post in January of this year that said people are not upgrading outdated packages. D.

S.. So a lot of people, when they use, you know, a library like React or low dash J. D, NJ.

Yes. And so people loaded off the CDL. But based on that, they have the ability to monitor what people use.

And they noticed that, you know, once, you know, aversion to dot two, dot one has reached a certain level of use. That level of use only gradually tapers off over years. Even when, you know, two three zero three zero zero zero zero are released.

And the conclusion of that is true, that people are not updating once newer versions are available, if they create a new Web site. They use the latest, but they don't go and update their old ones. D and Jesus references in each team pages.

S. as part of an effort to try to help people automate that process. Because, you know, if you if you're on outdated dependencies, it's pretty much guaranteed that you're going to get hit by vulnerabilities at some point.

Great. Great. So here, here's another one.

Why would I do this? Let me just throw the rest of my pet peeves around here. Go ahead.

Well, their abilities in open source. So let's discuss them. So the problem and this was a problem in 2002 and 2005, 10, 15 and 20 as well.

The problem is, is that. Quite frankly, we get desensitized and have a hard time prioritizing, especially as we've moved security left right into deficit. So oftentimes it may not even be a security person.

It's a developer or a DevOps team member who gets this long list of vulnerabilities, you know, and they may have like some CV. You know, a priority critical, you know, not high, critical, whatever. Yeah, but it may not even be something that is germane or applicable to this particular.

No application of what happened. And and so helping not only the security folks now, but we kind of help the DevOps in the developed people prioritize how to get the most bang for their buck. How to make these applications is sort secure as possible without.

Totally impacting. Time to release and so forth, because what we learned is if there's if we give them too many vulnerabilities to fix, that it jeopardizes releases and stuff. Yeah.

When the billions don't get fixed. Yeah. Yeah.

No, that's it's like another great question. We we've seen that a lot. As they increase, you know, the better the better.

We do our job site wide source, the more alerts people are getting and the potential for them to be desensitized. Now the secret to overcoming that Shinsei secret, the way to overcome that is by prioritization and triaging. And there's multiple ways that you can do it.

And, you know, ideally the tools you use, you know, automate that as much as possible. But like, for example, a lot of companies have internal tools. And if you've got, like, even a high or critical severity on an internal facing application that requires, you know, a malicious user, that's a really big difference compared to if that's, you know, on a public facing application.

So, first of all, just balancing between, you know, internal versus external facing, that's almost like a static role you can use. The next phase is differentiating between, you know, dependencies that are used in production versus dependencies that he used in development or as part of the build and release tool chain. It's very rare because remembering that when we talk about vulnerabilities, it's generally talking about a mistake.

You know, this is not a malicious act. We classify vulnerabilities and malicious, different. We may even break those out in future years.

So when you talk about vulnerabilities, which is in an oversight or a mistake, the chance that a mistake in the development or the testing dependencies you have would actually translate into an exploitable problem in production is pretty low. So that's a second way of kind of categorizing and triaging. And then the final way, and this is one of wide sources, secret sources, is we literally have a product code or a feature code prioritize.

And what that does is when it takes it, when a vulnerability is there, it analyzes your use of that dependency and essentially passes like a NIST passa and it determines whether it is possible to reach that vulnerable code or not. And what we found is that actually reduces down the number of what we call effective vulnerabilities. It reduces that down by 80 percent.

So even if you didn't have those first two steps of differentiating between public versus private and daviss non dev, you can on average reduced by about 80 percent. You know, what would otherwise could otherwise overwhelm developers? You know, it's it's a challenge.

Even 20 percent can be a lot. But the worst thing you can do is get your developers kind of desensitized to that. You want to make sure that when you when you ring the fire alarm that it's for a good reason.

Absolutely, absolutely. Reeses, I'd mentioned to you before we got started. We start talking about this stuff and boom, we're out of time that quickly and we are away from home, actually.

But it's all good. I thought we had a great conversation. Sounds like a great report.

Please, folks, if you're interested in this is something of interest to you. Go over to the white sauce site and download the report for yourself. It's a pretty you know, it's eleven or twelve pages.

It's you know, it's not heavy in text, lots of graphics and it's very readable. We put a lot of work into it to try to distill it down to the important points. Absolutely.

Highly, highly recommend making downloading this, adding it to your library. Hey, Reese, thanks for joining us. Keep up the great work over there.

White sauce. Thanks, Alan. Thanks for having me today.

All righty. Resarch is director of product White Sauce. com Security Boulevard.

You just listened to another DevOps chat.