 So let's move on to our next speakers. It's Marina Moore and Priya Wadhwa. I'm going to talk about software supply chain integrity with SIGSTOR. Please take it away. Awesome. Marina, are you ready? Okay, cool. Let me share my screen. Okay, great. Welcome everyone to software supply chain integrity with SIGSTOR. We'll just jump right in. Hi everyone, I'm Marina. I'm a PhD student at NYU researching secure software updates and supply chain security more generally. I'm a maintainer of the TUF project, the Update Framework TUF, as well as Uptame, which is the automotive variant of TUF. And I do work in various other open source supply chain projects including SIGSTOR and Notary and various other projects. Hi, I'm Priya. I'm a software engineer on the Google open source security team. I work on open source projects like SIGSTOR and Tecton. In the past, I've worked on open source Kubernetes developer tools like MiniCube and Scaffold. Fun fact, I like to play the drums, but it's probably not so fun for the people I live with. All right, so why do we need SIGSTOR? So as everyone who's here probably is aware that we as a community have a problem with supply chain security. And so what SIGSTOR is looking to do is looking to find a way to securely distribute all the pieces involved in that, which includes the software itself as well as things like S-bonds and other information that we securely distributed to people. The way it does this is it provides a set of tools and services for easy code signing and verification. It's all backed by a transparency log that is completely public and it stores all of the metadata in a public place so that you can make sure that nothing's been changed. Entities in SIGSTOR can sign and publish artifacts, publish signatures, and monitor logs in this transparency log. So we're going to talk in detail a little bit about the tools and services that SIGSTOR offers. So I'm going to start with Cosign. So we started Cosign a few months ago because there wasn't a really easy way to sign container images, and that's kind of how Cosign started as a project to automate signing containers from beginning to end. So you can kind of see in the terminal screen grab on the slide that you can use Cosign to generate a public-private key pair. You can use it to sign your image without private key pair, and you can verify your image with the associated public key as well. And Cosign actually has support for signing with different methods. You can use a cloud KMS system if you have one available, or even hardware like a UB key. So I mentioned that Cosign was started as a project to sign container images, but you can actually use it to sign a lot more. We've added built-in support for other kinds of software in recent months like Waza modules and Intodo attestations. So in the example on the slide, we're actually just signing a regular file. With Cosign, you can upload that file to an OCI registry and then sign it just as you would a container image that lives in your OCI registry as well. And that signature is stored alongside the image in the registry as well. So Cosign actually announced a 1.0 release a few weeks ago, so it's ready to be used. And yeah, definitely check it out for anything you need to sign. So the next tool in the six store ecosystem is called Record, which is the public transparency log. You know, it's a transparency log, so it's an immutable and temporary resistant log in which users can sign, can store signed metadata, sorry. And there's a tool, the RECOR CLI, which makes it easy to query anything that's been uploaded to the log as well as append new metadata entries to this log. One of the cool features about RECOR is that it also provides, by default, a timestamping service which uses the RFC 3161 timestamping service standard and to automatically timestamp anything that's uploaded to the log, so that you can make sure not only that the thing that's uploaded that you're verifying is the thing that was uploaded to the log, you can ensure some timeliness properties about the things that are included in the log. And the final kind of core six store tool is Fulcio, which is a free root CA that uses OACD email address verification to kind of simplify developer key management. So instead of individual developers or anyone who's signing metadata or images, having to store and manage private keys and make sure that they stay safe forever, what Fulcio does is it allows users to use their existing OACD supported email addresses to verify their identity. And then Fulcio issues them a shortlist certificate which they can use right away to sign that metadata or information. And then in the certificate of shortlist so the developer doesn't have or user in general doesn't have to securely store it or maintain it over time. Oh, and everything is published to RECOR for timeliness and auditability so that users can make sure that the certificate was valid within the window in which it was used. I think I sketched one, sorry. Okay, I'm going to do a quick demo now to kind of show how Cosign RECOR and Fulcio can all work together to make signing really easy. Let me figure out how to share my terminal. Okay, there it is. Okay, so the first thing I need is just a piece of software that I want to sign. So I already built just like a really simple docker image and pushed it to my own registry. So I want to sign it and I'm going to use Cosign and it's pretty easy. It's just a Cosign Sign command and then the name of the image. So at this point I could pass in like a private key or a reference to a KMS system for signing, but I'm going to take advantage of Cosign's integration with RECOR and Fulcio and request a certificate instead. So just run Cosign Sign and run the name of the image. And it will redirect me to this OADC flow, which I realize maybe now people can't see. Oh, cool. Redirected to this OADC flow. So this is how I'm going to authenticate my identity and prove that I am myself. So I'm going to log in with my own personal email account. And that's pretty much all I have to do. If we go back to the terminal, we should see that Cosign was able to sign this image for me. So the way that it did it was it generated an ephemeral public private key pair, which is just stored in memory and will eventually be thrown away and requested a certificate from Fulcio. So this certificate is a shortlist certificate like Marina mentioned, it's only valid for about 20 minutes and it'll include information like the email address I used to authenticate and the public key that we'll use for verification later. So Cosign also added an entry into the record transparency log to keep track of the signature and finally push the entire signature to my registry where it'll live alongside my image. So as a developer, it was that easy to sign my image and kind of like tie it back to my identity. But as a user, how do I verify that this image actually came from Korea? So again, it's pretty easy. We just want to verify the command and the name of the image and Cosign should just do everything for us. So this is pretty nice. So the first thing it does is verify that the signature is valid against the certificate. The next thing it does is make sure that an entry was put into the transparency log when the signature was signed and that it was during the window of validity for the certificate. And finally make sure that the certificate came from a trusted root CA which in this case is the full CO root CA. And then there's a little bit more information like who signs the image, it was me, and the actual payload that the signature covers. So we have the name of the image in there and the digest of the image itself. So as a user, if I wanted to find this information in the record transparency log, I could use this log index that was provided when Cosign did the signing. So we can use the record CLI commands to get this log index. And in here we have the base 64 encoded signature. We have the certificate that was issued. The shot 256 digest over the payload. And if for some reason I've lost this log index, I can also search the entire transparency log by email and I can find everything that I've ever signed in this log, which is a bunch of stuff. But the image that we just signed is somewhere in there. Presentation. It's not changing. You might have the presentation window would be different. Yeah. The risk of doing things live. I don't know why my presentation is tapping out. Reena has a copy we can switch over her display. Oh yeah. Yeah. Yeah, I will get that. I should see a share screen button on the bottom. Yeah. Presentation. They can see that. Yes. Awesome. All right. Thanks so much. Thanks for being flexible. Yep. So these things work. Okay, cool. So this diagram basically covers everything I just went through in the demo, but in more of a diagram kind of way. So on the left side, we have how developers might interact with the six or ecosystem. And on the right side, we have, we should see how end users might interact with it. So on the left side, we have developers. Who will want to publish some sort of signed artifact and they'll request a certificate from the full CO certificate authority and authenticate their ID with OIDC and by logging in with their email. We'll see, we'll provide a signature and certificate which developers can store in the report transparency log. On the other side, we have end users who are trying to verify that the signed artifact came is valid. And so they can look at the signature in the report transparency log also find the certificate and make sure it's valid. And they can also ensure that the certificate came from a trusted route certificate authority, which again in this case would be the full CO certificate authority. All right. So now I'm going to talk about a few integrations of the six or ecosystem with some other projects in the supply chain security space. So first thing to talk for a minute about the update framework or tough, which is a framework for secure software updates that uses metadata about artifacts to design metadata about artifacts to prevent notice tax on software update system. It's based on this principle of being compromised resilient, which means so that if any single developer key or repository is compromised, not sorry repository, but if any single piece of the system is compromised, then it has both methods to recover from these compromises as well as redundancies to ensure that single points of failure don't lead to people installing malware or other bad software. So the first way that six or uses the tough project is to do what we call the tough route of trust, which is kind of the root of trust that underlies all of these other pieces of the six or ecosystem. So the way this works is we held this offline ceremony where we generated some offline keys and we use them to sign metadata that includes the public, the public keys for various parts of the six or ecosystem. And this includes the full-year root CAs, roots through duplicate, as well as the keys used to sign things in the record log. And so this allows for both re-vocation of any of those pieces of the six or ecosystem if anything goes wrong. It kind of creates an underlying trust levels that it creates it makes it easier to kind of change trust to different pieces if you start with this, this route of trust. And these offline keys. The next thing I want to talk about is in Toto, which is a framework for software supply chain security more generally, it's based on this idea where you verify every single step in the supply chain and you ensure that the correct person did that step. It was done in the correct order and all the steps you expected to happen were all done before the software was delivered. So here we have an example of an in Toto attestation for, I get her project basically that shows that Priya authored this commit to the awesome project and I reviewed this commit and we both attest that we did those different steps and then we can pass it to the next stage in the supply chain and then you build up this chain of attestations to show that you have this which led to this artifact and then that artifact led to the next one in the chain. So record and currently includes support for both calf and in Toto types so that any kind of metadata that is generated for either these two projects can then be stored in the transparency log to get some extra security properties and auditability on these different metadata pieces. There's also a couple of in progress integrations. First of all, having cosine generate tough metadata automatically so that you can have kind of all these things just automatically work together as well as kind of a reverse integration of integrating full SEO back into tough to create easier developer key management for the tough project itself. Using the full year root CA instead of requiring developers to generate and secure public private key pairs. Too far. All good. Slides are hard today. Okay, cool. Okay, awesome. Yeah. So I'm going to talk a little bit about how we've been integrating six or with the tech time projects. So for those of you who may not know, tech time is an open source the ICD platform on Kubernetes. And it basically just lets you run your build pipeline on Kubernetes itself, doing things like building images or anything you normally do with a CICD platform. And I've been working on tech time chains recently, which is the supply chain security manager for tech time. So the idea behind chains is that it runs alongside your tax on pipeline. It basically observes your pipelines and provides any sort of supply chain security you might need for them. So this includes signing artifacts that are built in your pipeline with cosine and also includes adding entries for these signatures to the record transparency log. It can request certificates from full CO and it can also create comprehensive build provenance for your pipeline with in total attestations and store those attestations in record as well. So what does this look like in practice? Like what is something, what can you actually do when something has been signed with chains? So under the hood, we're using all six or tools. We're already familiar with them. And this is where it gets a little bit meadow because the most recent tech time change release was actually signed by chains itself. So we can use the most recent release image kind of as an example to show how users can interact with it. So the first thing that users can do with this image is they can verify it against the tech time public key, which just lives as a file in our GitHub repo for reference. So you can go to the next slide, pass in the public key and the image name and you get the same verification that we saw earlier in the demo. So the verification also includes the SHA-256 digest, which I kind of put in bold on the slide. And if we want to get build provenance for this image, we can use the recourse CLI command to get some more information. So if we go to the next slide. You can actually query the transparency log for build provenance with the digest of the image itself. So you can run a recourse CLI search and the digest and it'll set out all of the matching entries in the log. And you can get some more information from that entry specifically and it'll print out the entire in-todo out of build provenance for the build of that image itself. So I had to cut out a lot of information from this provenance so that it would fit on the slide. But it includes things like the name of the image, the digest, the parameters would be any environment variables that were set during the build. And the recipe is a list of steps and each step corresponds to a container that was run in the build. So in the recipe you can see the list of containers that were run, the order they were run in and what command or script was passed into each container. So you can really get a sense of how this image was run in its entirety. All right. So some future steps for 6-store. So cosign, one of the 6-store tools, already had its 1.0 release. But recore and folcio, those are still upcoming. They're coming up pretty soon. Some other upcoming projects are using, are issuing sorts to other nested folcio instances so that you can have kind of a local instance of folcio based on that same root of trust, as well as integrations with more tooling with any other tooling in this secure software system. If you'd like to get involved, here's some links to the website and Slack. It's a super open and welcoming community in my experience. So feel free to come with questions or ideas or anything as well as there's a weekly community which you can get info on from the website. Thank you. And feel free to email us and I think we have some questions in the Q&A that I will look at right now. Very cool. Let's see what's up. So how do you know how to trust a TSA that's used? So the TSA is based on that same recore root of trust key. So it's signed by recore when it's uploaded to the transparency log. So you can trust it like as much as that. I think similar for the next question of how you trust the cosine ecosystem. I think knowing who exactly to trust to sign it is in some ways an individual question of like the policy of the consumer of the software. But you can get information about it from the ecosystem to then make that decision. Okay, so you can take any of these two. See, I understand the build containers are signed by cosine. Yeah, you can use cosine to sign on containers that you've built and already pushed to a registry. What infrastructure is this running on? I think right now like the production report that the full C are running as deployments on Kubernetes. The last time I checked their work. Okay, here's one. What OS and software platforms trust the full C route. Is it added against the same standards as other CAs. Like, like we said in the previous slide, it's still just before it's still like waiting for the one point a release. I don't think it's currently put into any or two software platforms that would be kind of a, I don't know what the next step for the project as it is in a one point a release and is ready for large scale use in this. Yeah. I see it's cosine replacing memory or Sydney. I don't know how to say it. No, I think they're separate projects with their own kind of things that they do. It's definitely not. They kind of approach the problem from different angles and different pieces. I think memory does a lot of the registry storage pieces. They're super important. And then six to does the kind of the transparency log pieces a little bit differently. So they just kind of approach it in, in slightly different ways. This is great. Thank you so very, very much. Do we have any, any parting shots last words? Or Parthian shots. Just thank you all for having us. Yeah. Thank you so much. And definitely if you're interested in the project, come to a community meeting or hang us on Slack. Excellent. That's a great way to wrap up that. So thank you again very much. Priya Marina. Thank you so very, very much.