Transcript
Hi, Mike Matchett with Small World Big Data. And we're here today talking, of course, about security and one of the main problems that people are having with securing their own apps and identifying all the problems with them is they tend to leverage a lot of different components, a lot of different, uh, open source. They leverage a lot of, uh, opaque projects. They dependency chains of those things can go down hundreds of layers in some cases. Uh, how do you ensure that when you're building something and putting out there on the internet and you're leveraging open source packages or even using Cots, that it's safe, that it's not introducing risk? Well, we've got Lineaje here today. We're going to talk a little bit about how you, uh, can secure your environment, particularly, uh, understand everything in your, in your dev supply chain. So hold on a second. Hey, Nick, welcome to our show. Hey, Mike. Thank you for having me. Uh, before we before we dive into Lineaje, which, you know, kind of gives it away a little bit of what we're going to be talking about. Uh, you're the CSO for Lineaje. Tell us a little bit about how you became a CSO and how you got to looking at open source code this way. What what drew you into this end of the market? Yeah. No. Absolutely. You know, prior to joining Lineaje, I worked within the CSO organizations of several large companies. Um, and, you know, managed, uh, vulnerability management, cloud security, application security. Uh, ran the, you know, full automation of DevSecOps, CI, CD pipelines, testing and then also shifting left security champions, you name it. Right. I was really driving kind of the forefront of automation around security and application security in particular. However, I couldn't get away from the feeling that even with all of this advancement and technology, we were still playing whack a mole with a lot of security vulnerabilities. And then log for J happen or log for shell. And that really kind of broke my back. Right. And I and I after that incident, um, I spent about six months just really researching what was in our software, what was going on in open source, why was it so hard to find, you know, where Log4j2 existed and then remediate it? Um, and that started my journey here into the open source world and really diving into the challenges and risks of open source and then, you know, had the opportunity to meet with the co-founder and CEO of Lineaje. And, uh, you know, we worked together on building the concept out further. And six months after we started talking, I joined Lineaje. Right. For those who are maybe not as familiar with history Log4j2 open source package for logging. It was in everything, right? It's in everything. Everybody just says, I'm not going to rewrite that. I'm just going to import that and bring it bring it in. Uh, but that's not even really the extent of the problem, because it's in everything. That's in everything. That's in everything. Right? It's, it's it's it's baked in at many levels of that dependency chain of any of any open source package. And how many levels deep do you need to go to really find all the instances of? It is a question. People who do open source development probably don't even know how many packages are including the same stuff going way down and down and down, do they? Yeah, no, that's absolutely correct. And, uh, we call these nested dependencies. And as you said, we can see sometimes hundreds of layers of nested dependencies, uh, which are typically opaque. Right. And one of the key tenets of security is having an accurate inventory of everything you have. So really starting to understand that. And one of the things that we found is that it's incredibly hard to actually find the entire Lineaje, if you will like the Lineaje of your company, of your software, as the name of the of the company is incredibly hard. And so, you know, we started there. We started with what we call crawlers, similar to how Google crawls the web and indexes it. We crawl open source and learn everything we can about open source packages, as well as making sure we have the full dependency tree or Lineaje of that software. Yeah. And lest anybody like, forget this aspect as well. You know, when you use something like Log4j2 in your open source, uh, software and it's using it, it's not necessarily using a single version down throughout the whole thing. There's multiple versions and multiple places, even with the one application. Uh, and so you're also having to track the different versions and to do that and it becomes very complex very quickly to find, uh, even find a vulnerability and then to know what to do to fix it. So let's, let's dive a little bit into into Lineaje. Uh, you when you go to look at an open source package, um, for somebody, uh, what is What's the first thing you really need to do? Yeah, no, that's a good question. So the first thing we do is when we let's say there's open source package A in your software, we will then go scan the source code of open source package A. So let's say it lives somewhere in open source on a repo somewhere. We'll actually scan that source code. We'll also capture all the metadata around that package. You know who's contributing. What's the contributor frequency. Uh, how well maintained is it? Age of all the components. And then we scan the actual source code for risk. So we identify about 170 different dimensions of risk. And then we have a unique fingerprinting technology which looks at not only, you know, creating uh signatures, but we also look at vector based analysis so that we know that every component in that software is what it says it is, and it comes from a good known and valid source. And we do this not only looking at source code, but we also look at what is produced at the. As a package. Right. So sometimes a package is a binary artifact. And a lot of times what we've seen is the bad guys are putting in a change in the build. So between the source code and the actual package that's built, they'll, they'll insert something that ends up in the package but not readily viewable in the source code. And so we're doing all of that analysis. And then we're actually executing the software. Uh, so we understand not only its behaviors but you know, all of these open source components make calls to other open source components. That nested problem you're saying, right. Exactly. And being able to identify which calls are making and how they're making is really also part of the risk analysis. And so we're doing that as well. And then once we identify all of its dependencies let's say a1, a2 we will go to A1, crawl it, do that whole process again and do it for its dependencies until we exhaust the entire supply chain. I mean, that's like, you know, web crawling. It's a very recursive, but you don't know where the end necessarily is going to end up, right? You could be pretty, you know, pretty far down, uh, but someone's got to do it. You gotta, you gotta, you gotta you gotta trace that. Um, it's interesting that you partially execute the packages, too, because I think a lot of people might say, well, we'll fingerprint the source code, maybe we'll fingerprint the binaries, and then we'll say, like, we'll let you authenticate when you download something, the binary fingerprint, you know, you can do that with a bunch of tools. Uh, but to actually to actually understand that there might be a difference between those uh, is is pretty cool. Um, you mentioned you mentioned risk dimensions. What are what are some of the what are some of the interesting dimensions of risk, um, that would make having to do something take, take action on it. What would make it would say, hey, this risk is too much. I have to be I have to do something. No. Absolutely. So obviously vulnerabilities and known vulnerabilities is the first place, right. And everybody's focused on that. The second is looking at uh, the code quality itself. So are there other, other, uh, exploitable risks that are not CVEs or known vulnerabilities, but somebody could use to exploit in that open source to compromise your software. So we look at the code quality. We look for, you know, are there unsigned binaries in the code. We also look at age of components. So maybe your open source package is up to date. But its dependencies are very old. They're not using the latest versions. Those are other things that would also indicate risk of the overall package. And so we're really looking at all of these pieces. The other thing that we look at is is it well maintained. Right. And not only how well is it maintained as a package, but also all of its dependencies. How well are all the dependencies maintained? Um, and then look for potential risks that way. And then we, we aggregate or create a composite score of, let's say the reputation, if you will, of that open source. Uh, yeah. So so there is, you know, obviously all the details you can end up with pages and pages of stuff. Is there any way to get a higher level view of what's going on? Uh, to sort of summarize that? Yeah, absolutely. And so one of the things that we developed was a software supply chain risk profile, which is basically a graph, the x axis of the graph. If you look at like a grid, the x axis of the graph is what we call inherent risk. So those are things that are inherently risky in the code itself and the software itself. Vulnerabilities. We talked about the age. We also talked about code quality. Those types of things are, you know, that we're graphing out on the x axis. The y axis looks at integrity risk. So what we're doing with integrity is making sure every component that's there, uh, is a good is from a good known source. And what it has matches that good known source. And we're looking for any evidence of tamper. So again we talked about matching the what was in source to what's in the package binary and so forth, and making sure there aren't any changes between those that may lead to some type of evidence of tamper risk. So we do both integrity and then inherent risk. So that's a nice a nice high level view. Now say we identify some things that should be fixed. And and it's there's a lot of tools out there that might get to some list of things and prioritize the list and say, hey, these are the bigger security vulnerabilities at least once. Here's your punch list, go to work, and there's a thousand things on the list. Um, can you do better than that? I know, I know, you've got some some planning tools in there. Uh, how do you help someone really balance the idea of of of maintaining everything as current as it possibly can versus the idea of introducing new problems and breaking the software they already have? Uh, it you have to. I mean, you know what I'm saying? You have to balance that stability of the application versus the vulnerability, that application. How do you help someone do that? No, absolutely. And that's a great question. Um, you know, it's been actually a journey for us to get here. When we first started, we would provide, you know, all of these information and risks and vulnerabilities. And our customers said, this is great, but I really don't know what to do with all of this. And then we move to okay, let's give you some recommendations. Then our customers like oh this is great, but our developers actually can't implement these. And then we spent some time really digging in like why is it so challenging. And and we learned a lot of things. And then we created from we developed an AI set of AI capabilities to produce what we call plans fixed plans. And really there's categorized in three different types of plans. The first plan is what we call the compatible plan. And what we're doing with compatible plans is we're looking at all the vulnerabilities. We're looking at your entire stack. So everything from the OS all the way to the application layer and identifying fixes that will not break your software. What we found is what was challenging for many of our customers was, you know, adopting or using the latest version of something ended up breaking their software and they actually didn't know why, right? And they would spend a lot of cycles, uh, trying to fix it, but instead. Uh, they would just abandon that fix because it was just so hard. Uh, based on all the other issues that it caused. So the compatible plan really looks at all of your vulnerabilities, looks at your entire stack, and proposes, uh, changes or upgrades. Let's say you have a vulnerability, uh, open source package, version ten is the latest version and remediates those vulnerabilities. However, version 10th May break your software and also may introduce new vulnerabilities you were not aware of. So our compatible plan basically looks at what's the best set of changes, removing the most vulnerabilities without breaking your software or introducing new vulnerabilities. So we could, you know, what we will do is say, okay, version eight might be better. It remediates the vulnerabilities and it doesn't break your software. Go with version eight. Now we do this for the whole stack. So we're giving you all of these compatible fixes in one plan. So you so you could have maybe 1020 of those. Now you can deal with all 20 fixes in one fell swoop, if you will, because you know it won't break your software. The second plan. You say what? What if there is no compatible fix? Yeah. Yeah. No, that's a good question. So often what we'll find is we'll create what we call a minor plan, which is beyond the compatible plan, which basically says, look, there are fixes available for these vulnerabilities. However, we know there's conflicts, meaning that if you deploy it, it will break your software. Um, and basically what we do there is we identify where the conflicts are, we identify the fixes, and we give developer instructions integrated into JIRA so they know how to handle, uh, these, uh, these what I would say incompatible fixes. Right. Instead of simply discovering that during testing and breaking your software and having to rewrite it, write it, we actually give all of that upfront. So now you can plan for building these fixes that require, you know, developers to act upon. All right, Nick. There's still a problem here. What if that open source package is old and obsolete or not being maintained anymore? Yeah. Are you recommending. How can someone even address that? No. And that's a great question. So what we're finding is there are a significant number of open source packages that are not maintained or not well maintained, and they are vulnerable. And the likelihood of them producing a fix for them is pretty low. In those instances, what we will do is we will fork branch, fix that open source package and contribute it back to you as a fixed version, and we will maintain it on behalf of our customers. So really, by between the compatible plan, what we call that, you know, minor plan and and and fixing and forking and fixing unfixed vulnerabilities, we are getting to zero 100% zero vulnerabilities for our customers in this way. All right. So you'll you'll even fix the open source package in some way. Create that. Right. Um, and, uh, you know, I mean, are you are you are you good guys? Are you passing back those fixes to the rest of the open source community, or are you keeping those for your clients only? So absolutely, we we pass those back to the open source community. Um, you know, where they'll accept it. And a lot of times, as you mentioned, you know, one of the challenges with open source is that it's not well maintained. There isn't a right ecosystem. So in those situations, right, we will provide it to our customers directly, um, as well. Uh, so that's how we deal it. But our goal is to, you know, improve the entire ecosystem. All right. So to give back, uh, now, if someone does this, you get to zero vulnerabilities. And you said you had some graphs before. Is this is this something somebody can use to certify compliance and and use in their other, uh, regulatory kinds of kinds of things where they have to prove that they're, you know, go back to their own CISOs or their own board and say, you know, we've covered the angles on this. No. Absolutely. So, you know, what we call continuous compliance is pretty important. Right. And so we built what we call compliance packs into the solution. So we can provide all the evidence and artifacts necessary to say you are compliant, you know, with the right specs, including, you know, the vulnerability remediation. So that's all built into the software. Again, the goal is to get you end to end everything from understanding all the risks, how what kinds of risks, remediating them, and then being able to certify that it is remediated. Right. And I guess I guess we'll just sort of kind of getting towards wrapping up. But if you could just give me an example of, of, of someone who's used this and you can talk generically if you'd like, but just, you know, what, what is it that they're saving in hard dollars? And obviously obviously if you get to zero risk, you're saving all your risk. But, uh, how does this help someone, you know, justify investing in it. No, that's a great question. So I can give you an example for one of our customers. Um, we had cited an external research report, and it kind of lined up to what they were seeing is on average, large enterprises are spending about $28,000 a year in developer time in, in remediating vulnerabilities. Uh, through us, that amount of time almost dropped to zero because of the compatible plan. They didn't have to do any actions. The incompatible were so were drastically reduced. They can plan for them. So that was like almost a 40% efficiency gain. Then obviously the fixing the unfixed vulnerabilities that mean that you can't even measure because they would not have been able to fix it before. But but that's not only the cost savings there. We found a tremendous amount of cost savings because the traditional Appsec team no longer had to do all of the analysis and prioritization, and also determining contextual factors in the back and forth between Appsec and the dev teams that typically go on and on and negotiating. You know what's a priority? What's not a priority? All of that. You know, usually took at least in this one customer example, uh, for a set of, you know, critical high vulnerabilities usually took about six months really to hash out, right? Because it's pretty complex to do the fixes with our solution. They were able to do it in about a week. So it was a dramatic savings not only in time, effort and resources, but then achieving results, uh, happened in a much shortened cycle. You know, this reminds me of like, you know, we talk a lot about zero trust on this channel. We've talked about it with lots of companies, but now we're going to introduce a new term, zero defects. Right. And so like if you can actually get to zero defects and it's a believable, achievable goal, that would be to me as important or even more important than zero trust in a lot of ways like you close off this whole other avenue, like the back wall of the building is now also secure, right? It's not just the front doors. It's it's it's the walls are secure and tight. Um, if someone, uh. Nick, I wants to find out more about what Lineaje does, or maybe how it could help them in their environment. Uh, you know, someplace special on your website or anything. What would you point them to? No, absolutely. You know, obviously Lineaje.com. We have plenty of information on our website. Um, and there's a there's a button there to say, you know, set up a demo or a free consultation and we'll set one up very quickly. And the good news is, you know, we can do this with your own software, and you can see the risks and how we can remediate it. Uh, you know, within, you know, minutes, if you will, of integrating. Or you can send an email to, uh, sales@lineaje.com as well. All right. And check that out. So folks you know zero defects. It's going to be the next big thing after zero trust. You got to also batten down the hatches on your own software. Uh, check out Lineaje. Thank you, Nick, for being here today. Thank you Mike. Appreciate it. Take care folks. See you next time.
