Sigstore co-creator talks GitHub, Kubernetes and next steps

As an infrastructure engineer for a major cloud vendor, the creator of the Sigstore software supply chain security project was ahead of his time. This year, Dan Lorenc has found himself in the right place at the right time, as first Kubernetes and then GitHub integrated with Sigstore.

Lorenc, who worked at Google from 2012 to 2021, began contributing to open source projects in the Kubernetes community in 2016, and along the way, developed the tooling that would become Sigstore to verify the provenance of open source code packages. Sigstore consists of three subcomponents: Rekor, a publicly hosted cryptographic transparency ledger that preserves a record of software supply chain attestations; Fulcio, a certificate authority; and Cosign, a command-line tool for signing and verifying container images.

Sigstore was first released in March 2021. By September, Lorenc had left Google to co-found Chainguard, a commercial backer for Sigstore that markets tools for privately hosted use of the project's software. In May 2022, one year after a presidential executive order pushed software supply chain security into the national spotlight, the Kubernetes project adopted Sigstore in production for signing artifacts and verifying signatures. This week, GitHub said it will use Sigstore to verify npm packages associated with Node.js applications in its npm registry. GitHub also contributed a JavaScript client for signing and verifying Node.js packages with Cosign.

It's been a dizzying 18 months for Sigstore and Lorenc, both technically and commercially. In this Q&A, he talks about how an IT infrastructure engineer came to create one of the hottest projects in cybersecurity, and what's coming next.

What made this opportunity compelling enough for you to leave Google and found Chainguard?

Dan Lorenc: I had been working in software supply chain security for probably the last four years at Google. Nobody really cared about it in the beginning, and I was just kind of bothering people and annoying them. And then all of a sudden, everyone started to care. We had seen a steady drum up of increasing attacks on open source and package managers, and then the SolarWinds attack happened -- that was the big shift. After that, there was an executive order from the Biden administration, five or so months later, about software transparency. Attacks kept rising. It seemed like the right time, finally, for the industry to take this seriously. Since I've been working on it for so long, it seemed like a great opportunity.

What made you get into it in the first place?

I built the first release of minikube and published it on GitHub. And everyone just downloaded it and ran it on their laptops. That kind of terrified me.

Lorenc: It was the minikube project in Kubernetes [in 2016]. That was the first open source code I wrote. Back when I started in 2012, Google had to be conscious of nation-state attacks. All the big tech companies did. It was just the cost of doing business at that scale. Working on the infrastructure team, I got to see that. And then when I shifted over to developer experience and open source and particularly minikube, none of that was around anymore, so I built the first release of minikube and published it on GitHub. And everyone just downloaded it and ran it on their laptops. That kind of terrified me, that they didn't ask any questions about where it came from or if it was secure, or any of that. That's what got me into that space.

You've talked about wanting to borrow from the playbook of Let's Encrypt, and how there was a real "before and after" with that project. What would be the "after" you envision for Sigstore? Have we gotten there yet?

Lorenc: We're getting close. What Let's Encrypt did was take an ecosystem that has existed for decades and build new tooling, standards and automation to take something that used to be hard, time-consuming and manual, and change it so you could build websites and infrastructure that was secure by default. Now with Let's Encrypt, the way that technology has been adopted, you can just put TLS:true in a configuration file and all this stuff is automated for you, so everyone does it. That's what we're trying to do with Sigstore -- new tools, standards and automation to make the existing technology practices easy enough that they can be turned on by default, so everyone has them without having to think about it.

We have a two-point strategy: One is working with projects like Kubernetes to integrate it and figure out what they need, because they're both really representative of some of the more complex use cases, and also they're highly critical, so securing them has an outsized impact. That work took months to do, but it was a great learning experience, and now we can apply that faster to other, similar projects.

