Transcript
Hi Mike Matchett Small World Big Data and we are here just after RSAC 2025, catching up with a few more folks. We've got Lineaje here to talk about one of the latest and greatest things they're doing in the cybersecurity space, looking at your software supply chains and how do you secure those? Which was a hot topic. So just hang on. Hey, Nick, uh, it's been just a minute since we talked. How are you doing? I'm doing well. Mike, how are you doing? All right, so this world's moving pretty fast. Uh, you know, we we did something a couple months ago, uh, on looking at what Lineaje is doing in Lineaje with the software build materials and the software supply chain and trying to really secure that open source thing for folks. Uh, and we just had rsac, uh, you know, just a tremendous show, uh, on security. And, uh, we just wanted to catch up with you as well, uh, as to what's going on new here, supply chain was a big thing. Maybe just start by telling us what what what world are we talking about here? Software, Bill of materials and software. Supply chain. What is that about? Yeah. No. Absolutely. So when we're talking about software supply chain, software bill of materials, you know what we're seeing is about majority of the software is coming from open source. About 7,090% software is open source. So really looking at what are all the risks that are being brought in through the open source components software developers are using. And, you know, through our analysis, we find that about 95% of the risk in software is coming from the open source packages that they're they're bringing in. It's really easy today to put together open source packages. And this isn't even introducing the topic of vibe coding or having AI help us code software, because we understand that brings in even more risks as it as it makes up stuff. Right? Absolutely. Yeah. No, we're talking about, you know, your your everyday software development. Right. So, uh, as I mentioned, 95% of the risk comes from from open source is what we're finding. And that also about 56% of those risks actually can't be remediated by by your own development teams for a variety of reasons. It's probably even like the first problem is that people have no real clue as to how deep their open source dependency chains really go, right? Because. Because one package can include other packages which includes other packages. And so something like Log4j2 happens again. They just really aren't even going to be any better prepared for it normally than they were the first time. Yeah. No, absolutely. And I mean, based on our assessment from all the different customers that we work with, we're seeing some of these open source nested dependencies go down to almost 60 levels deep. Um, and issues and risks can live in any one of those different levels. And in fact, we know a lot of our, uh, the bad actors are taking advantage of that. Right. And taking advantage of that opaqueness in the supply chain. Right. And I wasn't just being facetious with that vibe coding. I did hear some stories of people saying, the AI coder told me to include these other packages, and those packages didn't even exist. They were made up. And then bad actors are figuring out the AI is recommending those bad packages and making those bad packages that are, you know, it's just kind of a crazy world. Uh. It is it is crazy. And actually, one of the things that we do as part of our solution is we. We check the source of every one of the open source, making sure that those packages are actually valid and good known sources and not, uh, you know, uh, a typo squatted or or worse. All right. So we are, you know, we just we did something with you just recently, but we've got a sort of a shift here, too. You guys are developing and moving as fast as the rest of the security world here. Uh, tell us a little bit about how you've evolved your thinking and your approach at Lineaje to now make, uh, this software supply chain security, uh, more. I don't say dynamic or more continuous. How would you describe it? Yeah. No, that's a great question. So one of the things we've been focusing on is how do we solve the challenges associated with software supply chain security and working with our customers. And obviously understanding what's in your supply chain is number one. Number two, understanding the risks. And we've done that. However, you know, we kept bumping into the question of how do I remediate this risk. And so we we moved to this path of all right we're going to provide you recommendations really targeted recommendations on what to do. And we discovered that our that our customers said, hey, this is great, but we still can't do it. Our developers are still challenged with making these fixes. And so we said, well, what's going on here? So we dug a little deeper, and some of the things we found out was when they make these recommended fixes, it breaks their software. Right. And it breaks their software for a variety of reasons. Software structures are extremely complex. And uncovering that it takes a lot of work. And so as we kept digging here, our goal is how do we get how do we solve this problem for our customers? Right. Can we do this? And so out of that whole exercise, really, we came up with three new innovations that that we've launched recently. The first one is called uh, Gold Open Source. So similar to, you know, in the old days when we had gold images, these are gold open source packages and container images that are pre-vetted free of vulnerabilities. We've taken we've done all the testing around it. So we know it's from an integrity standpoint. It's safe and we know all of its provenance and all its details. So now your developers can actually start with clean, if you will, open source or gold open source that is free of vulnerabilities as opposed to trying to patch it later. So that was number one. Um, in terms of the innovations that we launched, the second thing we realized is it's not so easy to, uh, update to a fixed version, if you will, of open source. There are many reasons, as I mentioned before, that's like compatibility reasons that will break your software. Sometimes it's the, you know, do you have the right skill set for the type of language or the package managers that that developers are using to make this happen? So, uh, the other two innovations that we focused on and have delivered is what we're calling, you know, kind of the self-healing concept where we will actually write in your source code, uh, create a branch right in your source code, all the fixes or all the remediation. That way your teams don't have to. We've done that heavy lifting for you using our AI capabilities. And then we do it also at the container level, because sometimes suffixes have to be at the container, not not necessarily in source code. And we're able to do that again through I make it compatible so it won't break your software. And we do this kind of as an offline parallel effort. So the development teams can actually test it, validate the software still works. And the remediations are are performed correctly. So it seems like there's a couple of ways to think about this. One is, you know, you're sticking your fingers in there and actually creating adding Band-Aids to the security risks that are in there. But another way is probably more more generous to say it makes it more self-healing, right? So some so someone's writing code and you're coming in and saying, well, there's some risks here. We'll just we will automatically, as you're saying, address those risks and lower those vulnerabilities so they don't have to. That was just something will come in and layer on from an automated perspective. Right. So that's kind of cool. Yeah. And that is correct. And also we know you know software is dynamic. It's not static. And so continuously monitoring the supply chain and software making these changes as, uh, as new risks emerge. Yeah. And I like the fact that you're, you're able to to do that at the source code level and also at the container and the container definition levels, because things can go bad at those levels. And I'm assuming as the bad guys get better at being bad, there's going to be some other things you're going to, you know, have to create and come up with too. But this looks to be like a really interesting way to, uh, create ongoing. What what would you call it? Transformations that I think you called it that, that just really address risk continuously. No, that's right, that's right. And leveraging AI so that we, you know, free up developers time so they can build new features and capabilities versus having to, you know, patch vulnerabilities all day. Yeah. Uh, and this is a good use of AI from my perspective, because it's something you, you, the experts are using your AI and doing all the great governance and monitoring and guardrails and stuff on your side. You're not embedding some AI piece into the customer's environment. That's that could go wrong or hallucinate or anything. Right? This is this is your your use of it. That's exactly right. And so we're we're basically building in the fixes, if you will, at source code and container. And we're not leveraging a JNI to write code. Right. We're actually using our expertise training the AI on how to how to implement the fixes. Right. Awesome, awesome. So, uh, I think that's all we really have time here to squeeze this into our RSA coverage. Uh, if someone wants to find out more about your unique, uh, self-healing approach to this, uh, securing the software bill of materials, the software supply chain. Nick, what would you have them do? Yeah, absolutely. You know, uh, go to our website lineaje.com and request a demo or send an email to sales@lineaje.com. Awesome. Thank you for being here again. And do come back around when you've got yet another take on this, because this is a fast evolving field. I'm sure there's going to be more news soon on every front, so take care. Nick. Thank you. Thank you very much, Mike.
