KubeCon + CloudNativeCon Europe 2024 | Brian Fox & Tyler Warden | Sonatype

Clips
News
More from KubeCon + CloudNativeCon Europe 2024

Brian Fox

Co-Founder & CTO

Sonatype

Tyler Warden

SVP of Product

Sonatype

Unlocking secrets in software supply chains: Sonatype’s new SBOM management approach

More than mere buzzwords, terms such as software lifecycle and bill of materials are crucial to understanding, curating and optimizing the enterprise software supply chain. To that end, the recently unveiled SBOM Manager by Sonatype Inc. aims to streamline the end-to-end management of an organization’s software bill of materials.“It’s a really exciting introduction to the market to have a purpose-built solution to help you manage, ingest, create, audit, and get that value that you want out of your SBOMs,” said Tyler Warden (pictured, left), senior vice president of product at Sonatype

play_circle_outline Introducing Sonatype SBOM Manager: Fulfilling the Demand for Effective Purpose-Built Solutions in SBOM Management

play_circle_outline Customers needing to consume and share SBOMs for software and components

play_circle_outline Understanding and Managing Supply Chain SBOMs: Resolving Open-source Consumption Challenges with SBOM Manager

play_circle_outline Importance of transparency and visibility into software components and vulnerabilities

Info

Brian Fox & Tyler Warden | Sonatype

Brian Fox

Co-Founder & CTO Sonatype

Tyler Warden

SVP of Product Sonatype

search

(bright music) (air whooshing)

>> Hello, and welcome back to Paris and KubeCon/CloudNativeCon EU. I'm Rob Strechay, your host for today, and I'm really glad to be joined by Dustin Kirkland and by some guys from, (chuckling) Sonatype, sorry. I almost went too much for it. I was going for 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 "theCUBE" and welcome back to "theCUBE" 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, 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 SBOMs quite a lot. We throw a lot of SBOMs down here on "theCUBE," and we have been for a couple 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 just yesterday.

>> Yeah, you want to take it?

>> Yeah, we were really thrilled to announce our Sonatype SBOM 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 SBOMS. We've heard so much, "I've got these SBOMs. 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. We were just thrilled yesterday to announce Sonatype SBOM 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 SBOM Manager for your customers?

>> We see organizations needing to both consume SBOMs for the software that they buy, the components they use, and then share those with their end customers.

>> Mm. >> So there's this real, think about your fulfillment or your distribution center and like the physical world. There's this need to automate and control and consume those SBOMs that you are 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 in to their product, right? That 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 SBOMs?

>> Yeah, well, of course, 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 SBOMs coming out of that. That's where we've been focused for a handful of years as this SBOM concept really gained traction. What we've seen in the last year or so is everybody's saying, "Great, I'm supposed to ask for SBOMs from my vendors, and my customers are asking me for SBOMs. I don't have a good clearing house for being 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. Last year I was speaking to folks who were somewhat in angry denial.

>> What a great way of putting it.

>> (chuckles) Yeah, "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." 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. It's been interesting that even within customers who have our traditional platform that are helping them with the software they're building, there are other groups within inside those same companies now who are focused on the distribution part that Tyler talked about and also the procurement part. So they're saying like, "That's great. Our engineering team is managing our software and our dependencies, and we could produce an SBOM," 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 SBOM 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 it, 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, well, what used to be called IT in 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 SBOMs, or is it... What are the challenge of getting started?

>> I don't know if I would say hesitant. Tentative might be the right word, but I think certainly any of the organizations that intersect with the U.S. 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, 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 customer's are asking us for the SBOMs, but we also know that they don't know what they're doing with them." And some of them are like, like honestly, I've been told some of them are like printing them out and putting 'em 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 'em into a database, which is not, it's better than not having it, but only barely, because if something like the next Log4Shell happens, you need to be able to quickly search through those and figure out

what's going on. >> It's not serving a purpose.

Right? >> 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 the purpose. >> That's right. So that's where the bleeding edge is at the moment. Hence, something like the manager to be able to import those programmatically, understand 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, that's got to be serving a CISO's 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.

>> Mm. >> We start to see agencies like the SEC, Security Exchange Commission, in the state starting to lean in and take some actions. The Justice Department starting to lean in and take some action. The FDA starting to lean in and take some action. It is a good first step to write very powerful, meaningful documents. 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 States. 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 component, 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 years we've done analysis on the consumption patterns, and we've 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, right? So it 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

and four months ago? >> 2019?

>> Yeah. >> 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 SBOMs, 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 (chuckling) that are vulnerabilities that haven't been patched yet but were actually released. I think you could argue how bad they were or not, but I think that plays to exactly what you're talking about, is it's 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 SBOM 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 SBOM is a little bit like the National Highway Safety Administration in the U.S. 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 the glove box of every car you sell." Like, that's kind of insane, right? But that's where the, that's where the policy started. We all expect as consumers that our manufacturer knows what version of what parts went into the 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 SBOM 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, 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.

>> Yeah. Yeah, yeah.

>> And not enough people are having that like 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, no, that's exactly right, that the Log4Shell was December of 2022, I believe, and that was a watershed moment for many a CIO and CISO, saying, "How bad is this? Are we using this? What version are we using?" and just having that transparency into it.

>> That's right. >> That's huge.

>> 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.

