Technically Speaking

One of the most pressing concerns in today's world of software security is the concept of trust. And one of the key security concerns with open source is that it's hard to be sure of where or how software was built, making it vulnerable to supply chain attacks. And open source developers may not always have the time, expertise or resources to implement code signing, in addition to all the other non-negotiable components they need for their code to work. So how do we protect the open source ecosystem's security without jeopardizing the decentralized collaboration that makes it all possible?

00:36 — INTRO ANIMATION

A software supply chain attack happens when malware is inserted into legitimate software. This allows it to spread widely, as it evades detection while under the guise of coming from a trusted source. To avoid this, we adopt a never trust, always verify approach, or what's known as a Zero Trust security model. Zero Trust security assumes any user, asset or resource is untrustworthy, and therefore, must be verified before access is granted. Essentially, Zero Trust is a form of highly granular access control and distributed trust based on cryptographic hashes, session, user and systems data. Zero Trust technologies have improved other aspects of enterprise architecture, but have yet to be widely applied to the software supply chain. While it's easy to talk about the benefits of Zero Trust in theory, actually building a Zero Trust system requires a lot of planning and complexity where things like cryptography and code signing come in. So how do we use the technologies available to help us achieve Zero Trust? And how can we keep things open and transparent, but maintain our security? Let's talk to someone who spends a lot more time thinking about supply chain security than I do, Luke Hinds. Hey Luke, how you doing?

Hey, Chris. Good to see you.

So, there's been so much attention around supply chain security lately, and I've been spending time thinking about, well, how a Zero Trust approach could be a part of a solution here. And I know this is a topic of deep interest to you, so I'm curious why hasn't Zero Trust been so widely applied into this supply chain security space?

The paradigm's changed. There has been so much disruption where we've gone from monolithic services to propagating many multiple services, microservices and cloudification, scaling, elasticity, all of these things have come along. And I think for a lot of folks, they're still, especially in the security community, they're still trying to shift beyond the old paradigm, which was very much, it was a duality, everything that side was red and everything this side's green. This is inside our Citadel, everything outside there is bad, essentially. And cloud and hybrid cloud and this proliferation of dependencies and software and open source, it's really sort of accelerated so much that I think the security world is kind of playing catch up really.

With all the complexity that we create through those dependencies and services and all of that stuff, the only way we can manage all that is through automation. And Zero Trust is sort of a, it's a capability where we're delegating trust to systems.

That's exactly what I've been thinking. Cause traditional trust was, I know you're Chris, okay? And humans have been the sort of the enactment of trust, the trust starts with a human, they'll perform some sort of action. And this is one of the things that we've had to grapple with in sigstore, is that we're now trusting machines because everything is unattended. So automated, there is no juncture where the human can inject that trust as such. And this is where we're starting to look at, how do you trust a container where you have to trust the layer underneath, and how do you trust that? And then you start turtles all the way down, and then you're mucking about in the hardware then trying to establish what you can do there. And how are you going to bring that back up to the high layers? And it is complicated, and that's the big area that we're grappling with.

Yeah. I know we've seen, for example, security on the internet fundamentally changed with the introduction of Let's Encrypt and how at one point HTTPS encrypted connections were maybe the exception, not the norm, with introduction of Let's Encrypt and pervasive encryption and warnings from browsers, it changes everybody's behavior. Here you're focused on something a little different, you're focused on that supply chain of delivering software from a software project. Give us a quick introduction to sigstore.

At its core use, sigstore is about providing software signing. When I say software signing, it could be artifacts, containers, binary, software bills and materials, all of these components of the supply chain. And sigstore provides the ability to freely, so there will be a nonprofit public good service that we'll run, that will allow developers to easily sign their container images, their artifacts, and to verify these as well, with mission controllers and policy engines and so forth. So yeah, as you said, Let's Encrypt is a really good example, and we sort of borrowed that model, really, we want to become to software signing what Let's Encrypt was to HTTPS.

I'm fascinated by both the technologically on that notion of ease of access creates better, you know, proliferates how we think about security and changes fundamentally what becomes a social norm. So there's a bigger picture here, it's not just open source communities, you're creating a level of transparency for how code is produced. And this is a democratization of software supply chain security.

One of the core technologies that we use is something called a transparency log. And without deep diving into the technicalities of that, it's a public storage system which anybody can consultant and query. So with sigstore, whenever a signing event occurs, it's recorded into this tamper-proof store, which anybody can query and look up and retrieve information about who exactly signed what. So this really helps to alleviate a lot of the current concerns again, around key management. So one of the biggest fears people have around key management is key compromise. So if you lose your private key, as it stands today, you don't know how many things have been signed under your private key, with effectively your identity, somebody stealing your identity effectively. And with these transparency logs, because they are tamper resistant and they're in the public domain, then you can actually specifically see the extent the blast radius of a key compromise.

Well, Luke, this is awesome, and thank you for the fantastic work. And I'm thrilled for you that you were able to be a part of creating such enthusiasm around an open source project like sigstore. I've really appreciate the time. Thanks.

All right, It's great to be here. Thank you, Chris.

Our goal in open source is to think in terms of enabling development to accelerate and enable consumers of innovation. To build on the great work that's happening in communities, we need confidence and trust that what the producers of the technology produce is actually what the consumers of the technology are consuming. We're not saying there's no bugs in the software, but we want to be able to say that we know what you got is what you thought you got. And that's a huge step forward for improving security broadly at internet wide and global scales.

08:23 — OUTRO ANIMATION