 All right, thank you. Thanks everyone for coming. So yeah, what we're gonna be talking about today, Lightning Talks is super fast, is source attestations with a project called GitSign. So a little bit about myself, my name's Billy Lynch, I'm a software engineer over at ChainGuard. I'm a maintainer for the GitSign project as well as some other supply chain security projects, Tecton Chains, and I also make contributions to the rest of Sigstore and Tecton as well. So source attestations. So the first thing we're starting to talk about is what is an attestation? You might also hear another word called providence. So what's the difference? So the two terms here, providence we're really talking about sort of the who, what, where, when, why. So these are metadata about the artifact, where did it come from, what's in it, why is it here, why do we care about it? An attestation is the metadata itself isn't necessarily enough because that could be populated and produced by anyone. So an attestation is really trying to say is it coming from someone that we trust? Is it from a trusted developer? Is it from our CI pipelines? So really the difference between the two is providence plus some identity is what really makes up an attestation. And when we talk about identity, usually this is where signatures come into play. And if we're talking about signatures, then we're gonna be, you know, one of the things we're gonna be talking about is Sigstore. So Sigstore is a project under the open SSF. It's goal is to make signing software artifacts easy, whether this is images, git commits, anything part of your software supply chain, we wanna make that signing easy. And one of the really cool things about Sigstore is it has this process, what we call keyless signing, which allows you to basically generate ephemeral keys to sign objects and artifacts using certificate authority called Fulcio and to produce signatures and attestations and put them into a transparency law called Recor. And what this lets you do is sort of offload the complexity of managing keys to Sigstore tooling so that, you know, all you need to worry about is like making sure that those things are signed and not having to worry about managing GPG keys and rotation and stuff like that. So one of the tools that people are sort of most familiar with just because it's been around for a little bit longer is a tool called Cosign. And Cosign is really focused on container signing. So making, signing OCI images, it can also do blob stuff like that very easy. So Cosign has a really nifty command called Cosign Attest where you can actually attach provenance data to an image and sign it to make it an attestation that about that image, right? So you can attach S-bombs, you can attach, hey, like, hey, we ran this check on this image and you can attach it and upload it as in the same registry. So you can see at the bottom here, there's this .att file that actually has the same SHA within the tag that references the image that it's attesting to. So this really nifty trick, what it lets you do is store the attestations in the same location, right? So if you have the ability to go fetch this image, you also have the ability to go fetch this attestation. So that's a really, really useful tool, really, really powerful. So one of the things that we were sort of thinking about for Git sign is we have this behavior with Cosign, we can add attestations to images. OCI images are just one artifact, one part of your software supply chain. Git commits are another part, right? The source that goes into your CI, the source that goes into the images that you build are another artifact that you might want to add attestations to, right? So the question is what can we do there, how can we add attestations to repositories and make that easy for users? So as I mentioned in the beginning, one of the projects I work on is called Git sign. So the original sort of goal for Git sign was to make Git commit signing easy. So traditionally, you would use a GPG key or an SSH key to sign your commits, but with Git sign, you can actually use the full six-store keyless flow. And we were thinking, hey, can we apply the same sort of principle of Cosign Attest to Git sign? And that's what I sort of want to show off today. So we have a really quick demo. I'm just gonna hop over to the GitHub repo here. So this is just a sample repo that I put together. So within the Git sign repository, we have, it's right now a separate binary. We're working towards upstreaming into the Git sign binary itself, a tool called Git sign attest. So it's very much mirroring what Cosign Attest does. And as an example here, I have a few GitHub actions that are producing attestations, some things that you might want to attach to your source commits, right? So this could be an S-bomb. What are the transitive dependencies that are part of this repo that are going into my builds? I'm gonna hand wave a little bit here. Salsa source attestation. So I was talking right before this. One of the things that if you look at the Intodo docs, the Salsa docs, sort of the concept of two-party review and have all my changes been reviewed by someone I trust. Can we generate attestations for that and add that to the repository? Things like scorecards, static analysis. And you can extend this even further, right? Fuzzing, have CI tests ran against this. What were the results of those CI tests? These are all things that you might want to attach to these commits and put in a discoverable location so that other tooling knows how to find it and then can take advantage of it. So as an example here, here's the S-bomb tool that ran. So we're just using the Kubernetes bomb tool. So it's pretty simple, pretty straightforward. We're just checking out the code, installing the bomb tool, installing get sign to test. We're generating the S-bomb and then all we're doing here is adding this attestation, making an attestation associated to commit. So all we're doing here is we're running get sign to test. We're giving it the file. We're telling it's type spdx. And what this is doing is it's actually storing the attestation in a special ref space within the repository itself. So just like branches and tags, we can actually push and pull these custom refs. If you're familiar with get notes, this actually works in a very, very similar mechanism. But this is sort of a different carved out space where our goal is to really make this a space for to put attestations into put attestation data. And so what we can do with this is just push the repository. And if we cut over to the repo here, we just have a simple repo. We can actually go fetch the attestations. This isn't actually gonna do anything. It's already having cloned locally. We can do full get things with it. So we can actually check out refs attestations commits. And so this is gonna dump us into a folder that looks pretty gnarly, but it's actually just a structured sort of format for, hey, here are all the commit shaws that we have attestations for. So if we do, if we just get the commit shaw for whatever that means, so we have this a4a. So if you see the into a4a. Here's where we see all the prominence data and all the attestations, right? So each one of these files, there's sort of a pair here. It's storing what is the prominence data that we added. So in the case of the S-bomb, this is just an SPDX S-bomb, and then the corresponding signature is the signed data of that S-bomb that we produced using this extracurricular flow. So this looks pretty gnarly because it's a base-64 blob of the prominence data that we had before. And we can do this for the other things as well. So like for the review thing, here, let me just pipe this into jq. So it's a little nicer to see. So for this, just for the demo, I just sort of spat out the pull request data. So for this pull request, I reviewed it, I approved it, and we can actually store this data in the Git repository itself only using Git protocol, so you don't need to, you can do this in sort of a Git repo agnostic way, so it doesn't really matter if it's GitHub, GitLab, anything like that. And then the other thing is, so here's a nifty UI that we use for just inspecting RECOR log entries. So this corresponds to the S-bomb that I produced before. So you can see it was issued by Sigstore, it's a short-lived certs. I ran this three days ago. And what's really cool about this is because the cert was issued to the OIDC identity of my GitHub Action CI, we can use the certificate in this attestation to say, hey, no, this came from my CI, it came from like a known runner. It wasn't just a random developer that sort of produced the attestation, uploaded it to the repo, things like that. So that's sort of the value that Sigstore can add to a process like this. So this is a lightning talk, so we unfortunately don't have that much time to go into the specifics. But yeah, so I just wanted to show this off. It's things that we're working on, it's things that we're actively thinking about. You know, the things that are on our mind is source attestation data. Like I mentioned before, it's another part, it's another piece of the software supply chain. We want to have attestations. So things that I would like to hear from everyone, if you want to grab me during lunch or something, is like what kind of data would you like to see in attestations? Obviously, I think there's a lot of value in having this data present next to the commit. Yeah, so we want to see how we can grow this. I am definitely interested in the intodo, salsa spec for the two-parter review, stuff like that. But yeah, I think it would be really interesting to see how we can apply this for other things. Yeah, so thank you, that's all I have. Really short talk. If you're interested in Git Sign, here's the link for the GitHub repo. And if you want to come and chat after, more than happy to. So thank you.