When Dan Lorenc released the first version of Minikube, people did what developers hope people will do. They downloaded it. They ran it. A small tool for putting a Kubernetes cluster on a laptop had found its audience. Lorenc, though, kept thinking about the step nobody had taken. The users did not know him. They had no obvious way to inspect the chain between his code and the file now running on their machines. Yet the download had crossed that boundary without a question. For a builder, that is a flattering sort of trust. For an engineer who had seen Google's internal security concerns, it was alarming.
He later said the experience “kind of terrified me.” The line has endured because it locates a large technical problem in a small, familiar gesture. Click. Install. Continue working. Modern software is built from other people's code, and the acts of finding, packaging and updating it are so ordinary that their risks can disappear into routine. Lorenc began asking how a user could know where a piece of software came from, what happened while it was built, and whether its claim to be the real thing could be checked. It was a question about evidence, not instinct.
A machine shop education
His route into that question began in mechanical engineering. At MIT, Lorenc designed a desktop milling machine kit for his 2010 undergraduate thesis. The proposed kit was intended to teach students electromechanics as they assembled it and CNC machining as they used it. The thesis considered software, electronics and the physical parts as a system. It is a useful early glimpse of a habit that later became central to his software career: the finished object matters, but so does the process that produced it. A machine can be admired from a distance; to trust its tolerances, someone has to look inside the process.
Lorenc joined Google in 2012 and worked there through 2021. He began in infrastructure, where large companies had long treated sophisticated attacks as a real operational concern. Later he moved toward developer experience and open source. In 2016, Minikube brought those worlds together in an uncomfortable way. A tool could be delightful for developers and still leave unanswered questions about its origin. Lorenc's own release was the example in front of him. He was no stranger with bad intentions; the problem was that users had no reason to know that from the file alone.
Several projects followed the practical problems developers met each day. Minikube made Kubernetes approachable on a laptop. Skaffold and Kaniko addressed parts of the container workflow. Tekton approached build pipelines. Lorenc's part in these projects was not a single heroic invention; it was sustained work among teams and communities. That matters in a story about supply chains. No one person builds the entire stack. The tools that seem to arrive in one neat package are the result of many hands and many handoffs. Security has to survive those handoffs too.
Put a receipt on the software
Sigstore, first released in 2021, gave the concern a more direct form. Its tools help software producers sign artifacts and help users verify them. Cosign handles signing and verification; Fulcio issues short-lived certificates; Rekor records entries in a transparency log. The names are technical, but the idea is plain: when a package says where it came from, there should be a way to check the claim. Lorenc talked about making that process easy enough to become a default, drawing a comparison with how Let's Encrypt simplified certificates for websites.
The timing gave the project a wider audience. The SolarWinds compromise had drawn attention to the routes by which trusted software can be changed before it reaches a customer. Lorenc said he had spent years raising supply chain concerns at Google while few people wanted to hear them. Then the conversation moved. Kubernetes adopted Sigstore in production for signing artifacts in 2022, and GitHub moved to integrate it with npm package publishing. Those integrations did not make every download safe. They showed that provenance could travel through infrastructure developers already used, rather than living only in a specialist's checklist.
“Everyone just downloaded it and ran it on their laptops.”Dan Lorenc, recalling the first Minikube release
Lorenc and colleagues founded Chainguard in late 2021. The founding team included Matt Moore, Kim Lewandowski and Ville Aikas, people with experience across open source infrastructure. Their company began with tools that let developers verify what they were building and deploying. Then the business changed direction. Lorenc has described walking away from an initial product after customer feedback pointed them toward containers. The distinction is revealing. They kept the underlying concern about trustworthy code and shifted the place where they could make the most difference: the components customers put straight into production.
A container image is an assembled piece of a software environment. It may include an operating system base, language runtimes and other dependencies. A team can spend time investigating each one, or it can use an image supplied and maintained by someone else. Chainguard's bet was to rebuild minimal images from source, maintain them and provide provenance with them. That turns a recurring chore for each customer into a process the company performs at scale. The model asks customers to trust a supplier, of course. Its answer is to make the supplier's process more visible and the components more consistently maintained.
The difficult art of changing course
The founder's job changed with the product. In a 2025 interview, Lorenc said the company had learned to follow customer feedback toward containers, and offered an unromantic lesson about selling them: “Innovate on your product, not your go to market motion.” It is a line with the dry edge of a person who has discovered that an original approach to enterprise sales can be less charming to buyers than to founders. He also described Chainguard as a remote-only company and identified growth, connection and opportunity for employees as the real challenges of that arrangement.
The company expanded its catalog beyond containers into virtual machine images and software libraries. Its 2025 Series D raised $356 million. These are company milestones, not personal trophies, but they show the scale at which Lorenc's old question is now being asked. A developer may begin with one downloaded executable. A large organization has thousands of such choices passing through build systems, registries and teams. The difference is mostly one of repetition. A weak assumption made once is a mistake. Made thousands of times, it becomes an operating model.
Lorenc's writing adds a less corporate note to the story. He is willing to use a vivid image or a joke to explain a difficult system. In one essay, he used an inverted double pendulum from an MIT course to discuss management. His X biography has listed him as Chainguard's “Primary Ariba Admin,” a wry title to set beside CEO. The humor is not incidental. Security prose often sounds like a warning siren that never stops. Lorenc's best explanations make the work look like what it is: a collection of awkward human decisions, technical constraints and occasionally absurd paperwork.
When finding out gets faster
By 2026, another problem had moved to the front of his writing. AI systems were finding vulnerabilities at a pace that threatened to overwhelm the human routines for checking reports, making fixes and getting those fixes into projects. Chainguard launched Athena as a coalition intended to coordinate that work. Members submit findings; the program checks and groups them, builds hardened versions under embargo, works with partners on additional protection and coordinates disclosure. Lorenc reported in July that Athena had processed more than 40,000 findings in its first three weeks. The count measures intake, not the number of independently confirmed dangerous flaws.
The issue is no longer limited to a signature on a package. A verified origin tells you who supplied a component and helps detect substitution. It does not repair a flaw inside the component, nor does it ensure a fix reaches every copy. Athena addresses those later steps. Lorenc's September writing described the gap between the speed of discovery and the slower business of getting a repair home. This is a hard logistical problem because open source is dispersed. A flaw may sit in a project maintained by volunteers, while its code is copied into products used by organizations that cannot update instantly.
The aspiration running through his work is therefore more demanding than a perfect scanner or a clever signing tool. He wants secure software to arrive as a normal part of development, with evidence of where it came from and a practical path for repairing it. The ambition is visible in Sigstore's easy verification, Chainguard's maintained components and Athena's coordinated response. Each has limits. Each also moves one step of the work closer to the place where developers actually make decisions. It is the engineer's version of good manners: leave the next person something they can inspect and use.
Back at the Minikube release, the absence of questions was the unsettling part. Today the question can be asked in more precise ways. Who built this? From what? Under which process? What happened after a flaw was found? Lorenc has spent the decade since that download building systems that can carry answers along with the code. The public may never celebrate a package because its provenance was clear and its patch arrived in time. That quiet outcome seems close to the point. A trusted download should be able to explain itself.