Open Source Software Tracking with ReversingLabs’ Tomislav Pericin

This is Textron tv. Hey guys, thanks for the throw. We're here with Thomas l Perin is Chief Software architect for Reversing Labs, and we're talking about some new resources they're making available to discover what's going on with Open to Source software security.

Thomas la welcome to show. Hi, uh, happy to be here. Yeah, we are launching something pretty good for the community.

Uh, we have been working on this for quite a while now. Uh, so we are launching a website where any open source developer or anybody who's using open source code can just go and look at the overall health status of a software package. So if you're developing code in, uh, you know, JavaScript for MPM or Python for Pi, PI or Ruby for Ruby Jams, you can just go to our website, uh, look up any package before you include it in your project, uh, to make sure if it's, uh, well, first and foremost, is it malicious or not?

Uh, we've, uh, had a dramatic increase in software supply chain attacks in, in the open source space. Uh, there's been, you know, 1300% increase year over year, uh, as, as was kind of shown by our research that we published, uh, late last year. Uh, the trend is not slowing down.

So there's, uh, many, uh, malicious actors, uh, including nation states who are publishing, uh, malicious code, and we want developers to be as safe as possible. So the website itself gives you, uh, direct access to our original threat research. Uh, all of these packages being published and there's, you know, tens of thousands pretty much every single day, uh, go through our automated system, which detects malicious code.

And also, uh, our threat researchers are looking over open source and both reporting and helping take down all of these malicious packages. So, yeah, happy to announce that, uh, spectra your community is not alive. Is this kinda like a red light, green light scenario or are there different levels of risk that I might be willing to accept for different packages depending on what the actual vulnerabilities might be?

Correct, yeah. Uh, so we track six different categories of risk for every single package. Uh, we look at, you know, any license compliance issues, for example, any exposed secrets in those packages, uh, presence of known vulnerabilities, for example.

Uh, are the software packages hardened against, uh, exploitation of said vulnerabilities? Uh, is there any code tampering, like malicious code being present? And are there, is there any regular known, uh, pieces of malicious code as well?

Um, if you want to think about just, you know, binary yes or no, we do, I have that too. It's basically rather, or green. Uh, but, uh, there's nuances as well.

Certain types of risks you might not tolerate. Uh, for example, you know, exposed secrets or just used for testing, for example, might not be important. Uh, but presence of malicious code definitely is.

So if it's red because of that, uh, you definitely don't want to use it. It also seems like there's a lot of subtlety because different versions of a package have different vulnerabilities. And as a developer, I'm not really gonna track that.

At least there's no convenient place to understand that. 'cause I can find all kinds of versions of things in different repositories, right? Yeah.

So we are monitoring the official repository. So if you are using NPM and pipeline Ruby Jams, that's kind of the primary way you would be interacting, uh, with your software development environment, should be kind of pulling down packages, uh, from those as you're building code. And yes, they are version, there's many different versions, and often you don't know which one's the best one.

It's not always the latest one as well. So let's say you have an older version and you kind of have to stick by it because of some breaking code changes and whatnot, you still wanna keep an eye on the risk because if the risk increases over time, let's say there's a critical neo vulnerability being detected, right? Like a lock for J vulnerability, which, uh, you know, the community was talking about, uh, uh, like more than a year ago, I, I would say, uh, you wanna know, right?

So that's included now in your code base. You have to migrate to a version which patches that issue. Uh, so not necessarily always migrating to the latest and greatest, but keeping an eye on the risk is always prudent.

As we go along with all this, I'm sure developers are gonna look at this, but will a DevSecOps team also look at this page as kind of a way to validate what the developer may or may not have done? Yeah, absolutely. So if there are any issues, uh, what we do is we kind of recommend the upgrade path and say, okay, so this is the version you wanna migrate to.

Uh, DevOps, uh, in our experience is more than capable of creating pull requests and, you know, bumping diversions if, if set updates are actually required. Uh, so we have idea that, well, we kind of hope that many constituencies in the, uh, software development lifecycle will be able to get value, uh, from our website. So DevSecOps, application security folks, developers themselves, and even IT security folks as well.

