# Docker Hardened Images: Securing AI Supply Chains

**Podcast:** The Changelog: Software Development, Open Source
**Published:** 2026-02-04

## Transcript

Welcome everyone.
I'm Jared and you are listening to the Changelog, where each week we interview the hackers, the leaders, and the innovators of the software world.
In May of 2025, Docker launched Hardened Images, a secure, minimal, production ready set of images.
And in December, they made DHI freely available and open source to everyone who builds software.
On this episode, we're joined by Tushar Jan, EVP of Engineering at Docker to learn all about it.
But first, a big thank you to our partners at Fly to IO, the platform for devs who just want to ship, build fast, run any code fearlessly at Fly.io.
Okay, Docker hardened images for all on the changelog.
Let's do it.
This is the year we almost break the database.
Let me explain.
Where do agents actually store their stuff?
They've got vectors, relational data, conversational history, embeddings, and they're hammering the database at speeds that humans just never have done before.
And most teams are duct taping together a Postgres instance, a vector database, maybe Elasticsearch for search.
It's a mess.
Well, our friends at Tiger Data looked at this and said, What if the database just understood agents?
That's a gentic Postgres.
It's Postgres built specifically for AI agents, and it combines three things that usually require three separate systems native model context protocol servers, MCP, hybrid search, and zero copy forks.
The MCP integration is the clever bit.
Your agents can actually talk directly to the database.
They can query data, introspect schemas, execute SQL without you writing fragile glue code.
The database essentially becomes a tool your agent can wield safely.
Then there's hybrid search.
Tiger Data merges vector similarity search with good old keyword search into a SQL query.
No separate vector database, no elastic search cluster, semantic and keyword search in one transaction.
One engine.
Okay, my favorite feature the forks.
Agents can spawn subsecond zero copy database clones for isolated testing.
This is not a database they can destroy, it's a fork.
It's a copy off of your main production database if you so choose.
We're talking a one terabyte database forked in under one second.
Your agent can run destructive experiments in a sandbox without touching production, and you only pay for the data that actually changes.
That's how copy on write works.
All your agent data, vectors, relational tables, time series metrics, conversational history lives in one queryable engine.
It's the elegant simplification that makes you wonder why we've been doing it the hard way for so long.
So if you're building with AI agents and you're tired of managing a zoo of data systems, check out our friends at Tiger Data at TigerData.com.
They've got a free trial and a CLI with an MCP server.
You can download to start experimenting right now.
Again, TigerData.com.
So, friends, we have supply chain attacks caused 60 billion dollars in damages in 2025, triple what they caused in 2021.
Every language, every ecosystem, every build stuff, they're a target because who does not use Docker?
And Docker's response was to make hardened container images free for everyone.
We have head of engineering Tushar here today to dive deep into that and all the things that uh come from it.
So, welcome to the show, Chishar.
Thank you.
Excited to be here.
And excited to talk about all of that.
Where do we begin in such a deep topic?
I mean, you got vendors out there that had products around this.
You got the desire to secure the supply chain.
You have a brand to protect, you got developers to protect, you got build steps protect, you got a lot of responsibility.
I mean, it's a it's a big job you have, but where do we begin to unpack the reasoning and decision making behind this choice?
Yeah.
Maybe I can let me just talk about how how we think about supply chain, supply chain security and our current role in it, and then how that evolved into Docker Harden Images, and then eventually why we made it free and how we see that.
What exactly is Docker Harden Images?
We can just explain that too.
Perfect.
So let's start at the beginning, before you and that.
I'm gonna assume everyone knows Docker and Docker Hub.
Everyone builds containers, you use images.
Docker Hub is effectively upstream for open source container images.
We get billions of billions of polls per month.
Everyone pulls from us.
And these are the repositories or images of like you know, usable open source software.
And not just like upstream base images, but like, you know, I want MySQL on Debian.
You get that from us, that works.
Great.
We've been doing this for a decade.
But we basically keep up with upstream.
As a result, images do have CVs, they've lost the CVs caused by multiple reasons.
One, bloated stuff, bloated packages that are built for usability first, as a result of many packages in them, or just you know, not patching fast enough.
Hardened images, and this is a concept that you know has started the industry even before we launch a product, which is let's first minimize this problem.
What people started doing was we'll have scanners in production, they'll see when there's a CV, we'll go alert some teams, they'll have to go update and patch, and this is sort of the world that lived in.
Instead, why do we need all these images?
Can we first minimize them?
Let's get minimal packages that are only what we need.
Second, can we have someone patch these faster and then we drive that?
So we release the burden on engineering teams.
This is the movement that started.
It's very natural for Docker to do this.
And so we launched Docker hardened images as a paid product early last year.
It's a hardened images, base images, app images that are minimal, low to no CVs, backed by an SLA by us.
When we launched, we had a limited catalog, and we've been aggressively growing that.
Our vision was always like Docker is like broad adoption, get tooling and content out to everyone.
So vision was always we need to make this accessible to everyone.
And then for enterprises, we provide things enterprises care about, compliance, and we can cover what is an enterprise package.
But for everyone out there, they should be able to get a great starting point and a secure starting point.
So that was the vision always, which said to like build up to that.
So that's what we got to last year and launched that out there.
So this is a paid product for a bit there.
And this is a big deal because you're letting revenue go by making this choice.
Yes, I know.
So it was a paid product.
What we did is basically launch a large catalog of, we made our entire content, entire catalog available for free, nearly most of it.
What's paid is stuff that enterprises would care about still.
So what's free is like any developer, any project, like open source projects have been adopting this at scale.
And in fact, like NATN is probably the largest open source project that's moved to this, right?
Which is what we want.
We want everyone to have a secure starting point.
But now, if you want an SLA, like any place where there's a CISO, they want things.
I want an SLA commitment behind the patching.
Uh I want FIPS images and stakes images.
I want support and patching on uh images that are old, like outside LTS images.
That kind of stuff isn't our paid product.
I want deeper, more scalable customizations.
Those are in a paid product.
So we still have a paid tier.
And that's basically the had to where it's if there's a CSA who cares about a bunch of stuff, that stuff is in the paid tier.
Free tier is for every developer, every company up there.
Gotcha.
So table stakes, it seems as S bombs, SLSA.
I didn't know there was an SLS out there, but there is.
Yeah.
And cryptographic signing.
You're making those those three things.
Those things everyone gets an S bomb, our build pipeline salsa issue.
SALSA.
That's how you say it.
SALSA?
SALSA.
That's how you say SLASA fun.
There you go.
I'm not gonna trip over my acronym ability then and just use SALSA.
And so that is how we build these.
So we have a salsa level three build pipeline.
We actually even open sourced our builder for this.
What's been interesting is to do this, we had to change um how we build images.
Uh it's still using like Docker build kit underneath the covers, but we moved away from Docker files to our own semantic layer, to our own new which build these well.
I can explain that.
And then our build system.
It's been interesting as we've done this.
You know, supply chain security is a broad topic, and secure content is one part of that.
Securing your build system is another part of that.
That's key.
So it's been interesting we've done this now.
Lots of companies are interested in our build pipeline.
So that's the next thing we're looking at is exposing that as technology to everyone.
Uh for so everyone can have secure build pipelines.
And we'll keep going down this route of like how to basically see the supply chain is just critical.
Not just for traditional container stuff, but you know, we'll also see this with AI when we talk about that.
You said you moved away from Docker file.
Is that right?
Concretely, I mean, it's still using the same technology under the covers, but just we have it, we built our own, we open source this too.
Uh we built our own YAML syntax here just to make builds more repeatable.
Like in Docker files, you can shut out, you can do stuff.
So remove that.
So in this syntax, it's very repeatable, it's reproducible.
Uh, so you can actually uh do these in a way where you meet salsa requirements.
It's still a build kit underneath the covers.
Can you unpack briefly S-bomb, what that means, why it's important, and salsa, which is obviously how you say it, Adam.
Right.
Yes.
I knew that the whole time.
What it means in that.
Did you know that the whole time, Jared?
No, I did not.
I had no idea.
I also don't know the first time.
That was good to learn.
This is uh like a different version of an SLS.
That's on point.
Some of us learn on the air here, which we've been doing it for years.
So we're not easily embarrassed.
Go ahead.
Let us know what it means now.
So SBOM is simply software-built materials.
All it means is typically in a container package, there's built in many layers.
How do you know what's in it?
And then second, you want to know not just what's in it, but how is it built?
Everything about how everything was built and signed.
So if you look at SPOM packages, it can say, like, okay, here's not just the top layer pack uh image that's there and all the packages.
Here's everything else that's in it.
And we also sign it, we can capture uh aspects of the build environment, where it was built, various aspects of the node, et cetera.
So there's a bunch of detail that's there.
That's typically important for, or that's important for um one provenance, you know, where the thing came from.
Two later with this compromise, you can trace what's all impacted and you can manage that.
So S-BOMs are critical, and then with containers, they're complicated just because of all the layering that can happen.
And so we manage all the transitive dependencies and like the full SBOM.
And then many tools, you know, all the scanners can pull from that and understand what's happening there.
Um there's three things to explain here.
So there's S bombs, the salsa, and there's VEX.
I'll cover VEX then second, actually.
VEX then is I'm gonna get the, I'm gonna get what it stands for wrong.
I'm gonna make it up and assuming it's correct.
Some of the internet can correct me in the comments if I'm wrong.
But it's like it's like vulnerability exceptions, I think, uh, which are a lot of times you have CVEs that are reported, but if you look through it, the maintainer is physically like these don't actually apply.
And so you can produce VEX statements, and that that is also, you know, we stand behind that, or the upstream maintainer rule has it behind it.
And then scanners can uh understand that and know, like, okay, these things don't matter.
So it reduces scanner noise.
And what's good to do it this way, a lot of times what other people can do is like in the SBOM, they might obfuscate, or they have a C V fee that says here's the CVs.
Instead, we say, here's everything, go pull it from anywhere else, and then we'll tell you which things we think don't matter, and we're standing behind that.
It's just much more open and transparent.
And then salsa stands for um, it's an open standard.
It stands for how you build a thing and your build environment and there's various levels.
And SALSA three just means it's reputable, it's reproducible, hermetic.
Um it is uh there's uh not being tampered with the build environment itself doesn't have access.
It's a way to secure your build pipeline that we're uh standing behind.
So you know, like, okay, nothing's being tampered with on the build pipeline itself.
Gotcha.
And so that's all a bunch of just maybe that's like you know, to give an example, all the machinery that goes into doing this stuff.
So stuff we put in the free, you know, you say we're giving revenue.
I think of it as actually, no, like look, our business model is very much, there's both the business model and ethos here.
Ethos is very much get this out, the community should run around standards.
And business model is sure, we'll drive that's the top of the funnel to a paid product.
But as a result, we do put a lot of effort and value that we give out into free, right?
Docker hub is free, and um we're giving the free tier for Docker images.
And there's a lot that just goes into that.
Let's just say I'm a working developer with a couple of servers out there in the wild and they're all Dockerized.
Maybe I got a Postgres server.
And my base image is like Debian or Alpine or something basic, and then I apt get install Postgres, and I, you know, my Docker file does all the things or whatever.
What do I gain by switching to a Docker hardened image and what do I potentially lose?
Or what might I hit up against when I try to do that?
Yeah, so um, in terms of what you gain, so like two ways, we generally have two flavors of hard images, like a development image and a production image.
In production, in development, you want stuff.
Like you need a package manager, you need shell, you need debug, you know, all these things, right?
You need the VCD bug.
Cool.
We'll give that to you, still minimal.
Really, with them, we recommend a multi-stage build.
So for your production images, you don't need that stuff necessarily.
So minimize that.
There are trade-offs here, primarily to do with usability and how you manage that.
Um, first, the images you get from us, maybe you need a few more packages.
We have customized build for that.
You run that for a build pipeline, we'll add those in.
Those are still hardened packages we're putting in, and you still get all of SBOM, Cell Services, all that carries forward.
But, you know, if you've just built a project doing it, uh, a lot of times, a lot of people's migration is really easy.
Sometimes you've done stuff where, like, okay, I have to figure out what's my trade-off between usability and security, and like what am I managing there?
And if I've built my system in a way where I can't split this up well, or I really depend on like, you know, shell access uh in production, uh, then those are trade-offs I'm making.
And so those are typically the challenges that a number of projects can run into.
But honestly, for the most part, from a lot of our customers, we hear like the vast majority of their um their projects are able to migrate easily to this.
We are also looking at building like an agent here to help uh do this.
We've got initial versions of running internally.
We use it internally, and then we'll start building that up.
Like, you know, how much can we help people with complex migrations here?
Mm-hmm.
Yeah, that'd be super useful.
So what did adoption look like back in May?
And then what's it looked like since then?
Is this something that everyone's just like it's a no-brainer?
Obviously, you might have some headaches, but they're worth it, or people more tentative.
What's been the reception?
Yeah, maybe just as an idea first.
We did a webinar, I want to say a couple of weeks ago, something, I forget when.
That was pretty broadly attended.
I think my favorite question from that was so is there any reason I shouldn't use Docker images?
Right.
There really is like no one, like, no, you should.
There's really no reason why you wouldn't want to just have a hardened image, you know.
There's really no reason, right?
This is part of the reason for opening this up, like uh you should go do this.
Uh so early on, we had lots of uh good traction with customers and working through the enterprise deals.
Since we've open sourced this, um, also to be fair, we open sourced it right before the break, like I think December 16th or something is when our uh or the not open source, but the free tier, uh that's when our launch was.
But even then we saw immediate interest and pickup, and so we're tracking open source packages, adopting this dramatically, uh, like I mentioned any tenants gone to it.
And then with customers, it's resonated.
So like CISOs like it, head of platform like it, in part because you know, we're seeing play out what we hoped, which is okay.
Now someone on the team, typically someone has a mandate of like, oh, I should go.
And people care about this problem.
The barrier for them to go adopt and try it on and see the benefit is low.
It's basically zero.
They can just do it.
And then they're like, okay, now I want all these, you know, additional security guarantees or just thing.
Great.
Now we can have a conversation about about the paid uh paid tier.
So we've seen it, we've seen an uptake for sure, and like this motion playing out where like open source adoption, top of funnel with companies, and then we start working through uh working through this.
Um, you know, this is still one of those things I think people have to it takes time to work through because like people have adopted, they have to care about security, they drive it, but starting to see starting to see this grow quite a bit.
You mentioned releasing this announcement right before the break.
Adam, didn't you have some feedback on that timing of this announcement?
I think it was like I think anybody would have feedback on that timing.
Come on now.
Uh yeah, it's the worst time ever.
Um I'll certainly counter that.
I'll certainly counter that.
It's the worst timing ever.
Just because right before the break.
I don't know.
I feel like holidays actually now, like when all AI products get released, it's like the moment to release all the things anyway.
Right.
Everyone's at home tinkering.
They're like, we gotta get our product out there for people to tinker it with it.
Yeah, yeah, I didn't know it was December, that's for sure.
Right.
Yeah, I was like, I don't care what month it is.
I'm I'm I'm here and I'm integrating.
You better follow me or or be left behind.
I suppose there's no really bad time.
It's just that whenever you want to get good fanfare, now you're playing a month-long launch plan versus a single day with a great precipice and a lot of uh attraction.
Now it's it's just I think you just made it hard on yourself, basically.
Um Yeah, it's fair enough.
We'll take that once you put it's just like let's just do it and get it out versus come back and gen, let's just go.
Right.
Um that being said, though, I mean, there's no good time like secure today.
You know, like security, I would I would rather use secure today than tomorrow.
Yeah, in every case, because don't delay security.
I think uh, you know, just timing is is not the best because we couldn't do the show in December.
We were we were away.
We were taking our breaks.
We're talking about it now.
But here we are, December December, January 28th, talking about it.
Uh super important though.
I mean, I think you know, the one thing that I'm reading here is obviously that you know, when you make a change, when Docker makes a change, when you change the default, it's a ripple effect throughout the industry.
Yes.
And I think about one, the effect of that ripple, and then two, creating that ripple.
My gosh, behind the scenes, what kind of thinking, what kind of specifications, what kind of planning?
Uh how do you architect this new vision, this new build pipeline from build kit to all the all the free artifacts that are given away for free, and then re-changing how you productize it to create revenue as a company.
I mean, it must have been uh head of engineering undertaking.
You know what I mean?
It's a whole company effort.
Honestly, my job is the easiest in all of this.
I mostly say with hey, we should do this.
We should do this.
Let me know when it's finished, guys.
And then, you know, look, um, Docker's got great talent, and so people rally and do stuff.
In this case, like this was always part of the things we wanted to go do and drive it.
But then, yes, there's lots of stuff to go figure out.
Uh, starting first and foremost with um, don't put stuff out there.
Like, it's true for everything, but if you're gonna make a big product community, we have like the quality, the underpinnings of this technical security have to be interestellar.
We simply cannot do it if you don't do that, in part because uh, you know, not from a brand damage on call us out, like that too, but but first, we are the source of supply chain.
Like, people will take what we put out there, and yes, we'll get, you know, if you do something bad, so we'll find out, we'll figure it out, but like really it's like a responsibility of like whatever we're doing is going out there.
So we have to deeply deeply care about that.
And so that comes from like just the team that's on this and the experts we have on this, and like going deep here, right?
We've got like decades in these areas, uh, and they've got a bunch of strong people here uh working on it.
Uh and then there is uh product and strategy, and all that we work through, like, okay, how do you actually get this out?
Um, manage community, manage customers through this, and work through all of that.
So, yeah, this def this was definitely a whole company effort uh for us to go take on.
And it's the start of what we're doing.
This is just a start, right?
Like the vision is secure the entire supply chain.
For those of Java, it's like you know, void main down.
Like we want to address everything.
Secure your entire supply chain as we can get policies out because we sit everywhere in your SDLC from laptop to CI production to registries, content rest.
Let's try to get your build pipeline, secure all of it.
Well, friends, I don't know about you, but something bothers me about GitHub Actions.
I love the fact that it's there.
I love the fact that it's so ubiquitous.
I love the fact that agents that do my coding for me believe that my CI CD workflow begins with drafting Tomo files for GitHub Actions.
That's great.
It's all great until yes, until your builds start moving like molasses.
GitHub Actions is slow, it's just the way it is, that's how it works.
I'm sorry, but I'm not sorry because our friends at namespace, they fix that.
Yes, we use namespace.so to do all of our builds so much faster.
Namespace is like GitHub Actions, but faster.
I mean, like way faster.
It caches everything smartly, it caches your dependencies, your Docker layers, your build artifacts, so your CI can run super fast.
You get shorter feedback loops, happier developers because we love our time, and you get fewer.
I'll be back after this coffee, and my build finishes.
So that's that's not cool.
The best part is it's drop-in.
It works right alongside your existing GitHub actions with almost zero config.
It's a one-line change.
So you can speed up your builds, you can delight your team, and you can finally stop pretending that build time is focus time.
It's not.
Learn more, go to namespace.so.
That's namespace dot so, just like it sounds, like it said.
Go there, check them out.
We use them, we love them, and you should too.
Namespace.so.
Can you estimate the time to shipping from the point where the phrase Docker hardened images was like a white on a whiteboard somewhere or in a product roadmap, like we're gonna do this someday, to deciding we're gonna do it now, and then from that point till either December 16th or May, when you actually ship the original version of the case.
Let's see.
I'll I'll try to jog my memory.
So I think we'll say is um uh so in UCO join uh Don Donos and I would say uh I think Feb of last year.
Okay.
That's when the site is rolling around and Vafo seems to be like, yep, we're gonna do this, we're gonna launch it.
So I think from that point, you know, if you have people with skill set, but like formed a team at that point.
So uh I don't know, early feb, mid-feb, something like that.
And we got it out into um like limited build release, like early uh uh limited release in I want to say three months.
Well, customers G'd it, you know, within the next three months.
So that got us to like summer-ish.
Uh then we grew, kept growing, growing, growing.
Um, and then I think the build we knew we wanted to make it free, but we weren't sure when.
But I think the real thing, like, oh, we should work towards free.
So December, I want to say it was like honestly, it was like maybe early November, mid-November was like, okay, we're doing this.
Um, or like right around, yeah, because close to Thanksgiving is whatever we call, somewhere on there.
And so from then till there was like a probably like a four-week sprint.
That's all pretty good.
That's all pretty impressive.
You said you have a good team there.
I mean, that I was expecting longer.
So I guess you know, congrats to you and the team for really a pretty quick turnaround.
Yeah, within this day and age, you don't have time.
Uh everything.
I don't have time.
Yeah, I better get it done yesterday.
You better get everything done yesterday.
Because also the subject of containers, but like, you know, it this this A, this mode of working is critical for us for everything we're doing.
And as you know, we'll when we cover AI, we'll talk about that like it's in that space in particular.
The timeline I just said in the air world has to shrink 10x.
Yeah.
So it does.
So this this muscle is in general, as an energy organization, critical for us.
This part of the conversation talks about the time.
Eight months is what I roughly kind of captured there to go from Docker Harden Images to GA to let's make it free, let's release it, and it's released.
But the tension behind it has to go back beyond that.
Because one thing that was mentioned in the announcement post was I'm gonna quote this.
It says, and while some vendors suppress CVEs in their feed to maintain a green a green scanner, Docker is always transparent.
So there's this, it seems like if I'm reading this correctly, you got Docker, which is you know the supply chain essentially of images, Docker Hub and the trust factor.
And you got vendors out there who have been doing versions of this seemingly not being fully transparent, making their builds green when they're actually not green.
Can you speak to not just the cycle to get here, but the tension that rose to say, we've got to take this on, we've got to make this a the way, this this default standard that you've made it?
Can you speak to the tension and what it took to sort of uh own the responsibility?
Yeah, absolutely.
So, you know, this these ideas go way back, right?
You can go to when like Google District started, right?
And so, like a lot of the ideas go back.
And so the discussion always been there, like what else should we do here, what to build, how to manage this.
I think there's been lots of like in the past, uh, discussion of how we how should we do this, and then it's like, is it a big enough business here?
Should we go after this?
How do we think about this versus what we're else we're doing uh across the company, et cetera?
So there's been this discussion, has definitely been there for some time.
Uh, and like what's the best way to do it?
I think a few things came together for us in Feb.
One, we should have changed clarity of like, yeah, we're doing this stuff, we're gonna do it.
Second, uh, I'd see on the Deadline side, like clear clarity and like how we should do this.
Of like, no, the serpents were like, we're gonna do this differently, and here's how.
Even concretely, like vex statements are a thing the industry is adopting now, and we're helping driving that.
We broke all the scanners of like, this is why you should adopt it.
It's been it's a standard, but there's not universal adopt adoption of it, and we're like driving that forward and making that happen.
So I'd say the tension is definitely there.
Uh, probably before that, I've been a year and a half.
I'd say even before my time, it's been there.
It's one of those topics that's you know been in the industry for a while.
Uh, and then the real thing was like, nope, we should do this.
And that was both business clarity, and second, I'd say uh technical clarity on how to do this.
And then on the speed, we built a bunch of stuff, but we get to leverage um a lot of Docker underpinnings, right?
We've got Billkit here, we've got Docker Engine here, we've got Hub here, like we get to leverage all of that for how we get to go drive this uh and make it happen.
Um yeah, I think the core part is just realizing this where it comes from.
Like we are a not really, like, we are a co-part of the supply chain, and so we have to start uh not just the kind of stuff we do, but like take on the broad responsibility of how to secure the supply chain.
That's both a business opportunity, but it's also almost like a responsibility, right?
Given our position where we are.
Can you go deeper into this vex you've said a couple of times?
Vulnerability, exploitability, exchange.
It seems like I'm not steeped deep in this.
I'm I'm learning.
You know, that's that's uh I'm I'm pulling back the Google results on this stuff.
Yes, I still google here and there because it's just easier sometimes.
Uh it seems like this is a way to be transparent, a software suppliers to be transparent about particular areas where you're still vulnerable, but you're able to do so.
It seems like in a community mindset where, hey, we've got this thing, we're delivering it.
It's not fully green.
And these are these are the areas where it's not green.
Can you speak to the behind the scenes of what that exchange actually is?
Yeah, so uh the way actually use it is um you can have packages.
So typically some if you're if you're distro, you have packages, uh, and then you have your own CV fee.
Like, hey, we will tell you what are the CVs here, and that's one way to control it.
You have this root issue often of like, well, there are CVs, but like, you know, the CVs in the national database, but they're not actually an exploitable C V E.
Uh, in here, we don't we don't think it's actually exploitable in our in our code base or the way this works.
So if you publish your own C V feed, you can just not publish it, and that's when we do it.
We take a different approach where we publish fully transparent S bomb, scanners can take that and they pull the central C V fee and the CD CVs.
Then we publish the VEX feed that says, okay, here are the ones that we don't think matter.
In the other approach, you're missing that that uh uh that transparency and that logic of like, oh, here's everything, here's what we think don't matter, and here's why.
And which is a better approach.
Because then we can talk about it, right?
And we can see uh whether you agree or don't agree with us.
If we can figure that out, also like for CISOs on the right, for anyone else, it's very clear what's happening.
So that's the sort of thing we're doing, uh the approach we're taking here.
Now, this has been a standard for some time, it was just like never, as I can tell, like broadly adopted yet, because like with scan as we're working through, some had it, some didn't, and now we're working all of them and they're all getting it in there.
And what it seems like is it's a focus on what is exploitable versus the things that are not.
So you still have let's just say security concerns, but these are the ones that we should pay attention to.
These are the ones that are actually worth paying attention to and actually cause real harm or damage.
Uh it's both.
We we we we we put you put everything in there, it's it's just a way to annotate stuff.
So we put everything there, like here's the ones that we think content is what's coming, but then it's also explicitly which ones are not exploitable, put that in there too.
So we cover all of that in there.
What about this tension?
Can you go?
Can you go maybe one layer deeper in terms of who has been the supplier?
So you got Docker, then you got third parties, not so much by name necessarily, but like what are their roles in the supply chain and why has this moved to a free tier with these kind of table stakes requirements, been a great move compared to the prior, you know, the prior way?
Sure.
So maybe we're to think uh maybe the way I'll uh talk about this is so yes, so I think like you know, Docker Hub has been, I'd say the easily the biggest main uh uh registry for open source container images.
There have been other companies that have come up that are uh uh selling um hardened container images, right?
Uh and so that's been a model of that other business models that companies have come up and started doing.
So then the question for us was like, well, one is like very natural for us to do that.
So we should look at doing that.
And it's a thing we've discussed and not done explicitly.
So that's a very natural thing for us to go do.
Um I think the tension talk was more just like Docker Hub could have remained just the open source usability first place, or really it's like, no, like Docker should take on supply chain security all up.
And I think that was the sort of change in like uh our product and business thinking is like uh if we if you look at our like sort of product strategy pillars, supply chain security should be a core part of it because we are a core part of supply chain, not just for images, but also where our Docker engine is, right?
It's runs everywhere.
And so we should take those two things and drive supply chain security everywhere.
And so that was, I think, the sort of mental framing change that was needed here for us to go drive with this and go do this.
And now the other thing for us making this free is two parts.
One, it's a general approach of welcome to adoption and then drive, use that as a funnel.
But maybe second is like, you know, we have a holistic platform and supply chain security and secure content is one part of that.
So that's why for us, maybe there's some amount of you know, revenue impact too, but I don't actually think so.
Cause for anyone who who needs compliance guarantees, there's a pay tier for everyone that's about adoption.
But this is a this is one pillar of our business, not the entire business, right?
So that lets us go do things if we get broad adoption for the community.
Seems like very much a long-term play.
Like this is not a short game play, this is a long game play.
And you know, Jerry, we just were about to release this episode.
I think it might be out, I don't know if it's out or not.
I don't know.
Uh, about securing NPM.
This reminds me a lot like that.
I'm wondering to show if you if while you were in this tension period with the ecosystem and realizing the responsibility, and then in this announcement back in February internally, hey, let's do Docker hardened images.
Let's actually put the effort here, let's do all the research, let's figure out what we have to tie together, and let's make a concerted plan to execute.
How did you look at the rest of the world in developer land to say, where are other supply chain attacks happening?
And what are their issues?
Because there seems like a responsibility you've taken on, and just put it bluntly, GitHub is not with NPM, at least based on our current examination of the situation.
You've taken the responsibility and made a concerted effort and launched it in eight months.
And you've done it regardless of maybe here in this conversation, regardless of potential revenue loss.
I think it's a long-term play, and you're adding trust to the layer and security to the layer, which is good for your brand long-term and good for Docker and me.
Like I got a home lab, I launching Docker daily.
You know, I want that to be trusted and secured.
How did you look at the rest of the world when it comes to supply chain attacks or supply chain security?
Was NPM one of the examination targets for you?
Yeah.
So number of stuff to unpack that, absolutely.
Uh, one thing we before we do that, just the revenue topic first.
I actually think of this as a revenue accelerant for us, to be very clear, right?
Like, actually think this is revenue accelerant.
Like we're having this conversation because we launched Docker's for free, or listen and listen to it.
Hopefully, many people go use it.
And within companies, they'll they'll want the stuff that CISOs want, and that should hopefully lead to like them calling us.
So, like the reach, basically our reach should expand here, right?
So I view this as like a revenue accelerant for us, and we're starting to see that play out uh just in the very front.
On the other part, you're absolutely right.
Look, I can't tell if supply chain security attacks have actually gone up, or we just like talk about them more.
But there is definitely a market increase here, right?
Like NPM stuff, but like the Shy Halud attack that just happened.
Side note, I love that name.
I just watched the show, and then I was like, ah, now I know why Shy Halud.
Um so we absolutely uh saw that and see this happening broadly.
And when we look at that, this is what I was saying, like this is the start.
We have right now with Docker and Images, we've started securing a critical part of your supply chain.
There's a lot more to do.
There's a lot more that's in your supply chain.
There's packages, there's runtime.
And so our ambition is to get through all of it and start looking at it all.
Um, mostly because um it's just the tax are increasing and supply chain attacks are the ones that have massive impact, right?
They just ripple out.
And so we just see as a critical a business need and uh and a need needed for like software uh across the world.
And then it's also just critical foundation needed.
I think if you're gonna live in a world where AI agents are writing more software, like if you don't have secure foundations, that life's just gonna get way, way worse.
And so as we look at our AI play too, we think secure uh contents and supply security is a critical pillar for that too.
So that was absolutely all of these things.
And to be clear, we've not addressed all of them, but this is why this is a this is not a one and done, we've got Docker images, that's good.
No, this is a this is a pillar.
It's a pillar, and now we're gonna walk on the pillar.
So one thing we didn't cover was the breadth of the the announcement of what was happening here.
So if I if I understand correctly, and correct me if I might be wrong, is over 1,000 hardened images and helm charts are not available.
That's a lot.
Uh you're building on Alpine and Debian.
These are familiar, these are trusted foundations people are building on.
And it's obviously being uh announced as open source under the Apache 2 license.
So DHI is now free under Apache 2.
That's the the current state of affairs.
Where do we go from here?
Like what is in that 1,000 hardened images in those Helm charts?
What is not there currently?
What needs to be there?
What is the if if now is the flag moment, you know, where else are you gonna go from milestones?
Yeah, so uh a number of things.
Um one, we're gonna roll out hardened sister packages.
Also, today a lot of system packages that you want come from upstream repos.
We're gonna start offering our own hard and sister packages, built from source.
We'll patch ahead if where and when needed.
Uh so we started doing that, and that's gonna, that'll come out.
We're also gonna look at like uh language uh packages.
Uh we'll attack that language by language and go into that and get those out.
On the enterprise side, we'll look at uh long-term support.
Uh typically packages have like, you know, uh LTS there after like two years, you stop getting uh patches from upstream or three years.
We will you can buy long-term support from us.
So we can continue patching.
And typically for enterprises, you know, for various reasons, they move slower.
And so that's important there.
Uh so we expand the way to think about this is like expand the breadth and coverage of all the things of all the content you'll care about.
Let's get that out.
The next thing after that for us, I think is um a secure build pipeline.
This is not another thing we're starting to look at.
Do seeing all the interest here.
And so we have to figure out how exactly we'll do that.
We want to get this out.
So anyone who's building software should run on us and get the benefits of SARS 3 build pipeline and work on getting that out from there.
And then I'd say last thing, and this is like I mentioned parts of this we started is well, I really want to like you know, get some agents out here that help you with either migration or help you with like understanding your state of affairs and get you how to like how to get them secure.
Like basically, everything we can do to have the foundation to make it secure and then help you move towards that and manage that.
So I've been cruising your hardened images directory or catalog as you do.
And I've been looking at a few of these, and it's very cool.
I have some questions around like the security summary.
So I'm looking at the PHP image based on Debian 13, 92 packages, so that's pretty slim.
Um seven tools included if you're gonna run the PHP image.
And it has one medium severity vulnerability, 10 low severity vulnerabilities, six unspecified severity vulnerabilities.
I assume those are upstream vulnerabilities that you know about because you're not doing hard end packages, like those things are just like you're patched up as far as you can go, but there's just known vulnerabilities.
Is that what is that what those mean?
Good question.
So the lows and unknowns, since my step with the medium one, uh, I'd be very cute.
I'm gonna look at it afterwards.
Typically, those will if there's any high, we'd walk with upstream or we'd go ahead and do it.
Medium should fall in that category too.
I think for us, we're like, it should be something we go after soon.
So I'll look at that one afterwards.
But generally, high and critical, of course, and even mediums we try to get ahead of and drive quickly.
So when you have like, say there's this medium here and we don't know what it is, I can't seem to find if it lists what that is somewhere.
I think that'd be a pretty cool addition.
It should be.
If it isn't, yeah, it'll be a good addition.
Yeah, that'd be a sweet addition.
I do see a full security details and it still shows the vulnerabilities list, but I can't seem to find it at the at the moment.
Anyways, is that then is that a known CVE against a package against one of these 92 things that have been installed?
Yes.
But that doesn't necessarily mean that there is a patch, or is there a patch that just hasn't been applied?
If there was a patch, we apply it really fast.
Yes.
Like ours likely to have a patch, you know, or an unlikely case, uh, yeah, like not a patch.
But uh even then we typically try to go work at it and get a patch in place.
So that's what we do for high.
So the medium, it depends a lot where we are on that.
Yeah, I mean, yeah, lots of packages, yeah, lots of images.
It's probably a uh an ever a never-ending task is just to continuously before.
Yeah, so there's behind this, there's there's a machine running, right?
Uh of uh software and people.
So then the other question I have about is this scout health score, which maybe it's not as new to me.
Is that new in general or just new to me?
Scout is something we've had for some time.
Um Scout is our own scanner that we've had, and it's it's our own scanner that scans everything, and now we've just put it in here.
So uh you can see the health score that's there.
Uh we've given it, you know, uh in Hub, package owners can see the health scope for their packages that they're publishing.
Um and now here we've done it so anyone can see the health score of packages we're publishing here.
Yeah with the DHI.
Yeah, that's super cool.
So this one has an A score and it has all the reasons, like no high no high profile vulnerabilities, no fixable critical or high vulnerability signs, supply chain attestations, no embedded secrets, no embedded malware, like on and on and on.
And I assume there's a score for every image you all have on here.
There should be a score for every image, and there should not be any score that's lower than an A.
And if there is, I will follow up on that.
Well, if we have a let's see, filter my scout score and just say, show me the ones that are B's or lower, and then you know, I'll get the work.
Yeah, you mentioned actually mentioned one thing there, which is like no embedded secrets, etc.
So that's another thing where it's not just about reducing the package playing CVs, we go through actually like you know, a list of stuff of like what makes the thing secure and ensure that's there.
Like there's no credentials in there, none of this stuff.
And keep in mind, we're getting lots of patches from our stream all the time.
And we scan every single one of them.
So there's a mixture of AI running here and people to make sure what's happening here is secure.
It's cool stuff.
It seems like a good step forward for everybody.
It's honestly like for me, it's been uh uh I'm inside the house, so it's you know biasing to say, but like uh seeing the team here just running this and define this and have very strong opinions of how to approach this one and do it.
It's been um uh it's been really fascinating privilege to do that, right?
As I've come in here and see everyone who works at the space and do it.
Uh because there's a lot of depth in here as we've done this.
Uh so I'm excited now and impatient to like do all the other stuff that's part of our vision in this space and build this out.
Um and I'm hoping if anyone listening, you should go try DHI.
No reason not to.
It's too easy not to.
Or too easy to, I guess.
Too easy to and no reason not to.
Yeah.
Don't yeah, too easy to and the reason not to.
I like that's a better way to say it.
There you go.
So it this makes me feel like uh containers are the way, even more so now.
Like they've already been the way for so long.
And this has been the Docker story arc since you know, Solomon to now, essentially, is that it it took the world by storm.
Uh we now have the containerized way to do things, deploying applications to become easier than ever.
And you know, if there was any scrutiny on how that plays out, well, now that you've made this security mindset a first class citizen in the way you deliver, which seems like the obvious way to do things.
Like to not do it this way seems like that's just not right.
Yep.
Is uh containers are the way?
Would you agree with that?
I think containers are the way.
I mean, like in general, I don't think containers are going anywhere, even as application paradigms are changing.
End of the day, containers are a great way to um bundle up software, package it well, understand it, deploy it across systems.
Um thousand percent.
Can you speak to the ecosystem and the partners?
So external, Google, Mongo, yeah, uh, the CNCF, Snake, JFrog, a lot of the players in this space, Circle CI, Socket, even.
We have friends at Socket.
Can you speak to partner level involvement and orchestrating all the things, I guess?
Yeah.
There's a ton of partner involvement, right?
And like of various kinds.
So there's scanners.
So like Wiz is, for example, we work with them to integrate stuff here.
Like all the various scanners.
So a bunch of scanners have to integrate with us who drive that.
There are CSPs where they pull images from us and understand that.
So working with them.
There's also interesting things we can do with them over time and figure out various, you know, they have trust centers to have them integrate with us too, right?
So all of their effectively their own scanners and their own uh registry caches, have them integrate with this.
So we'll do that.
Then there are other players in the sort of uh, I would say supply chain or a security space, right?
So Sneak uh or uh sorry, Socket is interesting.
Uh we actually have a partnership with Socket that I think we announced, uh, where uh you can get images from us and we'll integrate Socket.
And so you can uh get the Socket firewall and get their benefit over um uh I believe it's PyPy or NPM, I forget which one they're on now.
Uh I think NPM.
And so there's a number of like the ecosystem, like Docker is in general that you know the DevTool supply phase has lots of players in it, and the Docker is just like such a core part of the Nexus.
So we have lots of players we integrate players we do this.
So when we do this, we have a we have a key arm that goes around and drives various partnerships.
We have strong relationships with many people here.
Um with Microsoft, actually MS Build, um, when we did LA, the limited web release, uh, I was at MS Build last year when you were there too.
That's where you announced it.
And we had early integration with Microsoft for this, where they would take uh Docker images by default deploy them and keep up with updates and get those deployed to their pipeline and to their scanners.
And so there's a number of these kinds of integrations we're doing everywhere.
And the way maybe to think about this is if you want to go drive broad change and impact, us launching it is critical, but we have to go do it through all the various um the key sort of uh you know uh systems and players in the space.
Like you can't do broad broad impact without working with partners.
What is that like?
Do you have to, if I'm one of these partners, do I get early access to documentation?
Do I get early access to maybe an embedded engineer that's you know works for Docker but actually works for me because they're inside my organization, helping me better understand and organize the way we work around securing Docker or working in orchestration uh orchestration as a partner, how does that how does that play out when it's actually boots on the ground, people getting commingled?
How does that work?
It varies based on the state of the partner state of where we are.
So, for example, when we started early with Microsoft on we were just getting started in that case, uh we had PMs and engineers connected.
Generally, everyone went up on a joint Slack channel uh or something.
Uh, and then we're deeply connected.
And in that case, we're like doing some go build, and it's very early.
So they're getting early access from us and we're working together.
When you're later stage, then you just have connections with partnerships and product people generally, and then you drive that forward, right?
So depending where we are, we do this.
Um but the maybe the approach and the philosophy here very much is succeeding at partnerships is not the job of like a partnership department, it's a job of like our company with everyone, right?
So we like figure out what's needed and drive that.
And that's the general approach of everything, right?
These aren't like yes, there are departments of focus and stuff, but like we have to operate as like one.
And so depending on what's needed, we'll have engineers plugged in, we'll have SAs plugged in, whatever's needed to like manage this and and do this as we work through with everyone around it.
And so it varies a lot where we are and what's needed uh as you work through it.
But like uh it's absolutely like a ends up becoming a cross-functional team effort by default.
Is there a framework or a specification or a substrate that could be borrowed or extracted from all the work you've done, your team has done for the last eight or nine months accomplishing this mission?
I'm just thinking, like, if we want MPM or any other registry out there to have similar characteristics or similar concerns around security, is there a substrate here that can be extracted that says this is the way we secure registries across the board?
Because when you look down the line, you've got you've got the idea that you've mentioned hardened MCP servers, for example.
This is a versioning thing around AI security, you know, AI.
That's how can we secure AI?
Then you got things like maybe hardened libraries or system package.
I'm thinking like Apt, or anytime you install anything, like is there an extractable thing here from this effort that uh that you can lead or provide a spec to?
That's a that's a good question.
So like the first thought that comes to my mind is actually, I think the first thing is like at least extracting like the principles and the like uh end goals, right?
Being very clear about that.
Like we have some core principles that we've applied.
Uh and I say that because like the hows might differ depending on the domain of what's needed.
Yeah, right.
For sure.
Um, and so then the segment, like, what can you extract like at a technical level to that?
I'm not sure.
I suspect I'm sure the stuff here, but especially if I think about stuff outside container images land, then it's interesting and like a little different.
But the principles definitely do, and the approach does, um, in terms of common things that you can pull out there.
Um I think there are things here.
For example, like the way we're building, yes, we made it for images and containers, but I suspect that like if you sit down and look at it, core parts of that stuff we can pull out and make it work for like non-container stuff too, maybe, right?
And I'm I'm winging it a bit here when I say that.
But there's like core parts of like how do you do a build how to secure a build pipeline that should apply, I think, uh a little more generically too, as an example.
Uh, there are parts of like maybe some of the AI agents we're running that can uh apply more broadly than just for because they run at the code level to verify security of all the thousands of upstream pack uh PRs uh patches we're getting, right?
So there might be stuff like that.
But if I step back and think like, okay, how do you secure non-container registries, et cetera?
First stuff that comes to mind very much is like let's extract the core principles, and then we can see what components are extrapol.
Yeah.
Do you have that in a like a manifesto?
And if not, can you can you give it to me?
Yeah, as I was saying this, I'm like, I think I teed up the next question.
Yeah, I really I really want that.
I mean, I really do.
I think well, because I even think about it, like, I want I want your your what and your why.
And I I kind of want a little bit of your how, but not all of your how, because my how is going to be a little bit different based on my context, right?
I want to know your what and your why and how you think about the problem, because I want that's the that's the intellect, that's the intelligence.
My how is gonna be different if I run you know a different kind of registry that is not at all images or container images or around the things you care about, it's gonna be a way different thing.
So don't tell me the how.
Give me the what and why.
Yeah, yeah, yeah, yeah.
Uh yeah, absolutely.
That's actually great.
And then also, you know, riffing a bit here.
Even though the house can imagine if you do that, you still produce maybe like this another, maybe another opportunity.
That's good to give me some ideas here.
Maybe the other opportunity to work with CNCF for someone of like producing a spec of like once you've done it, like, you know, what's an S bomb end of the day?
It's a signed artifact saying, hey, here's what I've done, here's what's there that someone can take and understand, and then be like, okay, cool, this boss is the bar.
So, you know, if you can agree in the Watson House, then cool, someone does do that and produce a result, an artifact that captures all of that.
And then just depending on what you're doing, we can still like have a central, a central, like, you know, reviewer or grader or something across stuff.
So it's not limited to just containers, but like expand more broadly.
Uh, there's something interesting here.
You can also do this for like runtime security, for example.
I think.
Cool.
All right, Adam.
I think you gave me you give me an action item here.
All right.
Go right down.
Why don't I give you more?
What's a podcast?
Uh I mean, I want it, seriously.
So the moment uh you release it, uh, email me personally if you don't mind, because I'm gonna read it right away.
Done.
So here's the thing about network security for enterprise.
It's usually a six-month project involving hardware, consultants, and at least one person whose entire job is managing the VPN.
North Layer looked at that solution and said, What if we could do that in 10 minutes?
What is Nordlayer?
It's a toggle ready network security platform built for businesses, VPN, access control, threat protection, all this stuff all in one place.
No hardware requirements.
It's built on zero trust principles, which means only the right people access the right resources, verified every time.
And it's powered by Nord Links, their VPN protocol that's built on WireGuard.
So it's actually fast.
For IT admins, this is a good stuff.
Granted control over who accesses what, from where, on which device, built-in threat detection, scan provisioning for automated onboarding and offboarding, deployment minutes, and scale and clicks.
They've also part with CrowdStrike to bring Falcon endpoint protection to small and mid-sized businesses.
So you get enterprise grade multi-layered security without needing an enterprise size IT team to run it.
Here's an exclusive offer for you, friends.
Up to 22% off Nordlayer yearly plans plus 10% on top of the coupon code changelog 10-nordlayer.
Try it risk-free for a 14-day money back guarantee at Nordlayer.com slash the changelog.
Once again, Nordlayer.com slash the changelog and use the coupon code changelog-10-Nordlayer for the 22% off Nordlayer yearly plans, we're here in January, just until end of January, going into February.
You've done all this work, it's released, it's out there.
We've got table stakes, hardened security out there for Docker images.
What is next?
You've got great partners in place.
You talked about how you integrate with them, how you work with them, how you involve them, and then you have hopes for uh new trust to be built on in the community.
What is in your mind as head of engineering, both leading your team, but also just altruistic thinking about Docker and its trust level?
What do you want to come from all this work?
There's a lot here.
So in terms of sort of what's next and like how to think about like the impact, that would be uh great to get here.
So, first on the current stuff, like I said, we should do a lot more, right?
We've got to keep adding packages, expand the ecosystem of stuff we cover a lot more, get into system packages, get into language packages, uh build stuff for the enterprise layer.
Um we need to get a secure policy, like the ability to define policy and enforce it across your entire tool chain.
So we're working on that, trying to get secure builds, to all there's a deep roadmap here for us to go work on and drive.
But maybe the like, you know, to your point of like what's the sort of maybe the way like impact we want here?
Like one, I'd love to see like I'd love to see this be the default starting point, right?
Like what is needed to get into place when I'm building something new, why not start with Docker hardened images and what all is needed to achieve that?
And I expect it's a mixture of technical and non-technical things that are needed there.
Like one, it's like, you know, for someone new that's starting, like, where do they learn how to start?
Uh, how do we make this be the default easy path?
For a lot of people, it's like I'll just I'll copy what someone else did, or I'll just do whatever ChatGPT tells me to tells me to do.
So, like, how do we go influence all these places and let this be starting point uh for everyone?
Because I think that's a that should be a key thing if I jump forward n years in the future.
Great.
The next popular open source package starts with just DHI, because like why wouldn't it?
That's like the thing you do.
Um to go achieve that.
And the reason that matters to us, apart from you know, the electricity goal or just the real goal of like make software secure is like on the business side, that then very clearly leads to for enterprises.
Um they get to buy uh enterprise level security from us.
Yeah, just worry a little less, you know.
One one less worry for a CSO or one less worry for a head of engineering to think, gosh, you know, our supply chain needs to be secured.
Somebody should just do something about that.
Let's just thrash in the engineers, right?
Let's just shift left more, okay?
Just put more on the developers.
Right.
Even more.
That's one way you could go.
Yeah.
Yeah.
Well, this is very much, you know, just start, just start green.
Start green, stay green.
So I like that.
Start green, stay green.
Yeah.
There you go.
That is uh you should you should tagline that.
We should put that on the website or something.
If you haven't done it yet, t-shirt that, okay.
There you go.
That's how you create defaults, right?
You create a movement.
Do you see that uh kind of a tangent?
I I don't know.
I'm gonna riff a little bit.
Do you see that?
I think it was the show Billions or something like that on MBC.
I don't even know.
I didn't watch the show, but I saw the clip where he was talking about lemons.
Do you see this clip ever?
I don't I see the show, I don't recall this clip.
Well, there's a known term out there where you, you know, when life gives you lemons, you make lemonade.
He's like, No, no, no, that's not what you do.
And I'm gonna just paraphrase it because I forget.
But he went into this massive, just like deep dive.
Now you don't make lemonade, you make lemons scarce.
And he went through this whole story arc of how you make lemons the default and you you make it a tagline.
That's uh that's not cool.
That's Lamont.
You know, you kind of give it this cache of sorts.
You know, um, I think if you do something like that, you create a movement, you create a change.
Yeah, that's how you create uh you start green, you stay green, and uh you make that the the maneuver, and it's essentially you make it not cool.
Yeah, it's the ultimate nerd snipe, it's the inevitable.
Like this is the way, and the longer you take to get there, the further behind you are.
Yeah, 1000% agree.
Yeah.
And so uh if you go do that, and then also, I don't know.
I do a medical failure to make this be the thing that like is the default thing that like every agent recommends and starts because that's just how you write the code now anyway.
So yeah, agent recommends us still a black box, I guess, in a way, right?
Yes.
And you can rag it, but that's that's just from the side, it's not from the from the bottom, it's from the bottom up.
Figure that out.
What's left?
I know we covered a lot.
Uh I know you have a big role there.
I know that there's a lot happening around Docker in general.
I mean, this is a big announcement.
There's AI things happening.
What is your stance on things in that uh in that area around the Docker world?
That's that's you know, so we've done all this, and but like the AI stuff is clearly a big focus for us.
Uh and like sort of comes together in my mind.
Maybe I'll talk about like how we think about it, uh, at least like you know how I think about this a bit.
So look, Docker, you know, uh everyone uses it.
It's a core part of the STLC.
We help code go from laptop to production, and we kind of solve for like uh you know the big growth of apps that happened over the last decade, right?
Cloud native apps.
Every move to the cloud, everyone built services, continuous the way to do that and drive that.
We solve for all that with our packaging, with the hub content distribution, with the engine for building and running.
Well, there's two big shifts uh happening now, right?
Everyone is the entire STLC is changing.
You're developing coding agents, but literally the entire STLC of how you build, test, publish, run code is going to change and become AI first.
And second, the kinds of application you're writing are going to be agents now.
The next growth of apps are agents.
So I kind of see a very natural thing for us is like, you know, I think of Docker as our job is to help engineers and engineering team securely uh build and deliver software.
And so we've done that uh over the last decade for the way things have worked, and now we're adapting that for AI.
A core thing for us that we've had with Docker and Docker images, and even security and trusts we talked about, but even more important with AI and agents, I think is uh trust.
The thing is if you're gonna trust across this layer here for agents, that'll help people trust in agents more.
Basically, today everyone's like writing 10x to the code, but no one's shipping 10x to code.
In large part, because like there's not code trust yet.
Even when I reuse an agent, how do I let it run on unfeathered?
Do I trust all this output?
How do I test all of this?
How do I get this out?
How do I know what it's building with?
So that's sort of a framework we have.
And we're starting with the runtime environment.
So we've got Docker, Docker engine.
This is how you build and package and run isolated environments with containers.
Well, now we've got a slightly different thing with agents.
So with coding agents, we think, I frankly think it's crazy, everyone runs coding agents flat in the machines and then just like NPX installs MCP servers and runs them in the machine.
Like talk about supply chain risk.
So and so great.
But to be clear, the productivity benefits here are crazy, right?
What I want to do is I want to use an agent and let it run.
I don't want to like run a YOLO mode by default, it could do everything, but just give me some comfort, give me some security.
So we're gonna adapt our engine and build a new engine.
The way I think was like we'll need a new runtime engine for untrusted workloads.
It should be a place where you can go put in like a coding agent.
It needs a computer, it should be able to go run to everything it can do with security guardrails.
So it'll be by default, we'll have micro VMs here.
So if you go look, we have our initial start of this that should have just come out.
If you look at Docker sandboxes, we're coming up with you can do Docker sandbox run cloud, spins up cloud in a micro VM.
Around that, we have network proxies that are outside the VM.
So when it tries to go outside of the network, we run through proxy layer.
We have a credential layer here where you don't have to give it your credentials, but if it does talk to GitHub, we inject the credentials outside.
So the agent doesn't need to know your secure content and data.
We control files it has access to, control where it goes, but let it run.
Then for MCP, this is where we're adding our MCP security.
We have a trusted content, uh trusted registry of MCP servers.
These are MCP servers that we vetted, we run through security hardening here.
We're also building DHI version of these in a gateway that's plugged in.
And the gateway is where we can start injecting a lot more security uh rules too.
And so the vision is build towards a secure runtime for untrusted workloads, you know, folks encoding agents.
And we'll make this work both locally and remotely and give you the same thing.
So you can be working locally, but we'll have a cloud.
That'll be coming out soon.
Uh, and we actually have some early partners who are working with this on this already.
Um, but says as a developer, I should just start in our Docker sandbox.
I get all the proxy benefits, I run my agent unfeathered, I get all the security benefits, I'll get cloud, and for enterprise, they can manage governance around all of this stuff.
And then we tie supply chain security in here.
As we're doing this, create by default, build on the secure content we've talked about, get that in here, et cetera, et cetera.
Let me pause.
This is like a big, big push for us, and I think, like, sort of, you know, what should the next well, I want to say what should the next five years of Docker look like, but I'm talking AI.
So let's just say the next year for a minute.
Yeah, and then we'll see what happens after that.
Right?
Well, it does make sense because I I'm a I'm kind of a uh a dash dash dangerously skip permissions kind of guy, you know.
Um so when I run claw, that's where I go.
I'm just tired of like saying yes, you know what I'm saying?
So I just I just in a way yellow.
I'm not yellowing on production stuff, but on like little tinker things.
Uh but that's dangerous.
Obviously, this got the word in the in the flag for a reason.
And so what you're saying is in this feature world where we may be going to in this next year around AI, I can do that uh in a way that is less dangerous because it's containerized, it's it's compartmentalized, it's in its own, you know, micro VM or a sandbox.
And so the danger is really just micro VM danger, not Adam's MacBook Pro Danger, where I can I've seen this.
Well, there's a hacker news article out on this.
I believe somebody like deleted their the agent deleted their their entire machine.
You know, that's a possibility when you live dash dash dangerously.
Yeah, there's a ton here.
So just to you know, paint the picture a bit.
Uh so there's the VM isolation, and we can do that, and that'll protect your your home directory, your your directories a bit, but it's more than that, right?
So we can talk about just file for a minute.
Well, you want to protect stuff, but now, well, what if you do actually need it to read some folder?
How do you manage that?
So this is it's different from like containers, because containers you think of like package and you static and then scale them out.
Here we're talking about a runtime that actually needs to be dynamic.
That's the nature of the thing.
But I still want security, I want security statements to be true about it.
So by default, limited access.
When wants to go out, we can decide what we approve, what we don't let it run.
And when it does, like control rights to sensitive areas.
When it wants to write out to the network, it's not just to put a gate there too.
Anything it wants to do outside this box, we put a gate.
Great.
We'll have a network proxy.
That can control not just where it goes, but over time we'll add in deeper rules here that is it doing something dangerous.
And we can work at various levels of the stack as we do that.
Credentials, don't give this thing credentials.
You want to pull from GitHub?
Let's not put that in the agent, put that outside.
And agent can just try to talk to GitHub and we can inject the credentials as a minute.
There's a ton of the stuff you have to do.
And I don't know if you followed the Clotbot stuff.
I feel like I started, did that start on Saturday or something?
And then it's been like Yeah, so I've been using it, and then it's just like insane to follow out the speed.
And then I think yesterday there was, I forget the name of the person who wrote like a deep security article of how he used Skill Hub to get everyone to install the skill and like SLT show is White Hat showed how he could.
It just goes to show like what's happening here is like the potential is tremendous.
We all want to use it, but the security concerns are very, very real.
This is sort of the core of what I think like our job is like enable devs to be deeply productive and add security there.
And just this is now a space where like this is always being true, but it's even more true, it's more clear now because the productive benefits and security threats are just like you know 100x what they used to be.
Right.
Everything's faster, more pervasive.
Yes.
We're just flying by the seat of our pants.
And the stakes are high.
And I think it's like a perfect moment for Docker because like when you think about isolating, isolated secure workloads.
I feel like you know, is Docker, if not Docker, who else?
Star Green, stay green.
Just trying to say it, you know.
Yeah.
A couple more times here.
Yeah.
And so that's what we'll do local and cloud also.
And I think cloud's critical for us because as you start doing this stuff, I don't know.
I was doing a bunch of code recently.
I've got to the point now where like, I don't know, cloud can run for like a couple hours for me and produce good quality code with tests and everything.
I want to, I want that to run off somewhere else.
So I can like close my laptop and go do something else.
And I run like six of these at a time.
And so, but I but also want easy, I want security as the cloud, and I want easy DX between local and cloud because like I don't want to dig into it.
And so that's the other part of the engine we're like building now where the engine will run locally and run remotely, and we can get security and seamless, you know, local remote experience for you.
We're gonna have to get the IDE back into play, but I'm not talking about the actual IDE, I'm talking about the AIDE.
AI development environment.
That's what we need.
Yes.
Uh I mean, you have that for the cloud development environment, CDE, right?
Yes.
Let me take your machine away from you, let me put it in the cloud, and let me attach your IDE and/or Vim or whatever you want to rock, because that's just how it works.
Yep.
You know, we need an AIDE out there where you can just develop in the AI and close your laptop and move along and let it just keep churning.
Let's see if it's churning, right?
And then be able to pull it back when you need.
No, you have the security layer there when you need it.
And so yeah, this is like uh, yeah.
So it's like adapting Docker to be the uh to be the uh engine across the entire STLC for yeah, for closed P.
And so that's on the development side.
And then we're just gonna start doing stuff across the rest of the STLC too.
We've got to build security agents as we go and Docker building CI left, working all these problems here.
The goal is really help you securely actually, help developers securely 10x the code they're writing, use agents, and then help realize that and actually get that shipped out and know that it's safe and secure as you do that.
I definitely think this maneuver you've made with hardened images, I wouldn't say it cements it necessarily, it certainly puts the cement down and is hardening to just go back to the play on words here.
Because I mean, I can't imagine deploying software to production in a cloud that isn't in a container.
I can't imagine it just doesn't compute for me that way.
Now I am a system D kind of guy, so I do yellow here in my home lab.
So I don't really do a lot of Docker stuff in my home lab sometimes, especially if I'm putting somebody else's application in because they've already done the work.
They've containerized it for me.
But I'm if I'm doing my own thing here, I'm usually system D and I'm usually just running it bare metal because it's a VM.
It's in Proxmox.
It's my home lab.
It's not high stakes.
And it just gives you one less layer between me and the actual machine itself.
I'm I've already got hypervisor, virtual machine, then Docker, then Apple.
Let's say, come on.
I don't need all those layers.
That being said, I think that your intuition is right.
I think what you're doing in this maneuver has strengthened your position, has strengthened your trust for me.
And I think it just solidifies the fact that Docker is here to stay and containers are the way.
Yeah.
And maybe like, you know, uh another PT saving, maybe like you know, it's like build ones runs anywhere, sort of like Docker, and I think build one runs anywhere, trust always or something.
Right?
Like trust across the board.
Uh and that's true for AI, and then you're right, like DHI, like it's the same ethos, right?
Coming through of like trust security is critical.
Um just critical across your entire software lifecycle.
Well, Tishar, you are the head of engineering over there.
Anything left to say about what you do, what you're doing, what you're gonna do before we close things out.
Uh no, maybe I'll just you know wrap up, which is um I think well, like, you know, sort of where are we headed, what are we doing?
If it's successful and I've high confidence we'll be, then like everyone who's one, I think the entire engineering world, every engine's gonna move to using coding agents.
It's just what's gonna happen.
I think all that should run in a new secure runtime uh for agents using um the secure supply chain base that we have.
So you use the runtime, basically adapting our engine and our content for the AI world.
And I think that'll uh that is I think what everyone needs, and I think we're positioned to do that.
And already there.
So I think that's like that's the core focus for us is believing like, you know, solve for the world of people using coding agents.
But as we do that, I think we're also building the platform that people need for running any agent.
So that'll be the next phase once you get through this that any agent that's running of any kind should run on this uh layer here.
That's we're focused on doing.
Um honestly, it's like a super, you know, it's a really fun uh field of okay to have this gig.
It's a fun gig to be in the middle of uh all the change in software world and then to be at a place like Docker that's doing this, right?
Um that's so critical and so core.
It's a really fun time to be a developer because there's so much change.
It's also quite scary, this change.
You know, there's a lot of there is some uncertainty.
While there's so much potential, there's also so much uncertainty and so much pause, but also so much not pause.
Yeah.
I mean, it's such a such a conundrum, really, to think about the state of things.
But like everything is literally changing.
We didn't expect this to be where it's at a year from year ago.
Like a year ago, the conversation was this direction, but not where it's at currently.
And it's it's clear that everything from the bottom up is changing about how we develop software, how we deploy software, how we have to secure it, etc.
It's a fun time because we get to rebuild it all.
So if you're an old hat, you're like, uh, okay, that sucks.
I don't want to have to like learn new stuff.
But if you're a new hat, you're like, sweet, let's build some cool stuff.
But it is a wild ride we're on right now.
I mean, everything, everything is changing.
It is a wild ride.
Also, at least for me, like, you know, look, I struggle to answer the like, hey, where will engineering be, and like will software development be in in two years.
I don't know.
Uh I can estimate and I can I can guess a bit.
But right now, what's really fun is like fundamentally, I think people become engineers to like build stuff, uh like solve problems and innovate.
And like coding has been a key way to do that.
We just get to like do that at like 10x 100x the throughput now.
It's just fun.
I can like have an idea and and go.
Um, and that's just that's just fun.
Couldn't say it about myself.
Try thank you so much for sharing time with us, doing this hard work, leading the charge, and being cool.
Thank you.
Thank you all.
It's a lot of fun.
Good talking to you.
All right, that is your changelog interview for this week.
We hope you enjoyed it.
And we have a members-only bonus segment for our changelog Plus Plus people.
You get an extra 10 minutes of us talking Ralph, talking open claw, and talking role changes.
Join today at Changelog.com sort of the skills of like deck leads better.
Thanks again to our partners at Fly.io, to our B freaking residents, Brake Master Cylinder, and to you for listening.
We appreciate you hanging out with us each week.
That's all for now, but we'll be back on Friday with a Mel Hussein, talking career renaissance, aerospace, my return to the blogosphere, and more.
Looking forward to it, and talk to you then.