>>Welcome everyone to the cubes 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 log for J 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 Don Fisher. Who's the CEO of tide lift. 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, you know, a log for J this is an, a project otherwise known as logged for shell. It's this logging tool. My understanding is it's, it's both ubiquitous and very easy to exploit. Maybe you could explain that in a little bit more detail. And how do you think this vulnerability is going to affect things this year? >>Yeah, happy to, happy to dig in a little bit in orient around this. So, you know, just a little definitions to start with. So log for J is a very widely used course component that's been around for quite a while. It's actually an amazing piece of technology log for J is used in practically every serious enterprise Java application over the last 10 going on 20 years. So it's, you know, log for J itself is fantastic. The challenge that organization organizations have been facing relate to a specific security vulnerability that was discovered in log for J and that has been given this sort of brand's name as it happens these days. Folks may remember Heartbleed around the openness to sell vulnerability some years back. This one has been dubbed logged for shell. And the reason why it was given that name is that this is a form of security vulnerability that actually allows attackers. >>You know, if a system is found that hasn't been patched to remediate it, it allows hackers to get full control of a, of a system of a server that has the software running on it, or includes this log for J component. And that means that they can do anything. They can access, you know, private customer data on that system, or really do anything and so-called shell level access. So, you know, that's the sort of definitions of what it is, but the reason why it's important is in the, in the small, you know, this is a open door, right? It's a, if, if organizations haven't patched this, they need to respond to it. But one of the things that's kind of, you know, I think important to recognize here is that this log for J is just one of literally thousands of independently created open source components that flow into the applications that almost every organization built and all of them all software is going to have security vulnerabilities. And so I think that log for J is, has been a catalyst for organizations to say, okay, we've got to solve this specific problem, but we all 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 log for J log for shell 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, the digital supply chain. >>Absolutely. Yeah, it's a, this is proving a point that, you know, 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. Project's very similar in origin and governance to log for J 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 comments 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 log for J library, that we have a great plan in place to respond to it and to, you know, close the close the door on vulnerabilities when they, when they show up. >>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 U S government has definitely made attempts to emphasize this and, and shore up in, in, in, in, in push people to shore up the software supply chain, they've released an executive order last may, but, but specifically, I mean, it's just 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, are, as you pointed out are inevitable. >>Yeah. I mean, it's, 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 solar winds breach, you know, about 12 months ago from the time that we're talking, talking here, the U S 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, 2021, the white house issued an executive order on cybersecurity and it S 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 that even have a table of contents or an index to start working with. And that's, that's called a, a software bill of materials or S bomb is how some people pronounce that acronym. So th the federal government basically requires federal agencies to now create Nessbaum 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, to take this seriously. >>You know, I, I feel like the solar winds 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 Stuxnet moment. Donald were very sophisticated. I mean, for the first time patches that were supposed to be helping us protect, now we have to be careful with them. And you mentioned the, the bill of its software, bill of materials. We have to really inspect that. And 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, about tide lift and, and how we're looking to help. So, you know, the company, I co-founded the company with a couple of colleagues, all of whom are long-term open source folks. You know, I've been working in around commercializing open source for the last 20 years that companies like red hat and, and a number of others as have my co-founders the opportunity that we saw is that, you know, while there have been vendors for some of the traditional systems level, open source components and stacks like Linux, you know, of course there's red hat and other vendors for Linux, or for Kubernetes, or for some of the databases, you know, there's standalone companies for these logs, 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, you know, upwards of 10,000 log for shell log for J like components flowing into their application. >>So how do they get a hand around their hands around that challenge of managing that and ensuring it needs, you know, reasonable commercial standards. That's what tide lifts 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 test 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 for J that are flowing into your, into your application. >>So there's a software element to it. That's a multi-tenant SAS service. We're excited to be partnered with, 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, to drink customers deploying on AWS platforms. Now, the other piece of the, of our solution is really, really unique. And that's the set of relationships that Tyler has built directly with these independent open source maintainers, the folks behind these open source packages that organizations rely on. And, you know, this is where we sort of have 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 and areas around security, like, you know, 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 if 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, 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 GoPro 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, of maybe a example of an open source maintainer that you're working with? >>Yeah. I mean, w 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, you know, like examples of categories of projects that we're working with, just to be clear, are things like, you know, web frameworks or parser libraries or logging libraries, like a, you know, log for J and all the other languages, right? Or, you know, time and date manipulation libraries. I mean, they, these are sort of the, you know, kind of core building blocks of applications and individually, they, you know, they may seem like, you know, maybe a minor, a minor thing, but when you multiply them across how many applications these get used in and log for J is a really, really clarifying case for folks to understand this, you know, what can seemingly a small part of your overall application estate can have disproportionate impact on, on your operations? As we saw with many organizations that spent, you know, a weekend or a week, or a large part of the holidays, scrambling to patch and remediate this, a single vulnerability in one of those thousands of packages in that case log. >>Okay, got it. So you have this two, two headed, two vectors that 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, and it develop those relationships. And now you get first party data. You monetize that with a software service that is purpose built as the monitor of the probe that actually tracks that third, third party activity. So >>Exactly right. Got it. >>Okay. So a lot of companies, Donald, I mean, this is, like I said before, it's a complicated situation. You know, a lot of people don't have the skillsets to deal with this. And so many companies just kind of stick their head in the sand and, you know, 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, you know, and it's just become increasingly clear as these big headline incidents that happened like Heartbleed and solar winds. And now this logged for shell vulnerability. So you can, you can bet on that. Continuing into the future and organizations I think are, 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. You know, 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 of the U S federal trade commission has made a much more direct warning to private companies and industry saying that, you know, issues like this log for J vulnerability risk exposing private, you know, consumer data. That is one of the express mandates of the FTC is to avoid that the FTC has said that this is, you know, bears on both the federal trade commission act, as well as the Gramm-Leach-Bliley act, which relates to consumer data privacy. >>And the FTC just came right out and said it, they said they cited the $700 million settlements that Equifax was subject to for their data breach that also related to open source component, by the way, that that had not been patched by, by Equifax. And they said the FTC intents to use its full legal authority to pursue companies that failed to take reasonable steps, to protect consumer data from exposure as a result of log for J or similar known vulnerabilities in the future. So the FTC is saying, you know, 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 tide lift 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 a tooling like tide lift in the cloud as a service and you know, much easier today than it was 10 or 15 years ago to, to resolve, or at least begin to demonstrate that you're taking action against this problem. >>Absolutely. There's new challenges. Now I'm 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 a, you know, that's part of what we're, we're, we're showing up with from the tide lift 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 tide lift, thanks so much for coming to the cube 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. >>Very welcome. And you are watching the AWS startup showcase open cloud innovations. Keep it right there for more action on the cube, your leader in enterprise tech coverage.