Uh, sometimes it happens that, you know, threat detection systems, uh, detect malicious code, which is already installed on, on the server, and you want to get more information about it. So with this website, we're giving everybody a, a public resource they can reference and say, this exact version is a known malicious version. We have to, you know, file an incident, we have to migrate away from the version, we have to patch things.

And, you know, depending on what the malware threat is, you might wanna think about how you wanna structure your response as well. A lot of times people have older versions of applications or modules in their code or any, and they wanna upgrade that, but they're afraid because they think it might break. So how much insight could I get on this page in terms of how big an upgrade something might be?

'cause sometimes the DevOps team would just do it versus waiting for a developer. It just kind of depends on the level of, uh, lift. Yeah.

So if you have a mature process already, which says, I have CI/CD in place, and I have a set of, uh, tests or unit tests, or even end-to-end tests, uh, which can actually check for these things, it's pretty easy to just create a pull request and have that automatically tested for you. So if you have good test coverage, this is very safe. Uh, we don't right now, uh, offer, uh, the, uh, automatic notification of if anything's gonna break.

That's, that's very difficult, uh, to do in practice. And, uh, it depends really on which functionalities of set libraries you're using and how, uh, some package managers, uh, well, packet maintainers, uh, do follow pretty good versioning schemas. So if they use samware, for example, and they kind of stick by it, uh, so every breaking change will be then a major version.

You would be able to say that, you know, uh, with a little bit more confidence that the upgrade could break things. So it's kind of depending on from package to package. But if you have a good system in place, you should be able to go kind of use what we have, uh, without problems These days.

Of course, you can't walk down the street without somebody telling you about their great new AI thing. Um, can I apply AI to this process someday? And what might that look like?

Well, we're exploring those ideas. That's very interesting, uh, that you brought it up. We're trying to figure out if, uh, AI models are good enough to start recommending, uh, better versions of the package.

And even looking from, you know, migrating you from like, let's say an outdated package which is normal, no longer maintained to something which is fairly easy as to be used as like, like a drop in replacement or something. Uh, still in the early stages of that, uh, but, uh, hopefully soon enough, uh, we'll have a pretty, uh, good new announcement when it comes to, uh, integration of ai. Uh, I'm very hopeful because it seems to solve a lot of interesting problems in the space.

I wouldn't call it the panacea, which is gonna, you know, replace the developer and make all of these security issues redundant. Uh, but certainly as a tool it is very helpful. We've seen the Biden administration and the EU start talking about holding companies essentially more responsible for the software they deploy.

Are we moving towards a path now where essentially you're gonna be required to go fix this stuff versus kind of right now it feels like a gentle suggestion? Yeah, I, I, I think so. Yeah.

Um, and, and if you read about, you know, what US government is trying to do and all the different initiatives they have in place, you kind of see that the code process is there. Uh, getting software publishers to be responsible for a piece of code, uh, is, is ultimately where, where they're going. Uh, there's this new form, uh, currently in draft from, uh, office of, uh, budget management, uh, in the us which basically says you have to sign off on different things that you have a vulnerability management process that you're using best practices and more, most importantly, where our site can help as well, that you know where your components came from.

So if you're developing code in, uh, Python and Ruby Gen, Ruby and, uh, JavaScript, you can actually use our website to confirm that and say, yeah, this is the, uh, unmodified version of a piece of code that you can get from a, uh, official repository. And it has these issues and those issues we are comfortable with. We kind of know how they're gonna affect our application or not.

We can just might get to a better version as well if that's, if that's an option. We have seen issues with vulnerabilities that involve open source software that was basically being maintained by one or two people who really didn't have the resources to constantly updated and deal with all these security issues. So as part of your website, are you gonna look at, you know, what is the size of the community, how active it is, and how responsive it is as part of your, um, evaluation?

Well, yes, you have that, that those types of statistics, like how popular is a package, is part of our statistics. So if something is in like, let's say top a hundred, uh, packages, it has a more vibrant community and there's a, a list of, uh, releases, so you're gonna see the release cadence as well. Um, so the idea being, you know, the more frequent the updates, the more lively the community, uh, behind a piece of code.

Uh, however, I think we, uh, have to support the open source developers as well. Uh, there's a lot of burden and, uh, on, on, you know, developer shoulders. They're kind of doing this, uh, sometimes as as volunteers, there's, uh, little to no money involved in open source.

