 Hi, this is your subtle party and welcome to your front newsroom and today we have with us Nick miss three SVP and CISO at lineage Nick is great to have you on the show. Thank you. Thank you for having me today We are going to talk about CISOS open source software security roadmap But before we dive into this topic, I would love to know a bit about the companies and what do you folks do? What are you all about? Sure? No, absolutely. So lineage is a software supply chain security management platform we were we were born out of the Use case to be able to prevent and detect a software supply chain attack like a SolarWinds type of attack When we look at open source security How do you look at open source and security and then we'll talk about software supply chain site later But let's just just kind of build a baseline About open source and security a few things about open source is You know what we're seeing and this is true of all of our customers as well as what the industry is seeing is that approximately 80 to 90 percent of all software This is all production software is actually comprised of open source to begin with so many many people don't realize How much of their software is actually made up of open source components? So that's number one number two from a securing use of open source the the major challenge with securing open source is When you're grabbing an open source package, which is a software package from open source what's not well understood or well under under defined is What is inside that package most of the tools today security tools today will identify The first or second level set of software components that are inside open source what they're not giving Information about is the third level fourth level and oftentimes we've seen this go down about 20 levels deep So from a security perspective Understanding your entire inventory of software components is really the first step in terms of identifying all of your risk So I think you know from an open source perspective There are many dimensions from a security perspective is one just looking at Having an understanding of your full inventory and then from that perspective What are all the vulnerabilities or risks associated with that inventory of components and when it comes to Just you know keeping a tab on inventory I think the the best analogy can be with the you know auto mobile industry You know, you know vehicles, you know, there's so many components everything come from This breaks you or gears or transmission If you don't know what is the source of that material you won't even be able to fix it So similarly, especially when you're consuming open source, even if you're not consumers, there are so many libraries packages dependencies frameworks and And And it's just not like just one version. They're different version. They're different providers of the same software stack so talk a bit about How Companies understand this and if I'm not wrong a few years ago, the Biden's mission They also came up with the whole, you know, bill of materials as bombs, you know, software bill of materials So talk about the awareness that you see when you talk to your customers or you like you have to actually go and educate them or That a situation is that they do understand what they're asking you Hey, you know what? How do we track as bombs that there are a lot of open source technologies? There are a lot of you know profiting technology SPD x is there and a lot of other projects are there So so let's look at, you know, how much awareness is there? It's certainly, you know with the Biden administration's executive order Cessus focus on software bill of materials the awareness has has increased However, the opportunity for us really within the industry is twofold One is understanding what is a comprehensive software bill of materials as I mentioned previously, you know having visibility into the entire inventory of Software software components is actually a daunting task much of the security tooling available today Does not do that. They do not uncover all of the components and software They'll give you the first or second level and the reason for that is most of the tooling today will Actually ask the software either looking at a palm file or some other file for its directory of Components what we know within the industries. Those are almost always incomplete. They're not exhaustive to begin with that the second part of Software bill of materials and s-bombs is there is a Conception that pre-conception that this is a point in time and it's simply, you know Providing the s-bomb is a good starting point But I think it's important to note that it is a starting point the purpose of having the s-bomb is so that We can get visibility not only into all the components But then start identifying all of the risks associated with those components and equally important not just the listing of the components But how are those components integrated together? What are the dependencies between them because the context of which these components are used and Put together have a lot of relevance to the actual risk or inherent risk of your overarching Software so the bill of materials is really a great starting point to get a full inventory From there, it's how do we analyze that information to understand risk? Very very important point is that as visibility is good having an inventory is good, but Tracking all those changes tracking all those vulnerabilities can be daunting as well I just I think yesterday also there was a vulnerability in Linux the good thing with open source is that things get patched very quickly because The upstream projects is not their responsibility anyone in the ecosystem you folks can go and find a Patch it's up to the the users now vendors to actually Pull that patch pull those changes in so talk a bit about once again What is the next step, you know after s-bomb? Okay, you have the whole visibility inventories there But tracking all those changes and also ensuring that everything is up to date, you know I mean solar wind you get example so there's so many examples there where folks were leveraging open source technologies Patch was there, but they never implemented or deployed it So that's how do you look at that park? No, that's a very good question And we've we've actually worked and looked at this very deeply with many of our customers and one of the major roadblocks to Implementing the latest patches across all open sources this notion of compatibility What's happening is because your software is made up of many different pieces of open source different libraries and frameworks Upgrading one component could actually be a breaking change in your software So there's this constant trade-off we're seeing that software developers are making which is okay. Do I upgrade if I upgrade? What's the impact to my software will it break my software? Would that cause me to now Upgrade five other components 20 other components What's the compatibility between all of the different upgrades that I need to put in place? And so that that is a significant challenge to managing and maintaining All the upgrades and patches that are being released Um, and so one of the things that we look at is this compatibility analysis How do you decide what are the right set of upgrades and patches? That will not break your software but dramatically reduce risk and how do you look at all of this information? Again, sbom is a great starting point, but it's really how do you operationalize the sbom that is effective No, let's just talk about CISA the open source software security roadmap. I think the the CISA roadmap is a great Great, uh, it's gonna, you know, it's a great starting point. It lays out some very ambitious goals The ones that I believe are going to have a tremendous impact in industry One is this ability to share vulnerability data and share that effectively across the entire ecosystem Today, uh, we are getting as an industry better at identifying vulnerabilities and which components have what severity level of vulnerability So that's number one number two They've also have an outreach to the maintainers of open source to help these Open source ecosystems do a better job and understand where the vulnerabilities are Number three though, which I think is where we really help and come in is not all open source is well maintained today And it's not as easy as to say to developers Oh, choose an open source that is better maintained has a lower set of vulnerabilities versus another open source that You know is not as well maintained The challenge with that is there's you know, people have built software over the last 10 years Leveraging different types of open source And what we're finding is a vast about 50% of the software is not well maintained that most of all the most popular open source packages And so what do we do with those that are not well maintained? What we are able to do is work with our customers to identify risks identify Which software vulnerabilities can be upgraded based on well maintained open source providers? And those that are not well maintained This is where the tough decisions have to come in where you know, how do we do we create a fork or branch of our own If you do Then you're now responsible for maintaining that fork or branch Going forward or do we ultimately replace it or build it internally? Again, it's equivalent of you know building your own Version of that open source and now you're responsible for continual maintenance What we do is help you with that analysis in determining What is the right trade-off when is the right time to make those kinds of decisions based on understanding of risk understanding of compatibility And then secondly one of the things we're rolling out Is an AI model where can AI help in terms of making these decisions but equally important? How can AI help produce using some of the latest code generators to alleviate and solve Some of the branching and forking challenges When when it comes to that since you mentioned, you know some of the work that the US government is doing I want to draw a contrast with a similar initiative going on in Europe CRA or cyber resiliency act But that is causing a lot of problem because while the idea behind the act is great But it seems that it lacked some communication between actually open source communities and the lawmakers because they're putting a lot of owners on Software developers if I'm writing a small library, I don't know if my code is going to be used in the nuclear submarine So I should not be responsible for that. What are your thoughts on that? And if your folks are doing any work in that regard as well No, I mean, that's a very important consideration and I believe The the open source community is is a very broad Dynamic community and it ranges, right? You have like you have certain open source communities that Are much more active And then others that are not and to your point, we don't know how these packages will be used Putting the onus on open source communities. I don't believe is is ultimately going to bear fruit I think what we need to do and this is where we're focusing Are the software developers that are leveraging open source being able to analyze them understand their strengths weaknesses and risks So they can choose as well, you know, what to which open source components to pick which libraries which frameworks as well And that will then allow them to over time not only improve the risk that's in their software within the open source world Versus, you know expecting open source itself to to kind of, you know Have a certain level of rigor when part of the The value of open source is how quickly they innovate, right? They innovate quickly They put things out in the world and it's up to the developers to choose Harden them Secure them. So for whatever purpose they're being used for I think that's the right model And I think ultimately that is the the model that's going to succeed Because we don't want to stop the innovation that that we're deriving from open source today When we look at either the roadmap or we look at the overall Landscape of security in open source. Do you folks do any work any reports any studies to understand? The whole open source security and landscape if just can you just talk about it? We launched a report Looking at a broad set of open source packages. I think there was something like 114,000 Open source packages that we looked at and we analyzed all of these open source packages to identify some common patterns And what we can derive From from that analysis is as we talked about earlier, you know There are certain open source that are well maintained and actively maintained with Upgrades available and others that are not the the conclusion is about 55 percent of open source packages Actually have available fixes for the vulnerabilities in them. So that leaves a large percentage Of open source packages now these are the most, you know, we picked the most popular open source packages to analyze and um out of these packages We're seeing you know, uh almost 50 percent with no available fixes and many of these are in the critical and high severity ranges We also mentioned ai and of course, I mean we have been talking about ai for a long time But it kind of became boring and traditional legacy But we started talking about ai again after the whole chat gpt and generative ai Talk a bit about what does ai first of all? I'm not going into the whole can of worms of what does open source means in the terms of ai. This is very complicated It's not as simple as a lamp stack but what I do want to talk about is that impact of generative ai on security And like looking at ai helping security at the same time security helping ai because if you're running ai workloads You have to protect them as well or you can leverage ai to protect your workloads So so can you talk about generative ai ai from the perspective of open source and security? No, certainly and we we've had a lot of good discussions with our clients here on this topic One of the obvious concerns with using generative ai From a software development perspective is that we know there are malicious actors that are able to introduce You know malicious packages and frameworks Within the suggestions that these generative ai solutions are providing We've seen a few examples, you know with chat gpt Being compromised so that it's suggesting compromised components to use So that's number one and number two the other aspects of a potential risk is obviously You know tampering or poisoning of your data sets that come out with false Information, especially if you're using that in terms of generating software or generating You know potential security control configurations In order to address those, you know, it is really important that we leverage ai and its capabilities Effectively and what we're saying one one approach that we're taking is leveraging ai to identify risks Be able to perform the compatibility analysis that I talked about earlier It is pretty much a you know a massive combinatorics problem You're looking at thousands of potential fixes across thousands of components and compatibility across all of those So ai is very effective at producing You know what are optimal paths to resolving the greatest number of risks while not Introducing breaking changes that said Where we see the power of generative ai is now using this information To then make the decisions of let's say we want to fork as opposed to upgrading and when we do that fork Can we use generative ai to actually build the code for us and the answer we're seeing Through our work with our customers is absolutely. Yes. So but instead of simply saying To the generative ai I need a fork for this. It's a well informed Set of instructions to the generative ai on how to actually build that fork based on this other understanding Of compatibility of the risks, etc And that minimizes the ai being Compromised to produce a answer or a solution That the bad guys want you to use because it's following your precise instructions about your exact software All you know starting with this software bill of materials and we see a we see that as a lot a significant promise in how to use generative ai to solve and reduce risk But but using the information and from your perspective your context So you get the right outputs from from generative ai the other benefit of Of large language models and is the natural language interface One of the things that we launched has been extremely effective as you know Cyber security is it's a fairly complex field and as many great dashboards and widgets and everything else and reports Companies like like lineage produce We're never going to answer all the questions that people want answered Based on the data and understanding from a cyber perspective that we have So the natural language interface has been a really Nice addition to our product allows human beings to interact with their data set and get relevant information back In natural language, so you can ask okay. What are my greatest risk? Why is that risk so difficult the other benefit of this interface is when we provide recommendations on how to fix these components one of the things we found is that Developers are at varying levels of skill sets They also will have familiarity with one framework or one library or one code or language type And when we're remediating Open source they come in so many different varieties of frameworks libraries and languages And so what we're leveraging the large language model and the natural language interface is providing instructions to the developer on how to implement the fixes and if they get stuck or if they have questions they can just ask The ai bot. Okay. What do I do with this instruction? I don't and it'll guide them through and the beauty is that it'll guide them through in a natural language interface So I think I see the leveraging ai has a lot of different useful You know implement implementations in terms of helping us solve And address the cyber challenges with with open source and we're going to continue down that that path Talk about the realistic impact that you see will be there Either on public sector like federal agencies or private sector How is going to help and also do you feel that you know within like last few years The u.s. Government is doing the right thing right approach also the problem with the cra was the lack of communication I mean they do work closely, but I think like just two or three weeks ago There was a meeting at once again here at white house where linux foundation A lot of folks came there to discuss the whole open source and security where you feel that you know Actually us is in a way kind of leading the word when this comes to open source and security From what I've observed and we're also involved in the CISA has several Working groups within with the industry and the government Working together with regard to the software build materials with regard to identifying risks How do we communicate that how do we share this information? And what kind of requirements? You know it would be too burdensome or challenging For companies and so I do from my perspective at least I believe the u.s. Government is taking a very balanced approach They are not moving the goalposts with saying no we need to hold uh, you know the whole underlying premise here, which I think is a Shift and a good shift is holding software producers Accountable for their software and understanding the risks in their software And not shifting that risk to the users of their software Then I mean that that is the underlying premise that said they also recognize in working hand in hand with cisa This is not a change that's going to happen overnight, right? They are looking to work with the industry understanding This is a multi-year effort to ultimately be focused and partnering together on how do we drive risk out of our software uh, ultimately And what's the the recognition is any of our runtime? security controls as good as they are at preventing or detecting a potential attack The challenge is you're only as good as your software. So if your software is not built secure. So secure by design Yeah, you will be compromised. There'll be open opportunities for for compromise and and I believe that is the right focus I do believe they're going about it the right way It's a little bit of yes, we're pushing but we're also working with you so that it's not too onerous And it's a constant dialogue and I and I think that it isn't a Workshop at a time. It is literally weekly discussions Of how do we move this forward with constituents on all sides of the equation? And that means not only companies that produce and sell software to the government, but then also on the other side They include Software consumers so not only the consumers from a government perspective, but from large corporations If you think about it all of these Software vendors are both consumers of software as well as producers of software. So in a way they too are Help, you know helping influence How CISO rolls out the regulations and requirements because security is uh, as we were saying earlier Bad guys have to be right only once you have to be right, you know, hand it one time Security is not a product. It's a process It's also it's not just all the tools you need to have a culture as well They also say, you know what security is everybody's problem when something becomes everybody's problem is actually nobody's problem So I want to talk about the importance of culture and what advice do you have for these agencies or organizations? So they can build right cultures the right culture internally So that the tools that you provide they can actually take advantage of those tools Yeah, that's a great question and and one of the things that um, you know, I personally have been pretty engaged in with the government as well as on the Uh, you know the produce offer producer side and other developers of software Is you know, if I can frame take a few minutes and frame up where with the challenge right now So a lot of great work with with dev sec ops the icd pipelines a very mature Tool sets are there for the most part all the security testing is there What we are currently in though, right? And this is part of the challenge is we're now Overwhelming the software development community with vulnerabilities and we're identified Our ability to identify vulnerabilities has increased substantially, which is great, right? However, what is now causing is we have tools that because we shifted left or Are identifying Vulnerabilities and fixes and is causing a significant amount of contention With terms of resources and production. So now Developers are spending more than 50 percent of their time Addressing vulnerabilities and fixes the challenge with that is what we know from our analysis Is a vast majority of those fixes that are being reported Actually do not reduce risk and so now you're taking away precious developer time And these developers would rather be creating something new than patching a vulnerability But you're also taking away their time on Fixing things that do not result in substantial risk reduction because those Patches are out of context. They're not giving them the full context of their specific software The compatibility analysis how it's configured and all of the context information Is critical to how Uh a much risk reduction or prioritizing which things you fix and we also hear a lot within the current Discussion about how do we prioritize vulnerabilities? Right because why because we're we're facing this challenge We're overwhelmed with vulnerabilities developers are strapped. We want to produce helpful Features capabilities, but also reduced risk the challenge with the current discussion This is where we want to move it to the next level is that prioritization is is looking at things like Not only exploitability, which is good, but it's looking at things like reachability Is that is that component reachable? Of when it's executing Well, the challenge there is that the bad guys can still access that code They can whether it's dormant or active at runtime it can still be compromised and used as a vector so One of the things we're proposing and we're helping drive is kind of this it's almost shifting left of shift left is really looking at continuous sourcing and securing All of the third-party open source components that are coming in but doing so within the context of your entire software And so now you're focused on targeted fixes that minimize that actually reduce risk And optimize developer time in the process and I think that's the trade-off we need to make I think I think we've shifted You know, it's almost like a gut reaction. We have so many vulnerabilities. We need to go address them Yes, but now we've created this problem of there are too many vulnerabilities and developer efficiency And then then we switch over to the other side. Okay. There are too many vulnerabilities Let's just pick which which ones and prioritize which ones we believe Are the ones that are causing the most problems. That's that's good. But then that leads us to create frameworks of decision-making that may not be risk aligned And so what we're looking at, okay, we need to all come together Use all of this automated tooling. We have full visibility in the entire context of your software We have visibility into what you're sourcing. Let's bring that information together to Reduce risk but optimize developer time and efficiency and that real and make that real trade-off as a net benefit to both developers and and cyber security Nick Thank you so much for taking time out today Of course, it was great to learn more about lineage and also How folks can you know kind of secure their open source Of course the whole code base that you're running. Thanks for all those insights and I would love to chat with you again. Thank you Thank you very much. It was pleasure