Transcript for "Founder's Panel": This is James Governor. I am, one of the cofounders of a company called RedMonk. So RedMonk a research and advisory company. Basically, what we do is we try and understand the world through the lens of the developer and the engineering team. So, you know, when we're looking, at, the market, when we're looking at technology evolution, when we're looking at how infrastructure is deployed and why it's deployed. We're really looking at those decision making factors that are driven by and that affect engineers rather than just sort of top down. We are not out on the golf course. We'll hopefully talk hopefully talk to developers every day about what they do, how they do it, and that's how we build the world view. I am super excited today to be here with Tango founders. So this is a company, story history, in at least in terms of of the founders. You've heard of them. Otherwise, you wouldn't be here. But I'm gonna, I'm gonna lay out a bit of landscape, and then I'm gonna hand over some intros. So here's the thing. When we think about security, certainly from the position of, how it's been done over the past years, really, security has not kept up with application velocity. Thinking about the platforms that we've rolled applications out onto, and, generally, that's been Linux, those distributions, they were built for a different era. Practically, it shrink-wrap software. Changes were seldom. Changes were gonna happen every six months. They're gonna happen every nine months. So it's like, get it out there, pour a little bit of concrete onto it, and hopefully, we'll be good. Obviously, application development today has moved on a pace. We moved to containers largely rather than VMs. We are seeing multiple deploys a day. It is all about the pipeline. And, the the disjunction between security and, application delivery is getting harder and harder. And we've got the velocity, but we're not doing a good job in terms of how we can maintain security. And, of course, the threats are increasing. So, yes, we used to move slower while the the the the the threats are increasing. We're seeing more CVEs. We are seeing, well, in fact, one of the problems we've now got, and we may talk about this a bit later, is AI thought on entering these CVE chains. So there's a lot of challenges in terms of how we manage security. Security is not keeping up. Apparently, Chainguard is gonna help us solve some of those problems. So let's talk to them. Really proud to have some founders here. So first of all, Dan Lorenc, would you like to, introduce yourself? Sure. So I'm Dan Lorenc Lorenc, the cofounder and CEO here at Chainguard. We're about three and a half years old now, but I spent about a decade being a developer, being one of those people James used to talk to, before now I spend all my time on the golf course. But yeah. I understand, front and center kinda the the trade offs and the dichotomy that's emerged as developers have more control and start moving faster in this containerized world. I'll just jump back into that when we get through the intro. So Awesome. Ville. Yeah. Hi. I'm Ville. Also one of the cofounders, currently, an engineer. I spent most of my, adult life in building tools. I'm trying to make developers' lives easier. Sometimes maybe even succeeding at it. And here we go again. Okay. Awesome. And last but not least, over to you, Dustin. Yeah. Dustin Kirkland. Not a founder, but, joined two years ago to lead the engineering team here at Chainguard. Certainly proud of what we built and what we are building, and, I think I can, certainly speak to the developer experience around using, something like Chainguard or, or not and the pain that comes with, with and without that. Okay. Awesome. And you came from that old world of those that previous era of distros. We may talk a little bit, to that. But I'm always interested in sort of founder motivations, and why decisions were made. So if we think about Chainguard OS, and the realizations you had, what was it that pushed you forward, Dan, that this was the direction the company needed to take? And tell me a little bit about that story. Yeah. I wanna come back to something you kinda started with there. Containers, developers moving faster, security threats rising. Docker and containers solved a lot of problems for developers. That's why it's here. That's why everyone is using it. But one of the problems it solved, was that if in the old days, developers couldn't just go install extra system packages on the places their tools were gonna run. Those were managed by a different team, an ops team, somebody setting up these servers, somebody configuring them, and you got to write your little Python app, your Java app, and it got dropped on. And you can only use the stuff that was on there. If you needed some extra dependency. It was filing a ticket. It was waiting for the ops folks to go install that everywhere. Mhmm. And then you could get this stuff. And there are typically approvals baked into that too. Couldn't just go say, hey, ops person. Can you run curl pipe to bash to get this thing out to all of our production servers for me? There were checks. They were used to getting things from trusted places, typically distros. Even things outside of that, there are exceptions and approvals processes, those kind of things. And Docker solved a whole bunch of local development problems, works on MyBox. It's it's an amazing packaging format. But one of the problems it's all for developers is that they didn't need to go ask for permission anymore to install extra things around their application. In that little Docker file, you get to write whatever you want. You get to run app get install or you get to run curl pipe to bash. And it's just a single code review for someone else on your team away now for making it into production. So it gave developers a lot of power and a lot of control without having to go ask someone else for approval to get this stuff configured. And that was great. Docker got installed everywhere. This is admin. We're sick of getting bugged to install this stuff too. And that led to kind of what everyone is facing today, which is a little bit of the wild west. You give everyone full control over the environment their apps are gonna run-in. They take advantage of that. And now all of those controls and checks and balances are missing. And we talk a lot about shift left. All that control has already shifted left. Now security is kind of in this spot where they're trying to sprint back over to the left too to figure out how to put the good parts of that process back into place. And so Chainguard OS, is kind of us trying to reimagine that. And what if we can give people any of those packages, any of those tools, any of those systems, any of those language libraries, any of the open source components they might need, one command away from a developer, but with all of those trust and patching and security and curation guarantees. If you can get the best of both worlds? Give everyone any of those tools they might need to install one command away inside of a Docker file, inside of whatever tool you're building without actually opening up that supply chain, without actually opening up and punching a big hole in your security posture. Make developers happy by letting them get their job done quickly without actually causing a nightmare for security that to go fix later. Okay. But other than that so beautifully comprehensive, I'll go there, Dan Lorenc. That certainly talks to motivation, certainly the way the world has changed. I mean, I do think that's one of the the key issues to me as I see it is is that that that the, as I say, the the the velocity wasn't matching the the the stability we were aiming for. And there has been this organizational mismatch where, security is is frankly I think in very often, it it's like a cult. It's hopeful that it can go and, you know, oh, wait. If we buy if we you know, just I still see it every time I go into the you know, it's always amazed me. You can go to San Francisco to FFO and land, and there will always be the latest and greatest security appliance. It's always called, like, silver something. It's silver barracuda or silver something, and it's like, install this and you will have security. And I'm like, that has literally nothing to do with the new world. I can tell you've been in the San Jose Airport recently. That's what it feels like. Do it. Right? So you go to the airport. You still see this stuff. And it's like, if we if we just buy this thing, we'll be secure. And as you say, you know, living in a and, you know, some of this is is is is change is hard. No doubt. But but but the guardrails were a problem. So, Dustin, you know, given this this world that Dan's described so accurately, from an engineering perspective, what went into ChainguardOS? How do you deliver on, the the the the problem space and making it easier so that developers and security perhaps framework more closely together in the world that that that Dan is describing? Yeah. You know, I would start with a rolling distro. That that idea is not new necessarily. There's long been a Devel stream of Debian Devel, Fedora Devel, Rawhide, Ubuntu Devel, Alpine. But no one up until now has really been able to take that and, harden it into a way that it actually can be used reliably in production, used in anger by someone whose job is on the line every single day deploying and maintaining, production apps that run, you know, airlines and retail establishments and health care and defense applications. And that's exactly what we've done with Chainguard OS. We've taken the latest and greatest open source software as well as libraries, third party open source libraries that never existed as operating system packages before. Put that all through a build system that is constantly asynchronously monitoring tens of thousands of open source projects, automatically applying build rules to rebuild, retest, requalify those. And then in the case where there are static build dependencies, the Golang and and Rust ecosystems, to automatically rebuild all of those as well. And to do that in a way that end to end works and then at the end is published, a a a a signed certified well tested package, and then put all of those together into a signed certified well tested image to be able to do that, you know, practically hands off self driving, that's what we built with Chainguard OS. K. And I mean, I I think one of the things that I I find you interesting from from your perspective and, you know, this is always true when a a sort of category is is is being created. You know, there hasn't been a change here. You know, I think that we we sort of moved from from documenting what we were doing, this notion of of of an f bomb into more active management. As I say, use that word guardrails. I think one of the things, hopefully, with with with a platform like yours is is allowing developers to have that freedom that Dan talked about. We don't need to ask for permission, but, also, hopefully, we're not gonna cut our thumb off. So what was the the sort of the transition from being, describing things to understanding that actually it was your role to hardening the environment and owning the environment? Like, how did that how did that, realization come? And then from an engineering perspective, again, you talked a little bit about how you delivered on that. But what was the realization that you had to be taking more responsibility? Is is that the right thing to do? Yeah. I don't know that there was a realization. I think we kind of always knew we had to do that. And, you know, we call it TrainGuard OS. All names are terrible. Right? I think this is the best name we come up with for this because it is an operating system. But we're trying to break down that wall between things that traditionally come from an operating system and then things that traditionally come from all over by extending our operating system, our OS to cover all of the things that normal operating systems don't cover. So we kinda started working backwards on this. There's traditionally that notion of like an OS package. Like, you might install c stuff or open SSL or these things that are traditionally provided by an OS. But then if you wanna run a Python package, you get that from somewhere else. When I first started learning how to code probably fifteen years ago, it was in Python and, matplotlib and NumPy and all these tools that you still can't figure out how to install in the first time with PIP. I mean, sorry. Python package management hasn't really evolved, much in the last decade. But at the time, I was running some Ubuntu probably, 10 or 12 dot something release. And, you'd Google how to do stuff and it would say, well, you you can either run app get install NumPy, but then it's old and none of the documentation you find on Stack Overflow actually works because it's an old version. Or you run PIP install NumPy and stuff gets clobbered over and you probably have to reformat your system in between those two things. But if you do that, you get the right verb. And it was like, well, why are there two different commands that do the same thing and why would I ever run that old one? So me as a developer just happily starts running the PIP one, going forward. What you don't realize because the UX of those commands is so similar is that the trust and hardware integration and patching guarantees are completely different between those two ecosystems. And I think that mismatch is one of the key ones that we've been trying to break down as we build out this OS. Okay. Okay. And Ville, yeah, I was about to ask you to talk can you jump in? Tell me about that mismatch or or your thoughts on that. No. I I think it ties it back into what we're just talking about earlier, which is, like, developers just wanna do the right thing. Like, nobody wants to do the wrong thing. Right? They just wanna go and build cool stuff, and, they just wanna go ahead and get there. Right? Nobody's going out there going, like, I'm gonna deploy shitty software. Right? It just like, hey. I need that stuff. I need the newer stuff because I'm gonna use the coolest things. And, it's just too hard. Right? Like, why do I have to have a PhD in in something just to go and deploy my coolest little visual basic cap? It's visual basic is still cool. Right? Yeah. Okay. I don't know what but, Ville, talk a bit more about that because I do Ville, sorry. If we think about developer experience, what are the key things that you have done from an engineering perspective that have allowed this, the developer to just deploy their cool VB app? Like, what what what what what why do you what what what have been your, like, north stars from a developer experience perspective with ChainguardOS? I think it truly is that you can go ahead and and pick the latest and greatest and not have to worry about anything. It just like it's it's it's sort of kinda like I I like, one of the things that App Engine, I think, got right was sort of kinda like well, Google originally got it right, which is, like, I think of Google search boxes. Your problem goes here back in the day. Right? And all of that was a box. And you're like, I have a problem. And you paste some stuff into Google, and all of a sudden pops out the answer. And you're like, okay. Cool. Now I know. You solved my problem. Thank you, Google. App Engine sorta kinda solved that long time ago, with the your code goes here, which is like, this is the only code you have to worry about. About. Right? Like, put your code here, and we'll run it and carry and feed it and everything else. There there there's other things with it. But, that model is really awesome. And I think one of the things that we should be able to provide is for developers to only focus on their stuff. Like, everything else is just flat. I need this thing, but all I care about is my cool stuff. Right? And that's where we are trying to go with this. Okay. So a a a bit of a Paz like experience. Dustin, having having, sort of, well, I mean, you you you you've got you've got the battle scars. You've been in this for a long time. Operating systems, you got a rich, history in that area. Tell me a bit about, like, sort of where you were and and and, I guess, where you see Chainguard taking this. I mean, this question about Distroless, I think, is very interesting, to me. Anytime you get an industry transition, that's significant, because not to put you find a point on it, you know, a lot of people are quite comfortable, in a world of distros. So tell me a bit more about distroless, how it's different, and how you see that industry evolution. Yeah. I'll just I'll I'll start with that thing that we've been talking about, which is just the freshness of the software involved. I got my start in Linux in the in the mid to late nineties as a developer at IBM working on go figure a build system, that had to compile a whole bunch of IBM Tivoli software across a dozen different UNIXes and two Linuxes, SUSE and Red Hat at the time. And I remember this is probably '97, '90 '8. I remember loving Red Hat and SUSE because it was so new compared to Solaris and AIX and HPux and, digital UNIX and IRIX and all the old UNIXes where everything was ancient. Make was ancient. GCC was ancient. GLIB c was ancient. But, you know, circa nineteen nineties, Linux was just so much newer. Let's fast forward, you know, five or ten years. Debian, Ubuntu came out of that. You and I know one another from my days in the Ubuntu world and canonical world. Ubuntu managed to push that Debian envelope quite a bit by, you know, fast forwarding or snapshotting Debian every two years and doing that reliably April of every even numbered year and coming up with an Ubuntu LTS and freezing the world with a good set of known best versions of everything, you know, circa that time frame. And for, you know, a solid decade or more, that's been, state of the art. This idea, though, of the the rolling distro, that's something that has been an albatross for a very long time. But I do think, you know, if we you kinda started this off with containers, and Dan mentioned the works on my laptop, shipped my laptop, that was the moment I had around Docker, and I was I was working on Ubuntu at the time. And I'd been around containers, Solaris, BSD jails and Solaris zones and LXC. But what Docker made amazing was that experience of this works, ship that thing. Yeah. And out of that, you know, was born Kubernetes and being able to do that at scale. The chain guard value prop I've worked on a lot of products in in twenty five years. This is the first time that I think I can explain what we do in the value prop of it in thirty seconds in an elevator, like the elevator pitch but literally in an elevator, and someone goes, oh, wait. Zero CVE container images or zero CVE, VMs, libraries built fresh with CVE remediation, that it clicks immediately. And it's kind of it's kinda crazy that no one's actually done this, until now, until, you know, Chainguard managed to productize that and build, you know, a really remarkable value prop and and healthy business around that. Okay. So I'm a big believer that the best packager in any technology wave wins and wins big. I mean, I guess Docker in some ways isn't the best example of that because they did a phenomenal job of packaging some things and obviously didn't necessarily get the outsized returns, they might have done. But in terms of this packaging, because because one of the things you're doing is putting things together in a way that it can be consumed by enterprises, that it can be consumed by organizations that want to build more secure software. I I guess the question for me is or or a question, does this replace the traditional distros? Should they be worried? I'll I'll take a first step and say that I think we're past the point in the industry where a given enterprise, a major enterprise, is all in on on a single distro. And, again, that container layer allows one team of developers to have, an application base. That's one thing. And a different team to do a different thing. The idea of we're a Red Hat shop or, you know, we're a Solaris shop, that's it's just that that was the case when every machine was a pet and not cattle, and you spent hours picking the right host name for that machine that you were gonna SSH into for a decade. I think we're at a point now where I a Chainguard OS is a great replacement for, you know, parts of the infrastructure for many base app base images for you to build your own applications on top of proprietary work on top of, a a great replacement for some application images that, you know, need latest and greatest and or really want zero vulnerabilities. And then what we were doing around VMs certainly as a place where, you know, we were hardening entire virtual machine images to the same standards that we have with with containers. But I think the world is a little more heterogeneous than, one distro coming in and sort of wiping clean slate and replacing everything. At least that's that's that's my view. Okay. I mean, that's an interesting one. I mean, partly because, you know, sometimes in, selling software, you know, that that's what you're doing. It is a job of sales, and some of those, incumbents, have, Salesforce that are pretty good at persuading, customers that they shouldn't change, that they should keep doing what they're doing. I guess, from an objection handling perspective, I mean, Dan, is that part of the story that you're like, oh, no. It is heterogeneous now. Don't worry about it. How do you handle objections? People that say we already have, we already have a distro story in place. We can build security on top of that. Yeah. Well, we have 1,400 different images in our catalog today. You You can look. The overlap between the software in those and the software traditional distro will sell you is probably, like, 15. Right? Most of those things are, like I think I saw you at KubeCon London. We ran into each other. That CNCF landscape of software, that's growing by, you know, 50 new projects a month as things get get added in there. That's not part of it, most Linux distros. I just saw another thread yesterday about Debian trying to package Kubernetes for, like, the seventh time. There are ways that, that CNCF kind of native cloud native software moves that's just not compatible with three year, five year LTS landscapes. There is an overlap, but the overlap is not very large. There's just a lot of software you can't get any guarantees on today. So that that's basically the answer. You are heterogeneous if you're running software that comes from outside of your Distruro's package manager, and everyone in the world is doing that today. K. That said, it was interesting, the recent move. I mean, you know, you know, we had, Dustin's elevator pitch, which was very clean until suddenly we have to mention VM. So when when did you all decide that it was like, okay, Dan. I'm I'm like, actually, you know, some customers are gonna continue with VM infrastructure. We're gonna have to be doing a better job for them as well. What was tell me a bit about, like, the market feedback, and and maybe we'll ask, Ville as well about the engineering challenge. So, Dan, do you wanna talk about, like, the market and when you knew that that was really something you needed to do? Yeah. There's just a lot of software that doesn't containerize well and isn't going to containerize well for some reasons. Databases, anything with persistent storage, things that need to be closer to the metal GPU, high CPU intensive workloads. And a lot of people are running those in container native ways even though they're not inside containers. These are BMs that are immutable. They're booted up. They run a workload. They stop. They're gonna persist and disk attach somewhere that keeps state running along. And opportunities basically do the same thing that we do for our containers just now with a kernel. We talked about distroless, a little bit earlier. My cofounder, Matt, who's not here today, Will and I started that project and named it. And one of our first rules of names is that, if it makes people a little mad, it's a great name because then they start talking about it. The secret for distro list was that there was a distro there. We just deleted parts. So it wasn't really distro list. When we started naming, this, we first called it an undistro, because it was a Linux distro that had everything but Linux inside of it. So how do you how do you call it a Linux distro if you don't have Linux? This was alright. Well, we have all of the other components. How about we finally add a kernel? And now all of a sudden, we can cover those workloads that just don't containerize well. K. I mean, I and I I mean, it's interesting because either of those are likely to annoy people. Certainly, there were many people raging about serverless. You know? That was a a a similar one. It was like, well, you know, there's really a server there. So so yeah. That that, you know, that that that pattern applies. From an engineering perspective, dealer, like, you know, initially, we're in the elevator and there's one clean story. You know? As that as that broadens out, I mean, did you always know it would be broader or from an engineering perspective, what are the biggest challenges in being like, okay. Now we're gonna support other environments as well? Well, a lot. But I think one of the things that I think I just if you mind if you don't mind, one of the nice things about the containers is the fact they are immutable, and that basically means that it lends itself very, very well to the, roll things forward and don't get too attached. Right? We were taught not to say pets versus cattle, but I'm gonna say it anyways. So, you know, it's with the containers, you you got out of that. You're like, okay. I'll just roll forward. And I think what the so VMs are good for, very many things, but, one of the things that are not very good is that it, they they far too often are, very much like pets. So with the distros, you have to really care about them and feeding them. And while you have, like, ways of ghosting them or AMI ing them and all those different things, nobody was doing them. So with us, we are basically saying, like, okay. Cool. One of the things you can do is you can go and have that fairly similar experience going into the the VM land. It's all immutable. Right? And the immutability becomes, so many great things. Anyways, so back to the building things, it's hard. And we are basically writing, a blog series about this one and and talking about how, how difficult it is. But, you know, we are getting pretty good at it given our, years of experience in this. So we can we we learn we learn, we can reuse, and and and so forth. Yes. Okay. I think I think Dustin wants to jump in. So go ahead, man. Yeah. I was gonna add. I I think the elevator pitch is still still, you know, quite simple and elegant. Safe source for open source was what we started out with. The hardened container images was an immediate problem that we solved for a whole bunch of customers. Some of those came to us and said, look. We're Chainguard wall to wall. Chainguard has zeroed out the the CDs inside of our container images, but guess where every container in the world runs? On a VM. And and, you know but our VM still have vulnerabilities. What could you do about that, Jane Garde? And so we took a look at that. I see some of the questions in the q and a off to the right. Yes. Oscar, you heard it right. We will also build VM images. As Dan said, some of those are container hosts, but it doesn't have to be a container host. It could be some of the workloads he mentioned, something like a network, application workload that has to run a a very specific kernel, has to load specific modules, maybe some eBPF or container profiling. You've gotta do that at that at that container host level. We're building those now. Some applications any any application in our catalog, we can render as a VM appliance, essentially an immutable appliance that you you replace that node whenever you need to upgrade it, treat it like cattle. Instead of naming it, you know, Ganymede, it gets a name B487 5 C 2. And then it's just, you know, one of the the many, many running in your in your infrastructure. Right. Right. So Yeah. Coming back to the market piece a little bit because you touched on that. I think I think we were put off a little bit early on by, a mismatching, revealed preference versus stated preference. And we we we talked to a lot of people about this and they'll say, oh, yeah. We've got some VMs over there, but we're trying to shut them off. Don't worry about that. And a year later, you say, oh, yeah. We still have some VMs over there, but we're trying to shut them off. Don't worry about that. And a year later, we still got some VMs over there. Don't worry about them. We're trying to shut them off. And then you go and ask, and that number has actually gone up each of those years. They tell us that they're they're not worried about those and they're trying to shut them off. I'm sure you've seen it, in the market analysis data. You you only need to look at Broadcom's business. I mean, you know, that's not the happiest, custom based, the m y right now. And, but, you know, the numbers, don't lie. And, yeah, to your point, yeah, that that was, that that that entrenchment is very real. Yes. K. So talking of of of customers, happy to to to pay for things, it's kind of interesting. I I I think that if we go back, you know, even, like, a couple of years, you definitely didn't have those sort of you hadn't hit the the the knee in the curve in terms of logos. I mean, it's very noticeable to me you came. I had a briefing with you a few months ago, and just the number of, like, serious enterprise logos you have is is very impressive now. Right? So one of the things there that happens is you as you you establish product market fit, you get success, you are established in this category is that we now see other entrants, coming into the market. And they're like, okay. We can we can do something similar, and we can make a similar sort of story. But one of these are like, oh, and they wanna go and say, Chainguard is expensive. And so, Ville, like, tell me about like, what do you say when someone says, oh, no. Chainguard is is, like, a little bit expensive now? Well, you sometimes get what you pay for. And in this case, you definitely get what you pay for. Right? So, it it it like I said a little while ago, the things we are doing is hard. You can certainly go ahead and do things, that, may look and, seem the same, but they don't, you know, taste the same. They're not quite as good because you replace things with CPU mutations or tricks. Building the right things takes a lot of work, and, you know, you can you can do your own due diligence, and and look at us, and we are worth it. And, it's it's And so I think the question I actually meant to ask was about building a better mousetrap. Yeah. Well, did you like mice? And we'll also perhaps just get a cat. So Shengard is the cat of container security. So we talked about objections, talked a bit about the market there, this this this sense of of of category creation. Yeah. So slight change of gear, you know, which is looking to the future. Now, it's 2025, and we've managed to get through quite a lot of conversation, without mentioning AI. So I think we we probably, are about that time. You know, particularly, I think, you know, with technologies like MCP, which seem to be, potentially, a security nightmare waiting to happen, chances of arbitrary execution, lots of things talking to one another. There's all sorts of traffic you don't know about. People are building applications, using, components that they don't fully understand. Like, what's the this question for Dan Lorenc. Like, what is the the the opportunity or what's the the the opportunity and the threat? Are you able to keep up with the growing challenges that AI is gonna create, going forward for, your customers? Yeah. I'm an AI optimist. I'm I'm vibe coding right now. You can't even tell. Yeah. Twenty four seven. Yeah. I think, you know, AI is real. It's here. The results are you you can't ignore them any. If you're like a lot of people, even like myself, and you you've been trying this stuff out for a while and, you you there are a couple of wake up moments. Right? Like, when Chachi b t first came out that one Thanksgiving, it was like, wow. Holy shit. And then after a month, you're like, okay. It's not that cool. And you try it again and you're gonna get some results. You start getting hallucinations. You get a little bit more with it. Then you have another one a little bit later when the models actually start getting good and they start to look at real results. And I've been trying all the tools and your Copilot's been around actually in GitHub since before ChatGPT. A lot of people forget that. GitHub Copilot was the first consumer, LLM application. It was three days Chachi PT. And it you know, people are using this without even realizing it. They forget, the power these tools are bringing. But over the last couple of months, this was a progress a lot too. And it's not just the models themselves. It's the way they're being integrated into other things. MCP is one part of that. Yep. The model strength, I think, has been there for a while. It's the ability to feed in the right context at the right times that is dramatically improved. MCP is great. It's coming along the way. I love the protocol. Know, the plug in tools and have the agents figure out what data they need and I get it. But there's a couple of security angles you have to worry about too. The biggest one I'm worried about though is kind of ecosystem wide, which is that security teams are rightfully the most scared of this stuff. And when it when you're in a space like this that's moving this quickly, the gap between people using and taking advantage of these tools and the people that aren't is getting wider and wider every day. And one of these curves is going like this and the other one is going like this. And so you might be three months behind or four months behind, but that gap in those three or four months is getting wider every day. So you've got, more people writing more code with AI. All code has bugs, so there's more and more bugs and security issues that have to get addressed. And until security teams get fully on board and figure out how to deploy these things themselves, that gap is gonna get even more. AI is gonna be the cause of and solution to all of our problems. We have to minimize the gap between the cause of and the solution to part here as quickly as we can. Can I say something? Are you bot coding right now too? No. I have so shitty bandwidth right here. But, it it I can't help but to feel like this conversation could have been had, I don't know how many years ago, and it would have been about containers. Right? Yeah. Which is I look kinda like we are just having this conversation that is all about, like, okay. Cool. Well, Dan Lorenc just wants to pull the latest model because whatever, and he doesn't know what he's running right now. Right? He's probably he thinks he's white coating, but he's really mining Bitcoin. Right? But, like, it's interesting to me. Right? Because we are having that very same conversation right now because developers just wanna go ahead and pull out, like, oh, let me get that MCP. Let me get that MCP. Let me try this and and and and so forth. So I just find that interesting. That's all I have to say. We we we keep seeing the patterns. The patterns repeat themselves, you know, much like the fact that look. At the end of the day, this is just a I mean, what what we call shadow IT. This stuff is definitely gonna use to Dan Lorenc point. There will be people in the org that you will have orgs that say, we don't use that. Or you can go out to an enterprise and, you know, we saw this through multiple generations. Oh, no. You know, we we, you know, we we would never use Linux, you know, in our, you know, networks. It's like, are you stupid? Just talk to the network people. They're using Linux. Or we would never put our customer information in the SaaS platform and it's like, have you talked to your, I mean, have you talked to your salespeople? Because I think you're finally using Salesforce, you know. We see this over and over again. And and to Dan's point, I think that that that that means you're right, Ville, that the the challenges have some commonality pattern, but, of course, that doesn't make them any more real. You're gonna have a bunch of people that are gonna use the cool new shit regardless of whatever the enterprise thinks, whatever security thinks. And so from that perspective, yeah, we're gonna need, better tooling accordingly. So we we talked about sort of AI. Obviously, it's an important topic. Into the future and, obviously, you know, there there are some sort of limits to what you can say, but I you're all imaginative, folks like Dustin. Like, how do you how do you see the future of security and the future of Chainguard? How are you gonna be able to resolve this the the this challenge of of of security being slow and application delivery being fast? Like, Dustin, what what does the future look like? Well, I think this is, it's constantly evolving, especially the the threat and the threat actors, and our goal is to keep ahead of, of the threats and the the threat actors. I don't know if it's this year or next year, but it we're we're we're close to a point where if we take all the code that's gonna be written in that year, especially with five coding and everything like that, it's gonna amount to more code than was written in the previous twenty years combined. It is it's really moving that fast, and it's because machines are writing code and deploying code and operating code. And this is, you know, sort of the that next phase of agentic AI revolution where it's more than just AI being a better spell checker, helping you fix your mistakes or do your things faster. We're at a point now where we're gonna build a machine that builds machines, and those machines are are are are running. Security in that is pretty untouched, in that this is evolving so quickly now. Scanners aren't aren't able to to keep up with that yet. So, you know, what does the future look like? I I think we're gonna have to see step function changes in AI's ability to, quality assure and maintain the security of those machines. Like Dan, I'm pretty optimistic here. Maybe not quite as optimistic as Dan in in some places. If there's if there's a gap, you know, running a team that's building the code, there's still a long way to go for some of those tools to to reach their their potential. But we've got line of sight on what the what the what the light, at the end of the tunnel, you know, how far away that is. It's closed, James. It's it's right here. K. So, Dan, the future. What's the future for the industry of the Chainguard? Chainguard OS. Yeah. I think, you know, today, the way most people if if we're gonna stay on the AI team, today, the way most people are using is the way most of the tools are designed is, AI helping people go faster. I think the the closest shift that we can predict is that flipping. People helping AI. You're injecting intelligence every time an AI agent gets off track. That improving that agent for the next time. And then the whole, agent ecosystem getting better each time one of these agents gets wrong. If you've been in a Waymo in in San Francisco or anywhere, self driving cars are here now, and they're all over. And it's that same kind of premise. Right? Every 16 year old that gets their driver's license has to get into the same couple accidents to learn the same couple things. Every time a person, gets this, that learning is only to them. Drivers get better as they get older. These self driving cars aren't perfect. Every time one of them gets into an accident, every time a person has to correct one, the whole fleet improves. That's kind of the the flywheel that is now spinning and it's gonna keep spinning even faster. Well, kids don't want cars so much anymore, so it's good that they they That makes me feel better on the roads. Okay. So, Billy, what what about your your any any thoughts on the future, or are you too busy working on the the current current challenges? You guys got some kids on the road right now. Yeah. And it's it's very expensive, it turns out. Yeah. Yeah. No. I mean, I I there's a lot of work to be done, and, we just keep improving things as fast as we can. Right? I mean, yeah, there's the future is gonna be terrible as far as, like, it's gonna be really like, everything is so everybody's attacking everybody, and we just have to work hard at it and use the tools available to us. And that's where we can definitely go and, leverage, some of the AI tooling to go ahead and, do things faster and better and stronger. So, I mean, it's a double edged sword. Yeah. K. One thing I I should've got to the questions earlier because there are some good ones. So thanks for that, Mila. That's a that's I mean, yeah, everything everywhere all at once. As you say, so many so, you know, so many threat actors. But, government threat actors, Graham Voss has asked a question. I don't know which one. I I I'll give this to, I'll give this to Dan. As long as you rely on CVEs, how are you staying ahead of the threat actors? By the time the patch is available, the damage is already done. I'd say a couple of things. Yes and no. There, there are stats, average, like, fourteen days from the time a CV is disclosed to the time average, exploits happen. That's just the average. These things, vary. Trying to speed up that time from time a CV is disclosed to a patch is available to that patch actually being rolled out inside of an enterprise. Minimizing that window is huge. Yeah. There might be an exploit, but the state of the art today is, you know, that ninety plus days from the time that patch is available. So the time it's widely rolled out inside of an enterprise. We saw this was logged for Shell. Everybody panicked over that weekend, got fixes deployed, But then something like two thirds of enterprises accidentally redeployed vulnerable versions over the next year, because asset inventory and management keeping track of all these things is harder. So even with CVEs and even with those windows and those known patches, there's still a lot of room for improvement, to minimize that window. But CVEs are just one of the data sources we look at. We also do much of our own detection, look for malicious code, and filter out whole malicious, attack paths by building things from source. If you look at the the malware risk, which I actually think is much bigger than this u u risk at the end of the day, most of that isn't injected into the source repositories. It's attacked somewhere along the way from source to built thing you are consuming. You know, that's great two factor auth. It it's almost required, to log in to GitHub to use two factor auth. Same as your bank, the same as any website, it, takes security seriously. But PyPI, NPM, two factor auth, adoption for those is minimal. Yep. It's crazy. And so just by building from source, we also eliminate huge amounts of risk from malware along that supply chain. Source based malware is a thing, but it's so uncommon because it's so easy to slip it in later where it's harder to detect. So CDs are just one piece of the overall puzzle. They're the one that usually lights up the dashboards the biggest and it's easiest to quantify, and so regulators focus on it the most. So we talk about it a lot. But that's just one piece. Yeah. NPM security. Oh, what a fucking nightmare. Excuse me. I should have lost all that. James, can I can I have one I wanna add one thing to that, which is if you're worried about zero CVEs, I certainly hope that you've, you're CVE free, first? If you're worried about sorry. If you're worried about zero day vulnerabilities, let's talk about being CVE free first. You know? If you're worried about finishing a marathon, worry about getting to the starting line in the six months it takes, to get there. That that's where I, you know, I would say, yes. That's a real problem. But first of all, why don't we apply all the fixes that are known and available first, and then we can worry about zero days? So Aaron Miller says, I kinda don't feel that James could pull off a mean Michael Palin impression. I don't know that I'm gonna do one, but but I I mean, it certainly made me think. Simon Bennett. And I don't know if this is the Simon Bennett, but I I certainly know a Simon Bennett. And if it is you, hello, mate. So also complete was the Vibe Coding MVP. How could Chaingard help developers make better choices on their dependencies when they first pull them in? So yeah. Like, that guidance, is that a role for Chainguard OS? Is that a role for you? Dan's sort of nodding, so I'm gonna give this with you as well, Dan. Yeah. That that's our library's product. We in in some ways, we don't want you to have to think about the choice. We want all of the libraries that you have available to be safe. People talk a lot about that, like, don't pick the insecure version of the library, pick the secure one. I think there's probably too much focus on that in the industry. There aren't many cases as a developer where you're like, which library should I use for this example? And there are five that I get to pick from, and this is a critical decision point for my future security. For most of these, there's only one or two. Two at the max. You don't really have a ton of choice in which library for a specific task that you're actually trying to do. And I think that's probably for the best. Open source doesn't have tons of resources available. We all know that. If there's a critical library or a critical tool that you're gonna be using, we're all better off if everyone is collaborating on that one thing and have everyone fragmented or working on five GPU versions of JSON parsing or HTTP clients or web servers. There are cases where there are multiple of them. And, in those cases, they're all pretty much the same. You're not gonna make a security risk by picking the wrong one. But we wanna make them all safe. And that comes down to how they're built, how they're maintained, and how they're patched. So the future I would like to build is one where you don't have to worry about the library. Everything you have available is safe. K. So Dylan was not vibe coding, but he was answering questions in the chat already. So, we did did have a question with Jeremy Jeremy McGee, about container 30 VMs. Ville Aikas has answered that. Sam has also been pretty great in answering a lot of questions. Let me see. Oh, here we go. Edward Newman. Dan has been publicly sorry. They're all going to Dan now. Dan has been publicly skeptical about s bonds. Oh, yes. What should the industry be doing instead? Anything. Yeah. No. I think I think there's there's a time and a place for s bombs, but I think we are nowhere near it in the broad application of them and the regulatory push from the government, is completely ill informed. And, you know, my my biggest criticism is is is that, the government's role. The government doesn't have many hammers to mandate things in security, and choosing to waste one of their biggest weapons on s bombs, is just a massive misuse in government time and energy. And then all the time and energy is gonna cause companies to have to figure out how to create these s bombs and what to do with them. The the value of them is it it's pretty limited to be honest. That's where you get all of the skepticism and pushback. Kim. I'm pretty sure the threat is inside the building, but we'll leave the politics aside for a minute. Sorry, Dan. Over to you. On the SBOM one, I I'll I'll step a little away from Dan on this one and say, it's just the the list of ingredients on the side of the cereal box. I'm glad it's there. It's not gonna solve any problems, but I'd like to know what's in what's in my cereal. It lets me be a little better informed, about the software I consume or the cereal I consume. I think any regulation around it is probably overblown. Go, you know, go focus on the quality of those ingredients. But having the list of ingredients, the Espolon, to me, certainly adds value. Because yeah. Got my you know? Go ahead, Vivek. Yeah. I was gonna say a little bit of aligning with Dustin. Always, Dustin is my boss, so I usually align with him. But, you know, I I mean, I think the s bombs too, it's that there's levels of s bombs. This is yeah. I see Dan smiling. But the the they're sort of kinda like, what are the ingredients? I'm gonna, a little bit more on what Dustin was saying. They were sort of kinda looking after the fact, which is like, let me look in this case and try to figure out what's in there versus sort of kinda hand curating the s bomb, when you're building it, which is what we are doing. So, there's different levels of quality. I'm not saying it's the answer to anything, but I do agree that it's it's useful to know what you have there. Unfortunately, it also is useful for, the the, non friendlies, but, I think it's good. K. So this is a very I think this is from from Graham again. This is kind of a question I it feels like the question that I asked about objections. Like, an enterprise is trying to get their head around it. So Graham lost another question. I put some q and a in place in here. You guys talked about approvals needed to install an Apple package and how Docker made that easier. But if there's a new OS released with updated patches, do we need to update the OS? I just wanna make sure I understand how this works in terms of updates. Updating the operating system often is not trivial and often requires a lot of testing and approvals. So I guess that's definitely I don't know which one you want to take that, but, like, Chainguard OS. I believe you have some, something to say about that. Dan? Probably Dan. Yeah. I'll I'll take the secure the, sorry, the quality angle. If I had to, you know, put at its most basic what it is that we do that's valuable above and beyond anything else, it's the quality assurance side of things. It's the it's the level of testing that we provide at the package, the image level, the upstream open source tests and regression detection, the proprietary tests that we've written, back to making a rolling distro actually work and work at scale. That really comes down to quality assurance of that thing. Do you have to update if you wanna get rid of those CVEs? Yes. I will say that the minimization that Chainguard does, we're a minimal distro. We take that distroless approach. We've already started with the previous version that presumably worked and maybe the next one somehow regressed. You're already at fewer CVEs in that smaller base image that was newer when it started. It'll accumulate CVEs, but much slower than anything else older. And then I would compare and contrast it with the traditional way of making distros. You actually have a bunch of quality problems when you go from one major version to another major version of any enterprise Linux distro. You've just put off and accumulated that tech debt for two years between LTS releases or three, four, five years between REL releases. And, you know, you've accumulated all that, and it's it's more like breaking your leg as opposed to stubbing your toe. It's gonna take you months to recover from that broken leg. You'll be over the stubbing your toe in five minutes. And so by releasing early, releasing often, when you identify a problem, it's this much to sort of, you know, bisect and triangulate where the where the problem was introduced, and you're back up and running in, you know, hours to days if if you take the chain guard approach. There you go. Yeah. Can can I save one? Yeah. You can. Oh, thank you. You're so nice to me. But, yeah. No. I mean, I think it's more akin to, like, push on green. Like, how much confidence do you have in how you're testing your stuff? Right? Like, at any given time, you should be able to push on green. And if you can't, you should focus on that. K. There you go. Well, Chainguard wants you to stub your toe rather than breaking your leg, so that is good. I've had a lot of fun with this. So much fun that I didn't drop an s bomb. I dropped an f bomb. So sorry if you have sensitive ears, people. But security is serious stuff. Get get get exciting. I've had a great time. I'd like to, very much thank, the the panel today. Great chance to learn from, the founders, at Chainguard and, of course, Dustin, the work they're doing, trying to solve some very important problems. So we'll be signing off now. By the way, you should check out the Chainguard blog because there's some great technical content on there. But signing off now, it's me, James, governor, Aikas, Icus, Dan Lorenc, and Lawrence, and Dustin, Kirkland. So thank you all. And, yeah, you know where to find Chainguard. Thank you.