So these are mostly passion projects, and that's why we felt the need to try to help this community, uh, by, you know, helping them, uh, have a website which itemizes all the issues they could be working on as well and helping them prioritize as well. So if, if we do that right. Uh, and, and we have been talking to quite a few, uh, package maintainers already.

Uh, they seem to like the idea of transparency quite a bit, you know, and they see that as a badge of honor because there's a lot of people who actually do care about security a lot and, and they are always on top of patches and, you know, uh, migrating different issues and they want to kind of showcase that as well. And, and we've heard from people that they want to use our website to do that too. Like, if I am invested, I want other people to know that.

So to me, that's inspiring that a lot of people do care about security in, in a way we do too. I mean, as security professionals, A lot of the times the developer will have used, uh, some sort of open source component and then they move on, and the people maintaining the application don't always see what's in there or don't understand all the dependencies. So how do I get an understanding of what my dependencies are when a lot of the times they're initially, uh, invisible to me?

So how do I kind of work my way through that equation? Yeah, and that is a very difficult problem in open source, uh, specifically because not all the dependencies need to be declared, if you will. So even if you're kind of using your basic software composition analysis tools, and quite a few of them are actually made by open source community, you might be missing certain things as well, because these types of tools that typically just look at what's declared, not necessarily what's included.

And there's a very many number of ways how a developer can add a dependency without explicitly declaring it. Uh, our website, uh, shows the declared dependency, so we kind of know, but there's also, uh, an information about how many others are there in the package. And all of the vulnerabilities we actually, uh, display on our website do refer to others as well.

So you get a sense of, there's more to the story than just what's publicly visible or if I'm just using, you know, basic tools. So we feel like the information we've compiled is, is good enough for people to actually start identifying issues and focusing on starting to fix them. And the good part is you don't have to install it or anything like that.

As you're doing your normal software development and you're pushing packages out, our website automatically picks them up. You don't have to worry about integrations or whatever. You just do what you're supposed to be doing.

And, uh, the website kind of updates as soon as you push a new package and it tells you, oh, you remediated the issue. Congratulations. There's no more vulnerabilities.

Uh, you don't have any more exposed secrets under all the other types of risks As we kind of think this whole thing through a bit. Um, there's a lot of investment in software bill of materials, SBOs, and I get the concept, but I also understand that we're constantly updating code and application. So how do we make sure that the SBO is current with what's actually in the code that we are now updating sometimes daily?

Yeah. Well, you know, at, to me at least, ASBO is just the part of that story. It's a list of ingredients which may be complete or it may not be, depending on how you're actually generating it.

Uh, but there's many other types of risks embedded within the software package as well that the end user, uh, of your software product cares about. So knowing that you have, uh, you know, a component is great, but knowing that the component was vulnerable at the time of the release is, is a good piece of information for the end user. Uh, knowing that that, uh, component was compromised in the past or compromised now is also very important.

Uh, but when it comes to software bill materials, in an ideal case, you create them when you're creating the package, and, uh, theoretically that shouldn't change, but, uh, the devils in the details, all the tools which generate, uh, the, uh, the asbo might be missing things or, you know, your, your asbo might be complete. Uh, what is preferred really is that the publisher in this case can be as open source maintainer, publishes their own as bomb and says this is accurate. And then you have the consumer on the other end, which has an automated tool and can crosscheck and validate, and in case there's discrepancies, you can have a discussion.

Uh, not as much with the open source developers. As I said, they're not really, they're volunteers. I, I wouldn't burden them with, with bureaucracy and, you know, getting them to do even more, uh, if we can help by creating tools which are better and, you know, helping them identify and address issues.

I think that's the preferred way. There are companies who build their business to be completely honest on, on open source, and, you know, having those folks contribute back, uh, would, would go a long way. All right, folks.

Well, you heard it here. The devil is most certainly in the details, but there's a new website out there. Where can I find this website?

What's it called? Uh, it's called Secure Software. So you just go to that website, secure Do Software.

software. And uh, we like to say that the main is our mission statement. We, we wanna help people create and use secure code, so secure software.

Awesome. Thomas Stops, thanks for being on the show. Thank you.

Thanks much for, And back to you guys in the studio.