And then on the other side, the integration that GitHub is working on has a broad horizontal impact, the long tail -- so rather than one project at a time, GitHub is working with us to make Sigstore adoption easy and automatic for everything on Node.js. It's not one particular project, it's everything that goes on to the package manager.

What does that mean for someone who wants to use upstream Kubernetes or Node.js packages on GitHub? What can they do now that they couldn't before?

Lorenc: There's this interesting gap in a lot of open source ecosystems today where you can review the code, on any git repository, and check to see if it's secure and if you want to use it. But then when you consume it, you get it through a package manager. You don't take the source code and build it yourself in most cases; you run npm install or pip install or something like that. There's no actual connection between those bits you download from the package manager and the ones that are in the git repository. It's the same as that minikube example I mentioned -- that was just something I uploaded from my laptop, and people had to trust that I actually ran the right build commands. The same is true for every package on npm and every package on PyPI and most other ecosystems. Sigstore is building a way to tie those two pieces together. From the binary, you can tie it back to the source code that it came from.

When you download a release of Kubernetes, you can be sure that the bits you got are the same ones that the release team intended to release and that they actually tie back to the source code on GitHub that thousands of community members have maintained and audited and fixed bugs in.

So a bad actor couldn't slip in the middle and send you some malware.

Lorenc: Exactly.

What will be the next big item on the to-do list?

Lorenc: The next big target is the general availability of [Sigstore] infrastructure. For the last year or so, it's been running in an experimental beta mode, as we load tested and got through our security audits and get a team actually staffed up with pagers to support this for open source. We've got a burn down list. This is all being done in public. You can see the remaining tasks and what the teams are working on. It's folks from a bunch of different vendors collaborating here. So Chainguard -- my company, Google, Red Hat and GitHub are going to be joining the rotation as well now.

Okay, and what exactly will that team be doing day to day? Supporting the Rekor transparency ledger as it's running?

Lorenc: Yeah, there are production services that are running. That's what makes Sigstore a little bit unique. It's not just code or tools you download. There's operational infrastructure that's going to require people carrying pagers and monitoring for SLOs and guaranteeing uptime, so people feel comfortable depending on it.

Are the companies donating their engineers' time, is it funded through OpenSSF or a combo?

Lorenc: Sigstore is an OpenSSF project, and most of these companies contributing are members. For now, it's companies donating and committing engineering time. Once we get this stable, and we're not still debugging alerts and everything like that, we want to seek funding through the OpenSSF to staff an SRE team.

There's been discussion recently about the challenges of cloud-native software bills of material (SBOM). Is that something Sigstore might have a role in?

Lorenc: We're spending a lot of time on those SBOMs now. I don't think cloud-native environments are completely impractical, I think there are different challenges, but also some benefits to doing SBOMs. There's a lot more code, there's a lot more moving pieces and you're deploying much more frequently. And that means the SBOMs all need to be updated and changed and travel around a lot faster.

There's been a few open source projects that we've been collaborating on. Just like Kubernetes did Sigstore integration, they're also one of the first projects to produce SBOMs. And some of our engineers helped out with that, so when you get a Kubernetes release, you can get SBOMs for it. I think a lot of the challenge coming up now is that people are making use of them and getting insights. That's where we're focusing a lot of our efforts -- not just making your own and checking off the box, but actually getting useful data and helping make your team more efficient and respond to vulnerabilities faster with the SBOMs that you have.

So much has happened in just one year -- where do you think things will be with software supply chain, SBOMs and cybersecurity a year from now?

Lorenc: Most organizations know this is a problem, they know they have to do something about it, and they're all starting to figure out their 2023 plans. This year, everybody's talking about it, but only a few folks are actually taking steps right now. But I think that's how massive industry changes like SBOMs are typically carried out, and this is probably faster than any other one I've seen. That regulation was only last May. We're barely a year in and people are already doing it.

Beth Pariseau, senior news writer at TechTarget, is an award-winning veteran of IT journalism. She can be reached at [email protected] or on Twitter @PariseauTT.