 Welcome everyone to theCUBE's presentation of the AWS Startup Showcase, Open Cloud Innovations. This is season two, episode one of the ongoing series and we're covering exciting and innovative startups from the AWS ecosystem. Today we're going to focus on the open source community. I'm your host Dave Vellante, and right now we're going to talk about open source security and mitigating risk in light of a recent discovery of a zero day flaw in log4j, a Java logging utility and a related White House executive order that points to the FTC pursuing companies that don't properly secure consumer data as a result of this vulnerability. And with me to discuss this critical issue and how to more broadly address software supply chain risk is Donald Fisher, who's the CEO of Tidelift. Thank you for coming on the program, Donald. Thanks for having me, excited to be here. Yeah, pleasure. So look, there's a lot of buzz. You open the news, you go to your favorite news site and you see this log4j, which is an app project, otherwise known as log4shell. It's this logging tool. My understanding is it's both ubiquitous and very easy to exploit. Maybe you could explain that in a little bit more detail in how do you think this vulnerability is going to affect things this year? Yeah, happy to dig in a little bit and orient around this. So just a little definitions to start with. So log4j is a very widely used source component. It's been around for quite a while. It's actually an amazing piece of technology. Log4j is used in practically every serious enterprise Java application over the last 10, going on 20 years. So it's, log4j itself is fantastic. The challenge that organizations have been facing relate to a specific security vulnerability that was discovered in log4j. And that has been given this sort of brand name as it happens these days. Folks may remember Heartbleed around the openness to sell vulnerability some years back. This one has been dubbed log4shell. And the reason why it was given that name, that is that this is a form of security vulnerability that actually allows attackers, if a system is found that hasn't been patched to remediate it, it allows hackers to get full control of a system of a server that has the software running on it or includes the log4j component. And that means that they can do anything. They can access private customer data on that system or really do anything into so-called shell level access. So that's the sort of definitions of what it is. The reason why it's important is in the small, this is an open door, right? If organizations haven't patched this, they need to respond to it. But one of the things that's kind of, I think important to recognize here is that this log4j is just one of literally thousands of independently created open source components that flow into the applications that almost every organization builds. And all of them, all software is gonna have security vulnerabilities. And so I think that log4j has been a catalyst for organizations to say, okay, we gotta solve this specific problem. We also have to think ahead about how is this all gonna work? If our software supply chain originates with independent creators across thousands of projects across the internet, how are we going to put a better plan in place to think ahead to the next log4j, log4shell style incident? And for sure, there will be more. Okay, so you see this incident as a catalyst to maybe more broadly thinking about how to secure the digital supply chain. Absolutely, yeah. This is proving a point that a variety of folks have been making for a number of years. Hey, we depend, I mean, honestly, these days more than 70% of most applications, most custom applications, are comprised of this third party open source code. Projects very similar in origin and governance to log4j. That's just reality. It's actually great. That's an amazing thing that the humans collaborating on the internet have caused to be possible that we have this rich commons of open source software to build with. But we also have to be practical about it and say, hey, how are we going to work together to make sure that that software as much as possible is vetted to ensure that it meets commercial standards, enterprise standards ahead of time. And then when the inevitable issues arise like this incident around the log4j library, that we have a great plan in place to respond to it and to close the door on vulnerabilities when they show up. Yeah, thank you for that. I mean, you know, when you listen to the high level narrative, it's easy to point fingers at organizations, hey, you're not doing enough. Now, of course, the US government has definitely made attempts to emphasize this and shore up and push people to shore up the software supply chain. They've released an executive order last May, but specifically, I mean, this is a complicated situation. So what steps should organizations really take to make sure that they don't fall prey to these future supply chain attacks, which you know, or as you pointed out, are inevitable? Yeah, I mean, it's a great point that you make that the US federal government has taken proactive steps starting last year, 2021 in the fallout of the SolarWinds breach, you know, about 12 months ago from the time that we're talking here. The US government actually was a bit ahead of the game, both in flagging the severity of this, you know, area of concern and also directing organizations on how to respond to it. So the, in May of 2021, the White House issued an executive order on cybersecurity and it directed federal agencies to undertake a whole bunch of new measures to ensure the security of different aspects of their technology and software supply chain specifically called out open source software as an area where they put, you know, hard requirements around federal agencies when they're acquiring technology. And one of the things that the federal government that the White House Cybersecurity Executive Order directed was that organizations need to start with creating a list of the third party open source that's flowing into their applications just to even have a table of contents, an index to start working with. And that's called a software bill of materials or SBOM is how some people pronounce that acronym. So the federal government basically requires federal agencies to now create an SBOM for their applications to demand a software bill of materials from vendors that are doing business with the government. And the strategy there has been to expressly use the purchasing power of the US government to level up industry as a whole. And create the necessary incentives for organizations to take this seriously. You know, I feel like the SolarWinds hack that you mentioned, of course, it was widely affected the government so we kind of woke them up. But I feel like it was almost like a stuck set stuck net moment, Donald, where very sophisticated. I mean, for the first time patches that we're supposed to be helping us protect. Now we have to be careful of them. And you mentioned the bill of material, bill of materials, we have to really inspect that. So let's get to what you guys do. How do you help organizations deal with this problem and secure their open source software supply chain? Yeah, absolutely happy to tell you about Tidelift and how we're looking to help. So the company, I co-founded the company with a couple of colleagues, all of whom are long-term open source folks. I've been working in around commercializing open source for the last 20 years at companies like Red Hat and a number of others, as have my co-founders. The opportunity that we saw is that, while there have been vendors for some of the traditional systems level open source components and stacks like Linux, of course, there's Red Hat and other vendors for Linux or for Kubernetes or for some of the databases, there's standalone companies. For these log for shell style projects, there just hasn't been a vendor for them. And part of it is there's a challenge to cover a really vast territory. A typical enterprise that we inspect has, upwards of 10,000 log for shell, log for J like components flowing into their application. So how do they get their hands around that challenge of managing that and ensuring it meets reasonable commercial standards? That's what Tidelift sets out to do. And we do it through a combination of two elements, both of which are fairly unique in the market. The first of those is a purpose built software solution that we've created that keeps track of the third party open source flowing into your applications, inserts itself into your DevSecOps tool chain, your developer tooling, your application development process. And you can kind of think of it as next to the point in your release process where you run your unit tests to ensure the business logic in the code that your team is writing is accurate and sort of passes tests. We do a inspection to look at the state of the third party open source, packages like Apache log project that are flowing into your application. So there's a software element to it that's a multi-tenant SaaS service. We're excited to be partnered with AWS. And one of the reasons why we're here in this venue, talking about how we are making that available jointly with AWS to joint customers deploying on AWS platforms. Now the other piece of our solution is really, really unique. And that's the set of relationships that Tidelift has built directly with these independent open source maintainers, the folks behind these open source packages that organizations rely on. And this is where we sort of had this idea somebody is making that software in the first place, right? And so would those folks be interested? Could we create a set of aligned incentives to encourage them to make sure that that software meets a bunch of enterprise standards in areas around security, like relating to the log for J vulnerability, but also other complicated parts of open source consumption like licensing and open source license accuracy and compatibility. And also maintenance, like is somebody looking after the software going forward? So just trying to basically invite open source creators to partner with us to level up their packages. Through those relationships, we get really, really clean, clear first party data from the folks who create and maintain the software. And we can flow that through the tools that I described so that end organizations can know that they're building with open source components that have been vetted to meet these standards. By the way, there's a really cool side effect of this business model, which is that we pay these open source maintainers to do this work with us. And so now we're creating a new income stream around what previously had been primarily a volunteer activity done for impact in this universe of open source software. We're helping these open source maintainers kind of go pro on an aspect of what they do around open source. And that means they can spend more time applying more process and tools and methodology to making that open source software even better. And that's good for our customers and it's good for everyone who relies on open source software, which is really everyone in society these days. That's interesting. I was going to ask you, what's their incentive other than doing the right thing? Can you give us an example of maybe an example of an open source maintainer that you're working with? Yeah, I mean, we're working with hundreds of open source maintainers and a few of the key open source foundations in different areas across JavaScript, Java, PHP, Ruby, Python, .NET, and like examples of categories of projects that we're working with just to be clear are things like web frameworks or parser libraries or logging libraries like log4j and all the other languages, right? Or time and date manipulation libraries. I mean, these are sort of the kind of core building blocks of applications. And individually, they may seem like maybe a minor thing, but when you multiply them across how many applications these get used in and log4j is a really, really clarifying case for folks to understand this, what can seemingly a small part of your overall application estate can have disproportionate impact on your operations, as we saw with many organizations that spend a weekend or a week or a large part of the holidays scrambling to patch and remediate this single vulnerability in one of those thousands of packages, in that case, log4j. Okay, got it. So you have this two-headed, two vectors. I'm going to call it your ecosystem. Your relationship with these open source maintainers is kind of a, that just didn't happen overnight. You had to develop those relationships and now you get first-party data. You monetize that with a software service that is purpose-built, the monitor, the probe that actually tracks that third-party activity. So, is that that right? Exactly, yeah, you got it, you got it. So, a lot of companies, Donald, I mean, this is, like I said before, it's a complicated situation. A lot of people don't have the skill sets to deal with this and so many companies just kind of stick their head in the sand and hope for the best. But that's not a great strategy. What are the implications for organizations if they don't really put the tools and processes into place to manage their open-source digital supply chain? Yeah, ignoring the problem is not a viable strategy anymore and it's just become increasingly clear as these big headline incidents have happened, like Heartbleed and SolarWinds and now this log-per-shell vulnerability. So, you can bet on that continuing into the future and organizations, I think, are realizing the ones that haven't gotten ahead of this problem are realizing this is a critical issue that they need to address. But they have help, right? The federal government, another action beyond that cybersecurity executive order that was directed at federal agencies early last year, just in the last week or so, the FTC, the US Federal Trade Commission has made a much more direct warning to private companies and industry saying that issues like this log-for-day vulnerability risk exposing private consumer data. That is one of the express mandates of the FTC is to avoid that. The FTC has said that this bears on both the Federal Trade Commission Act as well as the Graham-Leach-Bliley Act, which relates to consumer data privacy. And the FTC just came right out and cited the $700 million settlement that Equifax was subject to for their data breach that also related to an open source component, by the way, that had not been patched by Equifax. And they said the FTC intends to use its full legal authority to pursue companies that fail to take reasonable steps to protect consumer data from exposure as a result of log-for-day or similar known vulnerabilities in the future. So the FTC is saying, this is a critical issue for consumer privacy and consumer data. We are going to enforce against companies that do not take reasonable precautions. What are reasonable precautions? I think it's kind of a mosaic of solutions, but I'm glad to say Tidelift is contributing a really different and novel solution to the mix that we hope will help organizations contend with this and avoid that kind of enforcement action from FTC or other regulators. Well, and the good news is that you can tap tooling like Tidelift in the cloud as a service and much easier today than it was 10 or 15 years ago to resolve or at least begin to demonstrate that you're taking action against this problem. Absolutely. There's new challenges now moving into a world where we build on a foundation of independently created open source. We need new solutions and new ideas. And that's part of what we're showing up with from the Tidelift angle, but there's many other elements that are going to be necessary to provide the full solution around securing the open source supply chain going forward. Well, Donald Fisher of Tidelift, thanks so much for coming on theCUBE and best of luck to your organization. Thanks for the good work that you guys do. Thanks Dave, really appreciate your partnership on this getting the word out and yeah, thanks so much for today. All right, you're very welcome. And you are watching the AWS startup showcase open cloud innovations. Keep it right there. For more action on theCUBE, you're a leader in enterprise tech coverage.