Code Scanning and Composition Analysis, Josh Jennings – SOOS

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

We're here with Josh Jennings. Who's chief engineer for Seuss? We're gonna be talking about open source software security Josh welcome.

Thanks. Mike. Great to be here.

this issue has been around forever, but it seems like it's getting a whole lot more attention these days and I think more folks are discovering the need for scanning and composition analysis tools as a result. But I don't know if everybody understands what makes one tool different from another and for that matter. Why is it so challenging to get people to use these things?

There's there's been a big shift in. In how open source software is used and so I think as we've as we've shifted to more package managers, which allow you to easily pull in open source components. It's been it's been really easy to pull in all this data and and obviously pull in all these components and build your software on them.

But tools haven't really kept up at least in my opinion. There's a lot of Legacy tools out there that are used to pull in you know to scan for for a whole dlls and jars and we really moved away from that to to Modern development practices, so Tools like Seuss allow you to expose your open source risk and look at those at those package managers. Look at all the data that you're pulling through them and and give you really great results based on how vulnerable your software is what your license risk is what your open source risk is A lot of developers will complain about false positives they get generated and they wind up chasing their tail a little bit.

So how do we kind of minimize that false positives are are definitely challenging. I think the again with a shift towards package managers and just better. Better version data coming through sources like the national vulnerability database we're able to match up.

with the actual vulnerable versions easier and it still does take some in some cases. It takes some manual review to determine whether You're you're still vulnerable. But but again, it's it's a lot.

There's a lot better data. Now it's easier to match up. What component is used where and and really narrow in on.

On which components are used? Developers will also complain about how long the scans take and I wonder if sometimes if there are their own worst enemies because it seems like they postpone the scan and then to the end of the week and then you got this massive amount of code that you're supposed to scan. So there are their best practices or ways of thinking about this differently.

Yeah. Absolutely. We recommend you scan with every commit and we've built our system to be incredibly fast and to be able to scan very quickly often, you know in in a minute or less.

Obviously, it depends on the size of the code base and whether you have a mono repo or what's a little micro services, but we really have designed our system so that you can scan with every command and if there's no changes to your manifest files, then then we can easily detect that and and we know that you know, there's no new vulnerabilities that's come in there's no new packages that have come in and so we can even Make that faster in many cases. So I would say there are tools out there that do not take a long time to commit they're incredibly easy to integrate like Zeus. We have lots of CI/CD Integrations.

It's really easy to get up and running within minutes. So there's no excuse to not be scanning your software every time you make a change. Do you think that there's a lot more conversation these days about SecOps in general but is that help in the case?

And does it matter how well the tool kind of integrates within those workflows? Because a lot of times you see people want to work within the CLI and they want to work within the CI/CD platform. So do different tools work better in some cases than others in that regard.

Yeah, I think absolutely there's a there's a lot of tools out there that will give you sort of a generic option to run them. You know, they'll give you some script arguments to run you can get those to work. As soon as we've really tailored to individual ci/cd systems.

We have an underlying, you know infrastructure to scan and to pick up on manifest files, but we've really tailored to individual CI/CD systems so that again you can get up and running very quickly within minutes and And there's there's obviously lots of different ways that people want to run this so you could run it locally you could you could run a script locally against your local development. Maybe you don't have a CI/CD system because you're a small shop. Absolutely you can do you can do that and we've really tried to tailor towards what your development practice is.

How smart can all this stuff get eventually we hear a lot about AI these days do you think AI will be applied to composition analysis and security vulnerability this guy bringing? What will it look like? Yeah.

Absolutely. You know, one of the things we actually are expecting to be issued a pattern here shortly or we have been issued and from the you spend all this for malicious software detection that will be running works really running it already in the application to detect instances where open source components are compromised and we've seen a lot of those recently. So that's one area that I absolutely see AI coming in obviously already happening and I think there are some others as well.

