 Welcome to the CUBE's coverage of KubeCon EU 2024, live from Paris, France. Join hosts Savannah Peterson, Dustin Kirkland, and Rob Stratche, as they interview some of the brightest minds in cloud native computing. Coverage of KubeCon cloud native con is brought to you by Red Hat, CNCF, and its ecosystem partners. The CUBE's coverage of KubeCon EU 2024 begins right now. And welcome back to Paris and KubeCon cloud native con EU. I'm Rob Stratche, your host for today, and I'm really glad to be joined by Dustin Kirkland and by some guys from Sonatype, sorry, almost went too much for it. I was going for it, but Brian Fox, who's the CTO and one of the co-founders, and Tyler Warden, who's an SVP of product. Welcome on to the CUBE and welcome back to the CUBE as an alumni. Thank you, happy to be here. So I think what's been awesome beyond the fact that your booth is right behind us and we get to actually stare at your booth and very strategic move to get it there and great promotion all week long. So, but really you guys had a really interesting announcement, we talk about S-bombs quite a lot. We throw a lot of S-bombs down here on the CUBE and we have been for a couple of years. I think one of the things that people look at is that really understanding and managing that and dealing with supply chain is kind of a headache but you had an announcement that you just made this, you know, just yesterday. Yeah, you want to take it? Yeah, we were really thrilled to announce our Sonatype S-bomb manager. It's really, we think a really exciting introduction to the market to have a purpose built solution to help you manage, curate, ingest, create, audit and get that value that you want out of your S-bombs. We've heard so much, I've got these S-bombs, I don't know what to do with them. And so you can really, there's a lot of value. There's a lot of acceleration and there's a lot of optimization that can come from managing those effectively and we were just thrilled yesterday to announce Sonatype S-bomb manager to help kind of meet that need in the market. Can you connect us with your customers a little bit and just, you know, what sort of problems are you solving with this S-bomb manager for your customers? You know, we see organizations needing to both consume S-bombs for the software that they buy, the components they use and then share those with their end customers. So there's this real, think about your fulfillment or your distribution center in like the physical world. There's this need to automate and control and consume those S-bombs that you're going to share with your end customers, right? To give trust in your software. And then when you're looking at your supply chain and the software that you're building, organizations want to really understand what are those ingredients that they're bringing into their product, right? They want to eat healthy, right? And they want their software to be healthy. And so being able to consume and understand and put healthy ingredients into what they're making, those are the real key challenges our customers are looking to solve. Yeah, I think that to me makes total sense because I can remember having been on the product side myself at multiple companies and keeping it a list in like Excel and trying to then communicate that to some three-letter acronym, U.S. agency or something like that. Really not a fun conversation to be having. What are some of the best practices that you guys are seeing your customers adopt as they move towards management of S-bombs? Yeah, well of course, you know, historically it's been focused more on the first-party software development, the open-source dependencies, managing the supply chain, producing the software and the S-bombs coming out of that. That's where we've been focused for a handful of years as this S-bom concept really gained traction. What we've seen in the last year or so is everybody saying great, I'm supposed to ask for S-bombs from my vendors and my customers are asking me for S-bombs. I don't have a good clearing house for be able to manage all of these things, right? So it's been interesting to see the market sort of develop just over the last year. You know, last year I was speaking to folks who were somewhat in angry denial. You know, how dare they force us to understand what's inside our software. Don't they know how hard this is? For reasons that they would never want to tell their customers, like, we don't have any engineers on that product anymore. We don't actually know what's inside it. We can't source that. You know, that was last year's conversation. This year's conversation is more like, okay, we're doing this, but we're not sure how to do it. We don't have the tooling to help support it. And you're helping them develop that strategy maybe for the first time? That's right, we are. And it's been interesting that even within customers to have our traditional platform that are helping them with the software they're building, there are other groups within the side of those same companies now who are focused on the distribution part that Tyler talked about and also the procurement part. So they're saying, that's great. Our engineering team is managing our software and our dependencies and we could produce an S-bomb. But what about all the stuff outside that? What about the operating system, the database, the application server, the rest of the stack that they're not developing? When they push that to their customer, all of that now becomes a deliverable that they have to have a combined S-bomb for, right? So we're seeing that evolution of the market expanding and that's why there's that real need for purpose-built solutions with extra capabilities to help manage all of that. Yeah, I would say that, and we were talking about platform engineering a little bit earlier in the day today. And as platform engineering kind of becomes that center of excellence across what used to be called IT and many, they have to dive in and there's kind of a supply chain aspect to this and a security aspect and a number of things. Are you seeing organizations be hesitant about really like leaning into S-bombs? Or is it, what are the challenges of getting started? I don't know if I would say hesitant, tentative, might be the right word, but I think, you know, certainly there are any of the organizations that intersect with the US federal government are sort of on the leading edge of that and some of them may feel forced into it. Like I said, that angry denial, but I think that they're moving into, okay, we have to do this, but I think it's sort of this open secret. Everybody will say it when pressed. Like we know that the customers are asking us for the S-bombs, but we also know that they don't know what they're doing with them and some of them are like, honestly, I've been told, some of them are like printing them out and putting them in a file cabinet because they've just been told I need to collect them. You need to have one. I need to have one. Or they're just taking the JSON documents and dumping them to a database, which is not, it's better than not having it, but only barely because if something like the next log for shell happens, you need to be able to quickly search through those and figure out what's going on. It's not serving a purpose. It's not serving a purpose. If it's just a file in a folder or printed out on a desk, it's not serving a purpose. So that's where the bleeding edge is at the moment. Hence, something like the manager to be able to import those programmatically understands what's inside them, proactively alert you to the problems is such a key aspect. Talk to me a little bit about, you mentioned federal government, the regulations here. This is a landscape that's evolving fairly quickly by government speed standards, right? Some of the regulations that you see coming, driving adoption here. It's got to be serving a CISOs need, trying to meet their compliance and regulatory obligations. Is that part of what your SBOM manager will help with? Oh, very much so. And what we see that's most interesting is a mixture of regulation movement that I think Brian can talk about here, but also the enforcement side is also starting to happen. We start to see agencies like the SEC, a security exchange commission in the state starting to lean in and take some actions. The Justice Department starting to lean in and take some out. The FDA starting to lean in and take some action. There's, it is a good first step to write very powerful, meaningful documents. It is what we've seen recently is a industry changing step to start to enforce and follow up on those documents. And that's just in the state, similar enforcement and regulations across the world. And we're very involved in helping to lobby and thought lead in that area. What are some of the common open source consumption issues that you see within companies when they're trying to get a handle on it? And what are some of the challenges this is going to help solve for them? Yeah, I mean, most organizations struggle with understanding, let's call it, their organizational bill of materials. So across the portfolio, all of the components. And we could be talking easily 100,000 components or more in a typical organization. Try putting that into a spreadsheet and doing anything useful with it. And so we've published statistics, our annual state of the software supply chain report. We've done it nine years in a row. The past couple of years, we've done analysis on the consumption patterns. And we found that when something open source is being consumed from a repository like Maven Central, 96% of the time, there's already a fixed version of that same component available. So it speaks to the problem is that while the open source community does a pretty reasonable job at patching zero days and disclosing them, the consuming organizations don't update. In fact, as we sit here right now, Log4Shell was what, two years, four months ago? So more than two years ago, 30% of the versions of Log4J that are being downloaded are of the ones affected by Log4Shell, which is really, really shocking when you think about it. And I don't believe for a minute that organizations are choosing to do that on purpose. It's happening because they don't know, they have no visibility into that part of their portfolio. So the S-bombs, being able to manage it all up and down the stack, will help with that visibility, but then they need the tooling to be able to act upon it, right? And that's what we're trying to help them do. Yeah, I mean, even just this week, I was quoted on the Argo CD has three that are vulnerabilities that haven't been patched yet, but we're actually released and I think you could argue how bad they were or not, but I think that plays to exactly what you're talking about is, because for organizations, it's not only knowing what you have there, but understanding, okay, what version it is, is it susceptible, how do I mitigate that? Is that all part of what you're getting at with the S-bombs manager? Yeah, I mean, if you think about, let's take it to the auto industry for a moment, right? The early executive orders that said, everybody that needs to provide an S-bomb is a little bit like, you know, the National Highway Safety Administration in the US saying to manufacturers, you don't need to do a recall as long as you print out the bill of materials and put it in a glove box of every car you sell. Like that's kind of insane, right? But that's where the policy started. We all expect as consumers that our manufacturer knows what version of what parts went into my VIN number so that when there's a problem, they can send me an email or a letter saying, you need to bring that into a recall. We expect that. So the system behind that is really something like an S-bomb manager. That's what we're talking about, that asset management and tracking system that we expect is behind the scenes in most software organizations that doesn't exist. And that leads to this consumption pattern. And if you think about that stat I mentioned on Log4Shell, you know, talk about the flawed airbags problem that's been pervasive for years. Imagine what would happen if we found out that a manufacturer of 2024 model year vehicles was putting those old airbags in there today. Like, there would be nothing else on the news but that. And yet that is exactly what's happening with software. That's the state of software. That's the state of software. And not enough people are having that like, you know, what is actually going on moment because they just don't know. You can't see what's behind the scenes of the software. Yeah, that's exactly right. The Log4Shell was December of 2022, I believe. And that was a watershed moment for, you know, many as CIO and CSO saying, how bad is this? Are we using this? What version are we using? You know, and just having that transparency into it. That's huge. And I think what's also exciting if you're making software for a living or if you're on a team, that it's not only those security outcomes, but that taking that control and optimizing your software supply chain as part of that software supply chain report, your teams actually develop faster, call it more story points in your sprint, right? They bring more innovation to market faster proven by data than organizations that would ignore open source and just try to work faster. So despite what you may think, right, initially, these cybersecurity outcomes are awesome. But what's even maybe more exciting to me as a guy running product is our teams are faster. And they're spending more time coding the stuff that matters, right? And so you get both of those outcomes with this software supply chain optimization, which is pretty cool. And I think you kind of briefly touched on it, but it's when you start to look at it, it's not just one group that has to deal with this. And if you see organizations where there's actually multiple development groups in multiple different business units, and the whole corporate entity needs to now understand and have it. Because like you said, when the SEC Securities and Exchange Commission gets involved and says, hey, we're going to find you if you don't disclose these things, you know, you have a breach or what have you and you need to understand why within 48 hours or 72 hours. It's crazy. Is this where you see customers coming to you and saying, hey, this is what we're trying to get a handle on and breaking down these silos? At the core of who we are as a business has always been trying to work across those diverse stakeholders and silos within the business. And by diverse, I mean lawyers all the way over to engineers, product managers, designers, GRC, governance risk and compliance. It takes the business to make these decisions together. And what we're seeing is some of the best practices of just supply chain optimization in the physical world is not passing those defects downstream and having those silos be broken down. It's a forced silo breakdown. And we can do that without the friction now because there's a single source of truth with the context. So the legal teams can understand legal risk at the same time as the engineering teams can understand maybe a end of life component, right? This is all together and you need to not just, security is a great outcome, but the optimization and supply chain acceleration, like that's what you're doing, the outcomes of that. Or is that silo breaking down and the security and the legal and all those other risks that can be mitigated? So my last question because this week is already kicked off with yesterday with the day zero activities and a lot of hallway discussions. Security definitely at the forefront, I think this thing called AI is like kind of thrown a little bit of a monkey wrench. AI can't be making things any easier for organizations from an SBOM perspective. I would assume that that's also a big push is, hey, we need to be, if we're going to put this chatbot out, this LLM, we need to know what's in it, where it came from, how it got trained and things of that nature. What we're seeing for me, the pattern looks very much like the early, early open source governance days where you talk to leaders and they'd say, we don't use open source. And then as the stewards of Maven Central, we'd look and say, well, you downloaded 60,000 components from us last year. You clearly are. We're seeing the same conversation with AI. We'll talk to leaders that say, we've told our teams they can't use LLMs and AI, and yet they are. And so if you don't have the visibility, you don't know and you don't have the ability to do enforcement. So what, last month or so, we added those capabilities to our platform as well because our customers were saying, we need help getting a handle on this. We need to understand. But what's interesting is the LLM capabilities are popping up in areas where you wouldn't think. Like the chatbot is the most obvious and you would think like, of course the developers didn't just add that capability without anybody knowing. That just doesn't happen. But where you see it is in micro things like trying to do a parser or something like that, using an LLM to help understand, interpret. It could be buried underneath the hood in one of these micro LLMs. Code copilates. Code copilates and these other things underneath the hood in the product. And that's what we're seeing start to happen. And so that's not necessarily a bad thing if it's understood and managed just like the open source components. You don't want somebody bullying in something crazy without you knowing about it. The new part of that would just be the AI capabilities. Yeah, well we look at it and we're always dropping S-bombs on this show. So we love having you guys on. Brian and Taylor, Tyler. I'll get it right. I'd need more coffee I think already. And Dustin, thanks for coming on board. And thank you for watching The Cube, the leader in high tech analysis and news. We'll be back with more from KubeCon, CaliNativeCon, EU in Paris. Stay tuned.