(upbeat music) >> Welcome to this CUBE Conversation. This is part of the second season of the AWS startup showcase, season two, episode one. I'm Dave Nicholson, and I am joined with a very special guest, CEO and co-founder of Tidelift, Mr. Donald Fischer. Donald, welcome to the CUBE. >> Thanks David. Really glad to be here. >> So, first and foremost, tell us about Tidelift. >> Happy to, yeah, so, at Tidelift we're on a mission. Our mission is to make open source software work better for everyone, and when we say that, we mean, make it work better for all the organizations and governments and everybody that depends on open source software to build the applications that we all rely on. But also part of our mission, is making open source work better for the creators of open source. The independent open source maintainers, who are behind so many of those building blocks, technology building blocks that our commerce industry and society is comprised of these days. They've got a hard task to hold up all of that stuff and make sure that it meets, you know, professional grade standards and that we can all rely on it. And so, we want to do our part to help both sides of that equation. >> Fantastic, well, I want to double click on a few of the things that you said, but I think I want to format this by starting out with a little role play between the two of us, if you don't mind. I know you're CEO, but for the sake of this, you're going to be the CIO and I'm going to be the CEO, and we're going to play off some recent events here. So, hey Donald, come on in, sit down. Listen, I want to talk to you about this whole log shell, log for something, or another thing that's going on. So, let me get this straight. Our multinational Fortune 500 company is dependent upon software, that's free, and somehow we've been running this and the people who maintain it, do it for free, we don't pay for it, but somehow this has opened us up to a threat from people who can log into a system we're using to keep track of stuff, and then, what's going on? By the way, you're fired, but I want to know if, I want to know if you can stay on for the next 90 days to train your replacement, but, explain to me what's going on with this whole open-source nonsense? >> Yeah. Don't panic boss. Only about 70 or 80% of the software in our enterprise that is third-party open source software. So, there's definitely, like 20 or 30% that's not, and we're on top of it. Now, yeah, I think it's a, you know, you're right to say, we are completely dependent on this software, that's being created by these, you know, amazing folks on the internet. Boss, you told me that we had to have a global corporation here with modern digital customer experience. We're not going to be able to do it using Microsoft front page from 1997, and there's no other path to take than to build with modern building blocks. And today in, you know, the modern era, that means building on open source packages and technologies across a whole slew of language, ecosystems, like JavaScript and Java PHP, Ruby, Python, .NET, Rust, Go, we use all of it here, boss, and, we don't get to have a business unless we do. >> Okay, so, I didn't understand a word that you just said, but it was enough to convince me to let you keep your job. So, end-scene, we're not getting paid scale wages to do this, Donald, so I think we can go back to our normal personas. So, how does Tidelift play into all of this? I'd really want to hear about this concept of what an open source maintainer is, because these are largely volunteers, aren't they, in terms of the maintenance that they're doing? >> Yeah, so, I mean, open source, there's a lot of different models for open source software development. There certainly are a number of foundational open source projects, certainly at the infrastructure level, like operating systems, databases and things like that, that tend to be, you know, predominantly driven by vendors, software vendors, you know, like you can think of Red Hat, VMware organizations like that. But when you get up to the application development world, teams, building, you know, websites, web applications, mobile applications, most of the building blocks at that tier in these a programming language ecosystems, most of the software there is actually being created, that enterprise organizations use, is being created by individual, independent, open source maintainers, where it's not their day job, it's a side hustle for them. And it's a really interesting question, like, how did we get here? You know, why are these folks doing it? It sort of rhymes with the question I asked myself years ago, like, who's typing all this stuff into Wikipedia, and why? Like, it's amazing resource, I'm so glad it's there, but why are they doing this, right? And it turns out that there's a bunch of motivations there's some cynical motivations for the open source maintainers that people attribute that are practical too, you know, people say your GitHub repository is your resume in as a modern developer, things like that helps you get a reputation, you can use that to get a job. But, when we've talked to the maintainers of the most widely used open source packages, and by that, I mean, thousands of packages that every major organization that builds software relies on, the main reason why they do it is actually impact. We find we've actually done direct surveys of this audience and the reason why they spend their nights and weekends and carve out time, where they could be, you know, getting paid to do something else or going skiing or going to the beach, is it really feels good to have this activity that they put out into the world, and, you know, they know that folks use this stuff and rely on it, and there's a pride in their work and the impact that they're making. But the challenge with this model is that when it's only an impact and pride, and sort of a, you know, a good feeling driven effort, it means that maybe all of the things that organizations might want their standards that organizations might want their software to meet doesn't get done, right? Like it's one thing, if you've got a job as a software engineer, building corporate software, or even as a, you know, a maintainer at a corporate open source company, and you have a checklist of, you know, standard enterprise software development, commercial grade software development tasks that you need to be completing, if you're doing it as a side hustle for good reasons, like impact and, you know, releasing your creative juice, you might not get to some of the more boring aspects of commercial software engineering, like security engineering and some of the documentation and release engineering and, you know, making sure there's structured metadata around all the elements of it. And then that's the gap that we're really trying to fill at Tidelift, by connecting these two audiences. >> Yeah. How? How? You want to fill the gap, you want to connect the audiences, but, how do you do that? >> Yeah, perfect, so, we do it by paying the maintainers, paying the open source maintainers, actual dollars, or the currency of their preference, and what we're paying them for is not just to sort of hack on their projects, or hack on their projects more, we're asking them to help us ensure that the software that the organizations that we work with depend on meets certain specific concrete enterprise standards, and those standards fall into three categories, security, licensing, and maintenance. So, on the security front, you know, a baseline standard, there is making sure that we have known versions of the open source packages that are free of known defects, right? So there's like a catalog of known security defects that the industry uses called the National Vulnerability Database, you may have seen the terminology CVE referred to in passing, that's the identifier for these things. So, we work with the open-source maintainers to make sure that we've figured out, mapped out, which versions of software packages are impacted by known security vulnerabilities. And then we also look forward and make sure that we have a plan in place for what happens in the future when there are security vulnerabilities. So, you know, traditional commercial software, there's a security response team, who's kind of standing by 24/7, ready to respond, and then there's a defined protocol of what's going to happen, in terms of what's called responsible disclosure, telling the right folks in the right sequence, that there is a vulnerability causing there to be a patch version of the software available, communicating that through, you know, traditional commercial software vendors for, you know, years have been doing that internally, that doesn't exist by default for volunteer, you know, part-time open source, independent open source maintainers. So we fill that gap and we pre-wire that with them to make sure that that first track security is can be buttoned up. >> So, you're paying them, are you and your co-founders wealthy philanthropists that are just doing this, or what's the business model here? Now you're pulling these people who were doing it for free, they're happy, but how does that translate into a business model for Tidelift. >> Perfect, so, the work that they're doing, you know, I talked a little bit about security, we also do similar things on those other attributes, like licensing, making sure that the licenses are completely accurate, and we kind of know who wrote the software, et cetera, and then maintenance, is it being proactively cared for going forward? Is somebody still on the case with these projects? Now, the result of all of that work, is we create a vetted catalog of known good open source releases that we've vetted with the experts, often the individuals and teams that wrote the code in the first place, usually, we vet that it meets these enterprise standards. That's a really useful tool for organizations that are building with that. So, the way that we convey that to organizations that are building software in a useful way is we have a SAS service software, that as a service platform, that's what Tidelift is, and basically, the teams that use this stuff, they plug us into their software development process, typically alongside other tools that they might have, like CI/CD tools that are running tests on their application logic, they'll plug in Tidelift into their release process to ensure that those, the 70 or 80% of the software that they ship, that comes from GitHub, comes from the Python package index, or NPM, or the Maven Central Repository for Java, we're vetting that that meets their enterprise standards and ensuring that the ingredients, the building blocks that go into their applications are known good and vetted to these concrete standards. And they are, you know, this is an unsolved problem for almost every serious organization. There's a couple of, you know, over-performing organizations, like Google has done some amazing internal work on this, Amazon has an incredible dedicated team that does this internally for Amazon developers, very few other organizations, even some of the largest multinational companies have a dedicated internal function doing this comprehensively and systematically. Tidelift is that function that these organizations can use. They can work with us and our network, our unique network of hundreds of these independent open source maintainers, to ensure that there is a feed of known good vetted packages to go into their applications. >> So, were maintainers going in and auditing, and editing, and vetting software that was essentially created by others? That's one question, and then the other question that kind of goes along with that is, are you vetting a gold copy of something and saying, this software meets certain criteria, you should feel okay using it, that's one thing. Validating that the actual distribution, you know, the actual code that's being executed in their enterprise is secure and hasn't been tampered with is another thing. So where do you sit in that distribution channel or that supply chain? >> Sure, so, on the distribution front, you can think of us, we're sort of a GPS system that your application developers can use to know which versions of software are going to meet your enterprise standards. We don't create a separate world where we have our own, you know, side copy of the entire development ecosystem. It's not what these organizations want. They don't want to use some weird enterprise world set of open source packages, they want to just, you know, type NPM install have the, you know, software flow into their organization, but they also want it to not have no insecurity vulnerabilities in it, and they don't want to get bitten two weeks or two years later with a license violation, because there was kind of fuzzy, or incomplete data around the open source license. So what we do is, we help them consume the open source software, you know, knowing that it's been vetted to these standards. And then we also work with the open source community to cause the software to be changed to meet those standards, right? So back to the first part of your question, We work with a lot of projects with the prime maintainers, often the authors, as I said, and we've actually been extending our model over the years to work with these open source maintainers to cover not just their own project, but, some of those neighboring projects, right? Like the core projects that their project depends on, other projects that are co-used with them, they have a lot of expertise, and also, you know, relationships with the surrounding open source community there. So, they're working with us as curators, if you will, our ambassadors that help us get on the community and cover as much of the landscape as possible. >> And, so, what's the relationship with AWS? This is, you know, we're talking here as part of the AWS startup showcase season two, episode one, which is, that's actually pretty cool. So we need to, you know, the challenge here is, season one was awesome, much like Ted Lasso, season two, we have big shoes to fill here, Donald. So, what's the-- >> We got to up our game. >> (laughs) What's the relationship with AWS? And, I mean, why would they call you out as someone interesting for us to talk to? >> Yeah, so, we've had a great relationship that we've been investing in, and working on together with AWS. So, every one of AWS's customers faces this challenge around the software workloads that they're deploying on AWS. You know, it's just, you can't argue against the fact that the vast majority of the application software in the modern world is comprised majority of this third-party open source software. And so, it's really important whether it's running on a device, you know, an Edge device, or whether it's running in a Cloud data center, that those applications meet these standards, especially on the security front. So, AWS recognizes this need and opportunity for their customers, and so we've been working really well jointly with them. We're glad to say that we're an ISV, and AWS ISV accelerate partner now, which gives us the ability to co-engage with AWS and work together to solve mutual customers challenges, and we've had a great time working with the AWS team to help scale up our efforts to get the word word out around this important area, and then more importantly, give organizations the tools to address it and make sure that they have a comprehensive strategy for managing their open source in place. >> Fantastic, Donald, we're up against time, but I do have a 10 second answer I'd like from you. Tidelift, is that a reference to a rising tide lifting all boats, or is it an admonishment not to build a house on the beach in Malibu? >> It's the former, you know, think about this network of independent open source maintainers, working together, a rising tide lifts all boats. >> Eight seconds, that was like four seconds. Perfect. Donald Fischer, from Tidelift, thank you so much. For me, Dave Nicholson here at the CUBE. This has been a CUBE Conversation, as part of AWS's startup showcase, season two, episode one. Come to the CUBE for the best in tech coverage. (soft music)