 Okay, welcome back everyone. Live CUBE coverage here at RSA Conference 2023. I'm John Furrier, host of theCUBE. Dave Vellante is flying in. Walter Wall covers four days. This is a great show. It unpacks kind of the security industry. It breaks down all the action. It's kind of like the big trade show. It's not so much a conference as much as a trade show. We just came back from the CNCF, KubeCon, CloudNative.com. A little bit more developer focus all about open source. This next guest is going to bring that to here, Brian Fox, Kube founder and CTO of Sonatide. Great to see you. Thanks for coming in. You and I both just got off a plane yesterday. We're a little bit jet lagged. Yeah, a lot jet lagged. Amsterdam to the West Coast is a big difference. I mean, what a perfect back-to-back set of events. KubeCon, 10,000 people in Europe, by the way. That's a huge tell sign. The activity on the developer side and open source side booming. That's carrying forward here. I'm writing a post this morning called Developer Lead. Developer is the new consumer. Business to developer, B2D. They're the new consumers. That's going to go mainstream. This show is kind of mainstream. So I want to get your thoughts on where we are in the security industry now because this show, if you look at what's out there, this is essentially the trade show, the ecosystem. The vendors, the customers are here. Tons of business development happening. People are synthesizing, trying to prioritize their objectives. What's the focus? What's the big story going on from your perspective? What do you see happening? Well, I mean, of course, like we chatted about AI is a new interesting thing within this certainly around helping developers be more productive and what the security implications of that. I think people are just scratching the surface with. I see the industry struggling with some of the fundamentals though. We have done some studies for years. I think last year was our eighth year in a row. And the thing that I've been rattling on about since then is really that we see that 96% of the time when organizations are pulling down vulnerable components, there's already a fix available, right? Which tells me that the problem is on the consumption side, right? So take Takata airbags, right? We all know that there were some issues and they did recalls. These things happen. But imagine a vendor today, a new car, a 2023 model year car having these known vulnerable airbags from five years ago. That would be ridiculous. That's what's happening in software today. So there's a lot of conversations about all the new and novel edge cases. And really as an industry, we're failing to follow in best practices and deal with the fundamentals. Is that human problems? That's just laziness. That's just more hygiene. I mean, it's more, and does AI solve that? I mean, cause you see what's going on with this low code automatic chat GPT movement is codes being written, but that could also be helpful. Yeah, I don't think the AI aspect of this really affects the dependencies yet. You know, when people are choosing to make bad, but put bad components into there, it has less to do with the new custom code that they're creating and just about the hygiene of their dependency stack. Talk about the company. How old are you guys? When do you guys start? What's the focus? What are you guys doing right now? So we started in 2007. We were the company behind Apache Maven and the Nexus repository. We still run the Maven Central repo, which is where the world gets all of their open source Java. For more than probably about 12 years of that journey, we've been helping organizations deal with what is now known as the software supply chain problem. Right, the S-bomb software build materials. Love that term. It reminds me of like a manufacturing operation. That's right. Yeah, I mean, we recognize that gap way back in 2011, 2012, that there was this challenge that people kept using these known vulnerable components and not doing upgrades. And so we've been helping organizations with that for a long time. I think with SolarWinds a couple of years ago, the Apache Log4j and Log4shell really drove awareness on this problem in a big way over the last couple years. But that's really been our journey to help people solve that. What are some of the challenges coming on that you can point to? Because if you look at the mainstream enterprises, they're moving from virtual machines to containers and Kubernetes. We're just at KubeCon. Not a lot of people there yet, still head room there to move over. Whether it's bare metal or existing operations, they already have the challenge you pointed out, one of them, which was fix the stuff you got. Make sure they're all updated, make things as cool. But as new stuff goes with digital transformation, with the cloud native, where are the customers from your perspective? Because you got a unique view. You're looking at it from the open source side, which gives you a little bit of a 20 mile stair into kind of the shift. What's happening? Where are the mainstream customers at right now? Are they still kind of old side of the street? Have they moved over? What's your view on that? I think mainstream customers right now still don't have a handle on what's going on in their supply chain. As evidenced by, as of last week, 29% of the consumption worldwide of Log4j versions are of the known vulnerable versions. Everybody in the industry knows that that was an issue. We're closing in on 18 months at this point. How is it that a third of organizations are still pulling down these known vulnerable things 18 months later? That's insane, right? And that quite literally is the example I gave of new model year cars being shipped with known broken airbags right now as we speak. And so the mainstream organizations, that's where they are. They don't understand their organizational bill of materials, let alone one application. They don't understand across their portfolio that they have all of these known vulnerable things inside. So Brian, Brian, spell it out for a similar audience that might not be in the weeds, technical. Bill of materials is a business term. You're building a car. You need to build materials. I need an engine, I need parts. It's like the manufacturing list in software. When you build software, you need code. Open source obviously is out in the open. It's not always tested. What is Sbom or software bill of materials? Be specific and share a quick definition of what is software bill of materials? Sure, software bill of materials is the term of art for listing out the dependencies that are in your applications. 90% of a modern application are these components, these parts, just like an auto manufacturer doesn't always build, literally every piece of metal that went into that car, they're pulling them from vendors. That's what's happening in the modern application. 90% of it comes from somewhere else. The problem is because these decisions are being made often by developers, they don't go through the procurement process where procurement is about risk reduction across all these different things, whether it's a trusted partner, a trusted vendor, is it a good decision, these things are skipped and so what happens is organizations more often than not don't have good visibility into what these dependencies are, right? And so when something like log for shell happens, the people who should care, they don't know where in an organization that exists because they haven't followed these practices. That's where the risk exists from my point of view. I think your example of steel, for instance, is a great example, because steel, I was talking to Richard Hartman actually from Grafano last about this, is there's no more pure steel, they're going to go get sunken boats to get pure steel. That was really off the deep end, pun intended. You'd have enough of Richard, he's cool. But his point is it's been contaminated by just the pollution around it, but there are things in things that you don't know. This is where the verification comes in. And the same thing's happening with containers as well. You start to see containers be tainted as well. So when you look at containers, they're a big part of wrapping up code. That's right. That's another dynamic, what's your reaction to that? It's the same problem just at a bigger scale. As you start building containers, it's harder to know what's inside them. So we're focused on what's inside your applications. But when you step back and you look at the application as the entire stack, now it's your application with 90% stuff that you didn't write. Who knows what's inside there? You've got a container built on a base image. Who built that? What did they install on it? Are those things trustworthy? Are all the dependencies inside those things trustworthy? So the problem space is quite large. But it starts with being able to track what's inside your application so that you can do these recalls when something goes wrong. Brian, you're bringing up a really, really good point that I've been harping on for a long time. I'm so glad you brought it up. I'll just tee it up for you to kind of give your commentary on it. Writing code and understanding systems are kind of the same thing, but not necessarily the same thing. You can be a great coder. There's always impact to changes. So if you have a system mindset, one change could have a ripple effect other places. You just mentioned all these dependencies. This dependency conversation is super important. How does a company get their hands around this at the scale that they have? Because you have containers. You have now horizontally scalable data sets. We're going to see more and more of that. What's your comment on that? Certainly you could buy Sonotype products. That's all we want to do. We'll say that again? You could buy Sonotype products to help do that. Of course. Let's get into it. You know, it starts with being able to have the visibility around what's inside it. It leads to providing information to the developers so that they can make better informed choices. Developers are not motivated to do a terrible job, but in some cases they're not provided with the information to make a better choice about one component versus another. They don't have the visibility into that stack to know that the components they have might have a bunch of vulnerabilities. That's changing. People, the awareness of that has changed certainly over the arc of our history, right? But they're still not more often than not empowered with the ability to make those good decisions. So getting that information to the developers can help, but you have to be able to do this at scale. It's things like being able to provide them prioritized information. Not just say, you have to solve all the problems. Here's all the raw data, figure it out, but put policies in place. Monitor it from the enterprise scale so that when something happens, you immediately know. Here's all the places that need to be adjusted. Here's the things that need to be dealt with in the priority order. That's how you start to handle this. So I teed up a little bit of a warm intro to the product. How do you guys solve that problem? Take us through your solution. Who's the target? What problems do they have? When does someone say, I need sonotype right now? Take us through that use case real quick. Sure. I mean, one part we haven't touched on is the rise of the intentional malware in these components, right? So we've seen the last three years on average, 742% growth in the number of supply chain attacks. So these are not your log for Jays that have a vulnerability. These are components that are designed to cause harm as soon as the developers touch it, right? So we have a product that we call Sonotype Firewall. It sits in the development environment, is able to assess the components coming in. We know which ones have malicious, and we actually use MLAI techniques to identify that so that when the developers are trying to pull in these things accidentally, we can stop that, right? So that stops some of these intentionally malicious where they're putting back doors on developer machines and extra trains. That's more than scanning. That's more than scanning. It is definitely more than scanning because we've analyzed the things when they get published into the repo. So we can already detect that there's something fishy about it. If one of our customers tries to pull it in, we can stop it. So that's a new aspect of this whole game. It's, you know, tracking the vulnerable components is sort of last decade's war that we as an industry are still not doing a great job at. But now we've got these new malicious attacks which is a whole different domain. So we just published a story on the double, we call it double supply chain hack where they come in through the VoIP app. This was the one that was just published. They sit in there and then they create false credentials on LinkedIn, then they sell, then they're acting like recruiters for a big bank in Europe. And then they're targeting folks who have credentialed access to systems. And here, download this job. You can get paid more. And it's running in the background. They use the Unicode, not ASCII. So it looks like a dot. They fake everything out. It looks, everything's clean. It's even savvy tech people click on it. It's not a dot, it's Unicode. Right. There is the equivalent of that with these components that they're going in through the development environment and then moving laterally through an organization. There've been a number of high profile attacks like that where the developers get compromised in a modern cloud native infrastructure as code world. The development infrastructure has a lot of keys to the kingdom, makes it a very sweet target. All right, so I'm going to put my devil's advocate hat on. I'm a customer. I don't need sonotype, I'm good. What would you say to the folks out there who may think they're good, but they're not? When would they, what would you say to them on why they should buy you guys and how you help them? Yeah, this problem is, to do this well requires a lot of nuance and a lot of complexity that we've built up over more than a decade of dealing with this. To do it poorly is easy. And I think people that are just starting to think about this problem, they don't understand the second and third and fourth order effects of can we do this in a way that makes developers more efficient, not add another tax to them, right? Can we do it in a way that the organization can understand and manage the portfolio at scale is a complex problem. And you guys have a trajectory on just scale over the years. Oh, yes. And your platform, not a tool too, as well. That's correct. Explain the difference from this context. Right, sure, it's a great point. That we have a number of different pieces that work together, whether it's the firewall part I was talking about or lifecycle, which helps manage the applications all the way through to production and understand what's inside them when something goes wrong six months after you shipped it. Being able to do all of these things well and have it tied together requires a platform effect. But the reason for that, quite frankly, is some of the earliest customers that were caring to solve this problem were big financial regulated industries that understood they were the ones, they were the targets of the attack required a more sophisticated solution. Then can we just give a tool to our developers to scan and give them a list and hope they do the right thing? So we, by our customer set, the early adopters kind of pulled in that direction, which is what it really takes to do it at scale. I know you got to go, we've got some time here, but I want to get one more point in to get it and make sure I get it out there properly. The S-bombs now be getting some regulation behind it. Obviously because of the sensitivity of supply chain with software now highlighted. What's going on in that realm? How do you guys address that piece? Are you in line with that? What's the status of that? Yeah, I mean, S-bombs are a great thing. It's been driving the conversation. For me, it's a means to an end. The bill of materials by itself is just literally a piece of paper, right? It's what organizations do with that to do the active management of the components. So there's a lot of regulation. The national cybersecurity strategy is putting the focus on trying to shift the liability towards companies to do the right thing. So it transcends the S-bombs and gets more to the heart of the issue, I think, which is if you're not following the minimum standards to produce good quality product, you should be liable for that, right? And every mature industry before us, whether it's the auto manufacturers or food, have gone through this liability shift to where they weren't liable unless there was a contract in place to everybody says, that's ridiculous. If you don't follow the minimum safety standards, you're going to be held liable. And I think our industry is right on the precipice of that. Awesome. My final question since here, we both had a great week in Amsterdam with the cloud native and KubeCon, part of the CNCF Linux Foundation. Big open source movement, obviously a lot of conversations around licensing came up with the whole AI piece, which is separate from here. Connect the dots for this community here. This is a much more mature environment, RSA conference, there's all the big players are here, big vendors. I mean, I believe open source is a canary in the coal mine at many levels. Cloud native networking to application as it comes into the mainstream security industry. What do you think the big impact will be over the next five years if you had to kind of throw a projection out there? Well, I think it starts to obscure part of the problem, right? As you start relying on cloud native services, it's a black box. You don't know the implications of what's going on behind that. So we're struggling as an industry to know what's inside our own software. How do we know what's going on inside the services that we might be using or the platform that we're residing on top of. So it's, as they say, turtles all the way down. It's the same problem. But now you start putting walls in between you and them and it gets even harder. Yeah, well, Brian, I appreciate it. One thing that's clear, and I'll give you the final word here, is that you're starting to see the horizontal scale. You're starting to see vertical specialization with data, integrated systems, systems thinking, platforms versus tools. You're starting to see at least some visibility that you have to have a platform and not everyone can win in that game. Not everyone can be the platform or you have a collection of platforms. So at some point there needs to be some sort of unified base. Your thoughts on that concept in general as this industry evolves in the next decade. Yeah, I think that's the key. I mean, we took that approach from the beginning because we understood that this was a multi-dimensional problem. It wasn't just about solving for security or solving for the open source license or even solving for architecture. When you're a developer, you have to solve for all of those at the end of the day. And so that's why we took the approach we did to try to synthesize all of these different important policies down to the developers to help them make better choices. I think the next unicorns are going to come out of this next wave and I think it's going to be a platform like Enabler. That's a platform, it could be an open platform. I mean, WebAssembly, one of the hottest things I love about what's going on in cloud native world is it should have been done a decade ago, if not two. I mean, why would you want to, anyone want to rewrite code to make something work? That's right. And just get the binaries and have compilers support the code. Like, it makes sense. Exactly. Well, it took it so long. Thank you, Bruce. Hey dogma, walk in, grieve. I think the security, it's going to be a forcing function. It's going to be fun to watch. Brian, thanks for coming on. We'll certainly follow up with you guys and keep in touch. Great, thanks for having me. Okay, Brian Fox, co-founder, senior son of type, great company. Check it out, they are building a platform. They're looking at the big picture, years of experience, getting the data, knowing what's in the code. Software supply chain is the most important conversation happening here. And you're going to hear more and more about the data and techniques to make it better and identify what's in your code. So, we'll cover on the year at theCUBE. We'll be right back after this short break.