I think we'll see more in the space to get back to your sort of earlier question about how you detect usage Within. Of a certain vulnerable component within your code base. I think we'll see more along those lines as well.

Do you think that Enterprise it organizations need to do more to contribute to the security of the open source software? There's an argument. I mean the Linux guys, you know, they have hundreds of folks who look at this stuff, but there's a lot of smaller packages log for Jade comes to mind where it's just a handful of folks.

So do we need to kind of Marshall our resources as an industry and kind of figure out how we're gonna secure these open source packages more in a more cohesive and Collective approach. Yeah, I think that would be amazing and you know, obviously open sources has changed the way that we develop software and you know, we're for the most part using it for free. And so anytime that that companies can give back and and share some of their development resources to help maintain these open source packages a really is is fantastic and and should be happening more.

Um, and I think there needs to be more in this is something that suits has tried to do on the governance front as well. So so, you know as an organization how well-maintained a specific piece of Open Source software is you know, is there one person working on it maintaining it or you know, is there a decent size team and and looking at some of those other metrics that they really speak towards maintainability and code health, so Yes, we should do more as an industry and also people should be Thinking Beyond the vulnerabilities and sort of Beyond license issues into what the overall health of these open source components are I think a lot of organizations don't really have a method for doing that. So maybe we need some best practices in that regard because what I see is somebody will download a piece of code and now they've created a new branch of something and but they don't Send that Branch or that update back to be put part of the mainstream project or at least asked to be part of that.

And so now we wind up with all these kind of slightly branches half Forks kind of things. So, you know, is it really a process issue more than a technology issue at this day? yeah, I think absolutely you know, a lot of organizations have open source policies for contributing, you know, spending a specific amount of time and even you know, starting the outline some of those As some of those processes around if you if you maintain a make a change to to a piece of Open Source Code and and create a branch, you know, how you should follow through with that and and get that submitted, you know as a pull request to the maintainers.

So I think a lot of it as you said is process and and it's just something companies need to start to start to put in place. What do you think will be the ultimate relationship between devops teams and security teams going forward? Is it do they need to work more?

collaboratively together or is it just a matter of getting out of each other's way and kind of finding a way to reduce the friction while we make more secure code faster. I think there really is a need for more collaboration and I think a lot of that is through tools, you know getting that SEC Ops teams visibility into what's coming into the code base earlier is a great way to catch these things early and to you know to be able then before they go out into production. So I think again tools like suits do a great job of of doing that because we give you various teams views into what they would like to see as far as what's coming into the code base and being able to action on that.

So I think absolutely they'll they'll be more collaboration there needs to be more collaboration, but then they also do have their own areas of expertise. So, you know the SecOps teams. You know have have their pieces that they're running, you know looking at at production issues running external scans and you know, that's more on their side.

So it's sort of a mixture of both, but I do think there is and we've seen, you know a need for more collaboration there. So what's your best advice to folks right now as you kind of look at the landscape and there's more awareness of the issue, but how do I get started? What should I be doing?

And you know beyond just delivering the standard DevSecOps sermon. What's the thing that I should be doing tomorrow to move this ball for? Sure, you know run run something.

You need to be looking at your open source components at a minimum. You'll you know, almost every time. Someone goes and runs their first game, they'll find that they actually do have vulnerable components or out of date components if they're looking more deeply, you know, there's there's the whole licensing piece.

A lot of people are really surprised when they start digging into that that's sort of where I came up with the idea for Seuss originally, which was as part of an m&a process realizing. Oh, wow. We have a bunch of licenses that you know, maybe we shouldn't You know, we should be using that software.

So I think you know again run something and start to get this into your process and you know, just be aware of of the fact that there's a lot you can do and you should be doing and it's not as hard as as people think it is. Hey Josh. Thanks for being on the show.

Thanks, Mike. Appreciate it. All right, guys, you heard it here.

First do something make an effort because it's not going to solve itself on by itself for sure. guys back to you in the studio