For a few months, Kim Lewandowski tried the radical experiment of sitting still. She had helped build Chainguard from a new company into a substantial name in software security, and she had stepped away from day-to-day product leadership. Reflection seemed reasonable. Then, in June 2026, she announced another venture. “I’m not very good at sitting still,” she wrote. Its purpose, at least as she described it, was the work she had returned to across jobs and companies: making developers’ lives easier.
It is a deceptively modest ambition. Developers spend much of their time tending to other people’s code, tracing where a package came from, and dealing with problems that arrive long after a feature ships. Lewandowski’s career has moved through engineering, startups, product management and open source governance. The jobs have changed; the frustration with avoidable work has endured. At Chainguard, she helped turn that frustration into a product line. Her new project, still unnamed publicly, points toward developer environments in an AI world.
Before the supply chain, a laser
Her early résumé has an unusual opening for a future product executive: she wrote software at Lawrence Livermore National Laboratory. In a 2025 interview, the host recalled her description of working on code connected with an extraordinarily powerful laser and nuclear fusion. Lewandowski remembered government work as a place for projects that could scarcely happen elsewhere. Yet she was in Silicon Valley during the startup rush of the early 2010s. The pace, freedom and possibility were difficult to ignore. She wanted in.
She entered that world as an engineer, still writing code. The transition taught her something that would shape the rest of her career. A team could build an impressive thing and still fail to find the people who needed it. She later recalled the old “if we build it, they will come” mentality, and how little it guaranteed. The lesson led her toward product work: asking what someone needed before assuming the code had supplied the answer.
One experiment was Spotwag, a service connecting pet owners with trusted people to help with boarding. The startup was acquired by Rover. Another stop was Brit + Co, where she headed product and engineering. The subjects were a long way from cryptographic signatures and software bills of materials. The skills were portable. Each job gave her another view of how technical work becomes something another person can choose, understand and use.
Google offered her a chance to learn product on a different scale. She has said she went there expecting to discover how a large company did it “the right way.” What she found was more useful than a secret manual: even Google did not have everything figured out. For someone inclined to ask questions, that was permission to keep asking them. She would later advise her younger self to “Be very curious” and to assume less about who holds the answers.
“Ask a lot of questions. Be very curious.”Kim Lewandowski, 2025 interview
The problem hidden in plain sight
At Google, Lewandowski worked around open source projects and software supply chain security. Her contributions included SLSA, a framework for understanding the integrity of the steps that turn source code into a released artifact; Tekton, a framework for building delivery pipelines; and Security Scorecards, which helps assess open source project practices. She also served on the founding boards of the Open Source Security Foundation and the Continuous Delivery Foundation. Those roles put her near a question that reaches far beyond any single company: who can trust the code everyone else depends on?
Modern software is assembled from other software. A developer may add a library or pull a container image with a single command. The convenience is real, but so is the difficulty of knowing how that component was built, what it contains, or who will maintain it tomorrow. Large organizations can pour people into checking these questions. Smaller teams often have the same exposure and fewer hands. The work is repetitive, technical and easy to postpone until a security alert makes it urgent.
In 2021, five former Google colleagues - Lewandowski, Dan Lorenc, Matt Moore, Ville Aikas and Scott Nichols - founded Chainguard. They had worked together on open source and security problems. Their initial plan joined public projects with commercial products, a combination that matched Lewandowski’s own path across community work and product development. The company’s first public funding announcement was a $5 million seed round. The amount matters less than the problem it put on the table: make software components safer before they reach developers.
Her contribution was not confined to explaining the problem. As product leader, she helped shape the practical answer. Chainguard Containers offered maintained, minimal container images built for teams that already used containers. Later, Chainguard Libraries extended the idea to Java dependencies. The aim was to reduce the routine repair work customers faced when vulnerable components arrived in their projects. In Lewandowski’s formulation, a security product had to make a developer’s day easier, or the extra friction would limit its appeal.
In a 2025 conversation, she described the internal system for making those components as a “factory.” Chainguard built open source code from source, used hardened build systems and recorded what went into the result. She used the everyday analogy of clean water: companies rely on a supply, and the supply ought to be trustworthy. The image makes a complicated engineering proposition legible. People should not need to inspect the pipes every time they turn on the tap.
The analogy also reveals a product manager’s instinct. She did not ask developers to become experts in every upstream package or to add a ceremonial step to each release. She wanted the better choice to arrive in a familiar form. A container image is still a container image; a library is still a library. The change lies in what happened before the developer received it. That is a quieter kind of innovation than a dramatic interface, but it can alter hours of work across a team.
A product person in a security company
Security companies often speak in alarms. Lewandowski tended to speak in time saved. She said the most distinctive thing about Chainguard’s product was that developers would use it and see daily toil fall. She understood why people resist a new security tool: it can feel like another form to fill out, another process to appease. Her measure was whether a team could move faster while dealing with fewer vulnerabilities in code it did not maintain itself.
That measure affected how she talked about customers. In the same interview, she described the satisfaction of seeing a team start with a small number of images and then ask for more. Expansion, to her, showed that the original choice had worked in daily practice. Chainguard reported large reductions in known vulnerabilities for some users, but her favorite part of the story was the return visit: people who had tried the product wanted to use it more widely.
It was an outlook shaped by the failed certainty of her early startup years. Build the thing, yes. Then watch what happens when someone uses it. Listen when they ask for a different version. Lewandowski said customer feedback helped shape the roadmap, including feedback from Snowflake, one of Chainguard’s customers. The habit sounds obvious until an organization has spent years learning to defend its own assumptions. She had already learned that elegance on a whiteboard was a poor substitute for use in the field.
“We’ve built a product that developers love”Kim Lewandowski on Chainguard’s product test
Chainguard grew beyond containers. At its Assemble event in March 2025, the company announced Libraries and virtual machine images. Lewandowski appeared alongside colleagues to tell the founding story and discussed Libraries onstage with Jason van Zyl, the creator of Apache Maven. The setting made the arc visible: the person who had helped establish standards for software provenance was now presenting a product meant to put those ideas into the daily work of other engineers.
Another first day
In September 2025, after nearly four years leading product, Lewandowski said she was handing the role to Patrick Donahue and shifting toward strategy. She planned to reflect on the next chapter. The pause did not become retirement. In June 2026, she announced she was working with Brad B. and Wojciech Kocjan on a new venture, inviting prospective teammates and beta testers to contact her. She did not unveil a product name or claim a finished answer.
By August, her public language had narrowed the area of curiosity: developer environments in “our new AI world.” That phrase suggests a fresh technical setting for an old question. New tools can write more code and change how people build it; developers still need an environment they can understand and trust. Lewandowski had already spoken about AI as a force producing more code and new security questions. For the new venture, the announced goal remains simpler: make developers’ lives easier.
There is a temptation to draw a neat line through a career like this, as if a pet sitting service, a fusion lab and container images were always steps in a master plan. Lewandowski’s own account is more human. She saw startups and wanted to try one. She learned that code alone was insufficient. She went to Google to learn product, found more questions, and accepted a chance to build Chainguard because she thought she would regret leaving it unexplored. Then she tried sitting still and found another question waiting.
The through line is curiosity with a practical destination. It asks who is doing the tedious work, why they are doing it, and whether a better product could take some of it away. Lewandowski has carried that question from one unlikely field to another. The new venture has yet to show its full shape. The impulse behind it is already familiar.