>> 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, because like you said, when the SEC, Securities and Exchange Commission, gets (chuckling) involved and says, "Hey, we're going to fine you if you don't disclose these things," 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 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 has 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 throwing 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." 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, right? 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, 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 microcode LLMs.

>> Code copilots or something.

>> Code copilots 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 bowling in something crazy without you knowing about it. The new part of that would be just the AI capabilities.

>> Yeah, well, we look at it, and we're always dropping SBOMs on this show, so we love having you guys on, Brian and Taylor. Tyler. I'll get it right. I need more coffee, I think, already. (everyone chuckling) And Dustin, thanks for coming on board, and thank you for watching "theCUBE," the leader in high-tech analysis and news. We'll be back with more from KubeCon/CloudNativeCon EU in Paris. Stay tuned. (bright music)

Brian Fox & Tyler Warden | Sonatype

search

(bright music) (air whooshing)

>> Hello, and welcome back to Paris and KubeCon/CloudNativeCon EU. I'm Rob Strechay, your host for today, and I'm really glad to be joined by Dustin Kirkland and by some guys from, (chuckling) Sonatype, sorry. I almost went too much for it. I was going for 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 "theCUBE" and welcome back to "theCUBE" 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, 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 SBOMs quite a lot. We throw a lot of SBOMs down here on "theCUBE," and we have been for a couple 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 just yesterday.

>> Yeah, you want to take it?

>> Yeah, we were really thrilled to announce our Sonatype SBOM 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 SBOMS. We've heard so much, "I've got these SBOMs. 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. We were just thrilled yesterday to announce Sonatype SBOM 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 SBOM Manager for your customers?

>> We see organizations needing to both consume SBOMs for the software that they buy, the components they use, and then share those with their end customers.

>> Mm. >> So there's this real, think about your fulfillment or your distribution center and like the physical world. There's this need to automate and control and consume those SBOMs that you are 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 in to their product, right? That 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 SBOMs?

>> Yeah, well, of course, 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 SBOMs coming out of that. That's where we've been focused for a handful of years as this SBOM concept really gained traction. What we've seen in the last year or so is everybody's saying, "Great, I'm supposed to ask for SBOMs from my vendors, and my customers are asking me for SBOMs. I don't have a good clearing house for being 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. Last year I was speaking to folks who were somewhat in angry denial.

>> What a great way of putting it.

>> (chuckles) Yeah, "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." 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. It's been interesting that even within customers who have our traditional platform that are helping them with the software they're building, there are other groups within inside those same companies now who are focused on the distribution part that Tyler talked about and also the procurement part. So they're saying like, "That's great. Our engineering team is managing our software and our dependencies, and we could produce an SBOM," 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 SBOM 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 it, 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, well, what used to be called IT in 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 SBOMs, or is it... What are the challenge of getting started?

>> I don't know if I would say hesitant. Tentative might be the right word, but I think certainly any of the organizations that intersect with the U.S. 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, 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 customer's are asking us for the SBOMs, but we also know that they don't know what they're doing with them." And some of them are like, like honestly, I've been told some of them are like printing them out and putting 'em 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 'em into a database, which is not, it's better than not having it, but only barely, because if something like the next Log4Shell happens, you need to be able to quickly search through those and figure out

what's going on. >> It's not serving a purpose.

Right? >> 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 the purpose. >> That's right. So that's where the bleeding edge is at the moment. Hence, something like the manager to be able to import those programmatically, understand 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, that's got to be serving a CISO's 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.

>> Mm. >> We start to see agencies like the SEC, Security Exchange Commission, in the state starting to lean in and take some actions. The Justice Department starting to lean in and take some action. The FDA starting to lean in and take some action. It is a good first step to write very powerful, meaningful documents. 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 States. 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 component, 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 years we've done analysis on the consumption patterns, and we've 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, right? So it 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

and four months ago? >> 2019?

>> Yeah. >> 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 SBOMs, 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 (chuckling) that are vulnerabilities that haven't been patched yet but were actually released. I think you could argue how bad they were or not, but I think that plays to exactly what you're talking about, is it's 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 SBOM 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 SBOM is a little bit like the National Highway Safety Administration in the U.S. 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 the glove box of every car you sell." Like, that's kind of insane, right? But that's where the, that's where the policy started. We all expect as consumers that our manufacturer knows what version of what parts went into the 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 SBOM 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, 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.

>> Yeah. Yeah, yeah.

>> And not enough people are having that like 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, no, that's exactly right, that the Log4Shell was December of 2022, I believe, and that was a watershed moment for many a CIO and CISO, saying, "How bad is this? Are we using this? What version are we using?" and just having that transparency into it.

>> That's right. >> That's huge.

>> 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.

>> 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, because like you said, when the SEC, Securities and Exchange Commission, gets (chuckling) involved and says, "Hey, we're going to fine you if you don't disclose these things," 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 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 has 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 throwing 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." 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, right? 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, 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 microcode LLMs.

>> Code copilots or something.

>> Code copilots 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 bowling in something crazy without you knowing about it. The new part of that would be just the AI capabilities.

>> Yeah, well, we look at it, and we're always dropping SBOMs on this show, so we love having you guys on, Brian and Taylor. Tyler. I'll get it right. I need more coffee, I think, already. (everyone chuckling) And Dustin, thanks for coming on board, and thank you for watching "theCUBE," the leader in high-tech analysis and news. We'll be back with more from KubeCon/CloudNativeCon EU in Paris. Stay tuned. (bright music)