 Hi, everyone. My name is John Osborne. I'm a supply chain architect at ChainGuard. Tonight, I'm going to be talking a little bit about Six Store, which is a free signing service under the Linux Foundation, but specifically, I'm going to be talking about it in the context of Salsa, which is a supply chain framework that's been out for a little while. The reason why I'm going to put that little bit of a spin on it, if you've heard Six Store talks before, this isn't just about the tech, but how it fits into the framework, is because all these emerging, there's three emerging frameworks right now. One is Salsa, another one is the CIS benchmarks for supply chain that came out, another one from NIST called NIST SSDF, and in all these different supply chain frameworks, you end up signing a lot of things, and so it ends up needing to be automated. You're constantly not only just signing your artifacts, but you're making these things called attestations, which could be include things like an Sbomb, or other just statements that you want to make about your build systems, about your dependencies, about your source code, and so on. And so Six Store ends up playing a big role because it's kind of constantly signing things, artifacts and documentation attestations about the process as it goes along. And so there's a big role there for Six Store. I didn't spend a lot of time putting together content on the supply chain framework in general, but I did want to start off this talk with talking a little bit about how a chain guard used this problem space specifically. So I'll share my screen right here. There we go. Okay, so I'll be talking a little bit about the role of Six Store inside of the supply chain journey. And let's see. Now first, I wanted to talk about what is software supply chain, and that's really important because I think one thing specifically that gets lost when we talk about supply chain is people immediately tend to look at dependencies, and that is a big role inside of software supply chain, all your dependencies that you bring in, and then their dependencies and all the layers below that, your dependency trees or graphs, whatever it may look like. There's been lots of studies out there on different languages and how many levels they go typically in some languages or better than others. But software supply chain isn't just about your dependencies, and it kind of breaks down. I like to think of it as two parts. One is your dependencies, and then the other pieces is all the systems that would interact with an artifact from development out to production. So it could include things like your IDE, for instance, in the case of the SolarWinds, or it could include things like locking down your Git repos and not just other testing and attestations, and those things tend to run as privileged users and those types of things. So limiting access to those, removing different ways that your system could be compromised as it goes all the way from development out to production. And so we at ChainGuard really view the software supply chain problem as a lack of transparency. And the reason why is because if you look at historically how we've done security, it's really based around putting better fences around our systems, implementing better security practices for what is running in production, but it hasn't necessarily been around all those type of things that now we're trying to address in the supply chain framework. And the reason for that is we really just didn't have the information. So historically, there's been no way to tell whether who wrote in Apache Commons Library or even if something came from a certain person, there's really no proof, there's definitely no cryptographic evidence that something came from a person that it says it is or what methods that they used to build their systems. I mean, for me personally, I use Fedora on my desktop and if anything that's almost user-facing, video, audio, those types of things, those projects typically are maintained by one person that I've never met or heard of, right? So there's a lot that goes into supply chain. Now, this query here is one that I run in BigQuery. If you go to depths.dev, which is a project essentially from Google where they just ingested all this data about dependencies out there. They went to GitHub, they went to all the main repos that are out there and they just ingested all this data and they really tried to track what projects are dependent on each other and then what is the state of those projects? Are they maintained? When is the last commit? Their dependency is out there and there's a really good blog out there on depths.dev but they also made the data set publicly available on BigQuery, which is pretty cool. So I went and I ran this query and what it does is these were projects at the time that I ran it that had critical CDEs but then also had major, they were major dependents for other projects. So this could have been JUnit, all of these you've heard of, a lot of no JS projects out there. These could be really low in the stack, which means for instance, the JUnit, right? There's 63 projects that are depending on that but there's probably each one of those 63 projects probably has other projects above it, right? Usually JUnit's pretty low in the stack. So the sprawl there that's now inheriting this CVE, at least the time that I ran this is very, very large. So that's a problem we don't really necessarily know the CVEs of all our dependencies and definitely not our transit dependencies. The second aspect to it is all the systems that's gonna interact with your artifact as it goes out there. And one of the things I look at is historically, if you look at, let's say historically, but in the last few years, DevSecOps, right? A lot of, let's take the people and process part of it out there because that's a whole separate conversation but if DevSecOps, a lot of it in terms of technology has been about shifting left, right? So taking all the out of band stuff that we used to do at the end of the software lifecycle and shifting it left, right? So that's important, of course we should do that. That gets us feedback and gets our systems up the door faster. But what about all those systems that were already left, right? So those could be your Git management repose or your security scans, all those things, right? Those have to be locked down as well. And I think part of it was we took those for granted, right? And so a couple of questions I put here is there's really no way for most systems, most pipelines to just do simple verifications like can the source code actually be verified in the sense that can you actually tie back what's running into production to Git commits, right? Do you have actually cryptographic evidence that can do that? Can the build system, can you trace it back to the build system once it's running in production? Do you actually know where it came from? Is there any proof that it came from whatever deployed it whether it be Tecton or Jenkins or GitHub Actions, whatever it may be, right? So the little magnifying glass that I drew there that's the salsa logo. So when you really look at it from the salsa perspective, there are things that are lacking there. And that's really what salsa is intended to kind of fill in some of those gaps. And there was a big announcement this week from GitHub around Node.js and Six Store and one of the quotes was from GitHub, which I liked was, you know, there's really no guarantee that a package that's built actually came from that source code, right? So there's no way that to actually tie source code back to the compiled binaries in most cases, right? So that's a problem. And there was next executive order last year. And I thought that it was interesting because it was the first executive order I've ever seen that actually called out specific technologies. They actually called out things like S-bombs, which I'll talk about if you don't know what that is, that's fine, I'll address that shortly. But I grabbed this quote because I liked it and so I highlighted it. And what it said was basically the trust we placed in our infrastructure is basically proportional to how transparent it is, right? And when we look at software supply chain, historically it hasn't been very transparent, right? So we wanna increase transparency. So for us, we're looking at the software supply chain and we want to create transparency. So the way we're gonna do that is essentially building a massive data layer around software supply chain artifacts or software supply chain metadata. And to me, the three main components to that, there are others, but the three main components of that are is one digital signing. So in this context, I'll talk about six store, but it could potentially be other projects as well. So those are digital signatures, your signing artifacts, your signing all sorts of other metadata as your project goes from development to production. The second piece is our S-bombs. So S-bombs is now mandated in a lot of cases. So it's mandated for instance, if anyone wants to sell software to the government, they actually legally have to provide an S-bomb now. And what is inside an S-bomb is essentially a list of software dependencies. It could be external systems, anything that it depends on, also licensing. There's more to it than that, but the main components are your dependencies and your licensing, those are important. And then the third piece, which I think a lot of people are probably new to is called attestations. And attestations, it's not that complicated. They're essentially JSON documents and they're JSON documents that say specific things. So they might say something like, I did a two peer review or I did a static code analysis or I did follow this method of Salsa or I did a security scan. And we're actually created, I'll actually create an attestation for you during this webinar and we can sign it. And so then we'll have cryptographic evidence of that I created it. It'll go into the six store log. You'll be able to take a look at that as well. So six store. So there have been signing methods before six store. Really what it's trying to address is a couple key pieces is one, I think having a great UX, right? Anyone that's worked in software knows for a long time if something's really hard, it's really gonna be have low adoption, right? I came from Red Hat and it was pretty common. It was almost a joke that people would disable SE Linux, right? SE Linux is an incredibly powerful technology. It had stopped at least all the main container breakouts if it was configured correctly that I've been tracking. So, but it's not necessarily easy to use unless it's automated for you, right? And so we know at six store and there's a long record of other projects that have suffered from kind of similar fates, right? So we know that one, it has to be easy to use. And so the idea of six store is you don't have to necessarily know or manage keys. It's all done for you. But then also it has something called keyless mode. So keyless mode is you get a short term certificate and it lives in memory. So in most cases it doesn't touch disk. So no one has to manage it. No one has to worry about their public key or their private key. And also since it has this mode, it can plug into automation systems. So if you're a person, it can just tie into your OIDC login, whether it be Google or GitHub or any number of OIDC logins. Or if you're an actual machine that can tie into your workload like identity, there are integrations with Spiffy or anything else really can tie into key management systems. For instance, AWS that can tie into their KMS system, same Google Azure or anything, I think with a PKCS11 interface it can tie into. So there's a couple of key pieces to six store. One is Cosign. That's the piece that's actually making the signatures and that's what's actually signing things. Falsio is a certificate authority. All Falsio really does is essentially exchanges your OIDC login for a certificate. So you log in with Google as an example and you go to sign something and then it's going to create you a short term certificate that lives in memory that it'll just be in standard X509 certificate except the email that's in there will be your Gmail login that you logged in with and it'll be just for key signing and it lasts about, I think the default is 20 minutes. So it's very short term. And then the third piece is Recore. Recore is essentially the transparency log on the backend that you can use for audits. You can use to verify that things were signed by individuals. Of course, you need some method to do that since the certificate's going to be gone after 20 minutes, right? And so the whole point of this is that you can cryptographically create all these pieces. You can verify them in a very easy way. It's all community operated. So there was a very cool ceremony last year. It's on YouTube. You can find it. They did essentially a tough ceremony. So there's five people walking around with UBK is that created the root CA for a six store and they're all working for other corporations or universities. And there's also a free public instance out there. So in a free public instance, we've hit almost over three million entries so far in the community, in the public Recore log. So really why we care about all this is simply around key automation. So this was just something I did on my laptop. You can sign anything, not just container images, not just attestations and S-bombs. You can actually sign that as anything. So we've talked to customers that wanna sign assembly code. We've talked to customers that wanna sign, sign all these binaries or legacy systems. And that makes sense, right? Cause if you think about a legacy system, say it's at, just say it's an edge type system, right? You built it, you're deploying it in a lot of cases, especially in the enterprise, those things aren't necessarily getting updated very often, right? So if it's been running for a couple of years, you actually have no method of tying back that it's actually the same binary that you shipped two years ago, right? And so signatures help with that because you'll know that it actually is the same binary and you have evidence that it is. But now that can be automated. So in this case, I just tied into my six store. So this is what I would see. When I go to sign something, I can log in with any OIDC piece. Those three options are just the options on the free public instance. And then you just go to authorize it. And it's very similar to this logging into a third party app. And I'll actually sign stuff here in a minute. The usage is very easy. Simply cosign sign, cosign a test if you're signing an attestation and then verify, cosign verify. So all very straightforward there. If you're signing an S-bomb, one nuance there is S-bombs are actually considered an attestation now. So if you go to sign something, an S-bomb, you'll actually just be signing an attestation that the S-bomb is what you say it is. We also have a project called GitSign, which was really what the GitHub announcement was. This week and I'll do a demo and talk a little bit about that more also. Okay, so quick demo. Got two demos for you here. Hopefully you can see my terminal. Zoomed in pretty well here. Okay, so actually before I start, I wanted to show you something real quick before I start. So this is the Google Container Registry. And I just wanna show you this because it's important. And it has to do with signing because it's the way that these things actually, these artifacts get stored. So this is a pretty basic busy box image that I copied over about a half hour ago into this registry. So this is just the plain busy box latest. I copied it over and I just wanna point out the hash here and since six, nine, three, because that's important and you'll see why in a second. So if I come back here, what I'm gonna do is I'm actually gonna to scan this. So I will take this image. It's the busy box image. I'm actually gonna scan it and we'll create some signatures based around the results. So I'm gonna use Trivi, which was a pretty cool free scanning tool. Let's see there. Should be pretty quick. This is down, we can look at the scanning results. So it's scanned, clean scan because this was the busy box latest. So that's very nice. We wanna have clean scans of course. So what I can do now is I can actually create an attestation around that and I'll just set some environment variables which aren't necessary per se, but it'll just help populate the attestation component to it and I'll make a very short attestation. Sometimes these can get long, but in this case, I'll actually embed the scanning results inside of, if you see here, the Trivi scan, I'll actually embed the attestation, or this, the scanning results inside attestation. And I'm gonna do that because that way I'll be able to prove later that this had a clean scan when it went out the door. All right. And so what I'll do, I'll sign the image first. So you can see that. Go sign, sign, log in with my Google. So I don't go back to the signature here and it's gonna say, it's just telling me right now that this is in a private container registry. So it just wants to make sure that I wanna go ahead because it is private, I'm gonna say yes. And it pushed the signature to busybox, or to the Google Container Registry. So, and that's why I wanted to show you what this looks like. So if I come back here, remember this ended in six, nine, three. So if I come back to busybox, I can actually see I've got a attestation that I just pushed here, or I've got a signature that I just pushed here. So click on this. And this had, this is the same hash ends in six, nine, three, but dot sick. And so that's just kind of one interesting nuance of cosine in general is when you sign something, it can actually store these things inside the container registry. It stores them in what's called an OCI artifact. And it can do that for signatures. So anything you create a signature, it'll be dot sick. If you create an attestation, it'll be dot att. And if you can create, you can create S-bombs too, and they'll be dot S-bom. And if I look in here, I can actually go see the manifest. So I can actually see some of these attestations inside the manifest here. So I can see that there was a certificate. I can see the chain. That's the six-store public chain there inside that manifest file. And so that's all very cool. Now I can go back and create that attestation. So let me do that. Let's look at the attestation real quick just so you can see it. See the attestation that I've created. It's got some information in it. I populated that it's using Trivi in that version. And then it actually populated the Trivi results embedded them inside the scan. Now this was a clean scan. So this was very, very short and sweet. But now we can go ahead and sign that. So remember I said it's all very easy. So it's cosine attest is all that you're right here. So then I'm gonna give it a type of bone for vulnerability which is part of the in-todo framework which is a structured way to do these attestations. And then I'll just make that attestation based around these results. And that'll go inside that registry. So I'll click here. All right, similar. Our flow is the same. And I'll come back, probably gonna ask me again if I wanna go in the private repo to do. And it should be pushed there. So now it's inside the transparency log also. So if I come in here, back to busybox. I can see there should be a new attestation in here. Again, it's 693.att. So this was the same, this was the same one. And if I look at this manifest file, we can see it's got the cosine signature and the cosine certificate bundle, all those things. Again, this is an OCI artifact that it put it inside and that way it can store it in the registry. No cosine can sign anything else also. But if it signs something else other than a container registry, then you'll need our container image. Then you just need to keep track of the signatures. You could put them in an S3 bucket. You could use the same naming convention with hash.sig or the hash.att. That's all something that you have the option to do. We can also verify these things from the command line. So I'll bring up the command line here. And if I type cosine verify, you can take a look and it'll tell us if we've... That could take you. And this is important. So it'll verify that it's signed but also by who it's been signed by. So in this case, I signed it. I used my work email and other stuff as just certificate type of information, nothing important. But that was cool. And then I can verify the attestation also. So I can make sure the attestation was signed like we said it was. And yes, so this was kind of the information similar to what you saw, but it's using in Toto. So this is basically the structured way that we're creating these attestations. And it's got the signature. And at the end, it's got the signature field down here. So there's also a recore log. So I can use the recore log and let me scroll up. Do we have the ID that was created? Let's scroll up here. You scroll all the way up to... Sorry, I forgot to grab this ID. So this was the entry in the log. So this was the 3,166,785th entry in the log. So we can check that from the command line if you wanted to. And also there's a web interface also. So I'll show you what that looks like. This was the entry in the log. 3 millionth, same attestation information. And it's all encoded. So you're not gonna see any of the specifics for that. It's all encoded. But if we go out to the web also we can put that same ID inside of there's a public interface here. So if I put that and take a look. So it's proves that it was signed by Sigstore. It's my email. Again, this is the X5 of nine certificate that it created. So all it did was since I logged in with Google it took my Google email address and put it inside of ChainGuard. Of course I can see that there. If I log down, this is all informations encoded. But that's the attestation. And if I want to do some verification you can actually verify that things were it's the back end is a Merkle tree. So if you're into crypto cryptography you can go back and you can validate this using the inclusion proof. You can actually validate things offline as well using this called signed entry stamp which is something that's very similar to what you would get in a certificate transparency or framework or RFC essentially it's that same format and structure. Okay. So that's a demo of cosine. You understand how it works now. So really it's important to level set on what that means. So signatures by themselves actually don't do too much. They essentially what are the guarantees? So the guarantee that one it's exactly the same as when you signed it and the guarantee that you signed it or the workload signed it, right? So the signatures by itself they can if you just sign us up for artifact you can prove that it was exactly that way and that you signed it the day you signed it, right? So that's good for making sure that things don't necessarily have changed but we want to do a lot more than that, right? So we want to actually start signing all these other artifacts. We want to start creating attestations around how it was built. You'll start hearing this term called Providence. That's really based around the build process. So all the build systems that were interactive with it as it went out the door. Most notably typically what people are signing the kind of three main things now is they're signing their Git commits, they're signing S-bombs, they're signing attestations in their artifacts. So S-bomb, there's two emerging standards out there right now, I shouldn't say emerging but they've actually been around for 10 years but they're emerging in terms of popularity I guess you could say. So one is SPDX, the other one is Cyclone. At Chingard we're not too opinionated on it. I think both formats will probably be here. One interesting nuance here at Wrinkle is there's actually an effort to put some companion documents out there with that. So one is called VEX or the vulnerability exploitability exchange. What VEX is, VEX is something that would come from a vendor. So it's a standardized way to make attestations essentially around vulnerabilities. So a lot of companies have been doing this already. So for instance, I came from Red Hat. They used an open thing called Oval and that was a standard to say whether something was vulnerable or not. VEX is very similar. It's just a companion piece to the S-bomb and it's an open way, right? So if you look at a lot of SCA tooling and things they've been creating these big databases that they've had for forever, S-bombs is an open way to do that because we're all using the same software in the back end. It doesn't matter if you're in telco or startup or if you're a bank, everyone's kind of using the same components, right? So let's have our standardized way to do that. And VEX is a standardized way for the vendors to make attestations about, you know, there's say that, for instance, say there's a CVE, they can say if actually what they're shipping is affected by that. And it might not, right? For a number of reasons. It might just be mitigated in the context of the environment or a number of other factors, right? Attestations, this is new for a lot of people. So I think sometimes it can be a little confusing but all it really is is a JSON document. And the reason why it's important is you can say things in a structured or unstructured way about your software, right? So you could say things like the build system that it created and I'm gonna show you some specific real life attestations in a second in addition to the trivia one. But you can also create unstructured ones if you want to or create your own structure. So you might have, for instance, your organization might do things on top of certain frameworks or have their own checks. They might have their own review boards. You can make attestations if those things were followed and they can be signed. Commonly, I would say that the number one thing that we see for attestations right now is how it was built. And you'll hear that term Providence a lot. Providence just means how it was built. So for instance, you'll find these slides, I'll put them in my GitHub repo. But you might see something like there might be an attestation that says, okay, this was actually built from a very specific git commit, because that has to do with the Providence and how it was created. You might have other ones around how it was tested. And then you have a lot around security scans, which is what I just showed you. Another interesting thing there is they're actually standardizing the security stand format now also. So if you noticed when I scanned with Trevi, it actually outputted to something called Seraph, which is, I think it's an Oasis standard for how that looks like too. And this is all really important because everything is no longer going to be a one off. And now we have standardized way to say what we're shipping with S-bombs, if they're affected by vulnerabilities with VEX, we have standardized way to sign things, we have standardized way to make common attestations, and we have standardized way to do these security scans and other things. So now that everything is standardized, we're gonna be using all the same software and we don't have to all do one off efforts to validate and vet that software. And six store is really critical to all this because it's constantly just signing and verifying all these things, right? So all the attestations, think of anything that as you get more advanced, a lot of customers now, they might just be signing, they might just be signing their documents, right? A way to start, or they might just be signing their S-bombs, right? Or just signing their container images, right? But as they get further along in the salsa path, they're constantly signing things, they're constantly verifying them as they go out the door. So I wanted to, that was all great, but I wanted to walk through some specifics on what that would look like. So just a few slides specific to salsa. So salsa covers a lot of areas around your source code and your builds and your dependencies and all those things. But for this case, I'm just gonna talk, I'm gonna walk you through level one through four so you can see what it might look like, right? So salsa level one is a lot of basics around documentation. A salsa level one build would say that you have a script to do it, right? We're not doing artesian handcrafted builds. You at least have a script. It could run in your laptop. Hopefully there's some providence available, some information around how that was built, right? And there's a script to do that. This is a real life example that's in the recore log on how to do that. And you can click back on that as well, but this was specific around Maven. So this person was creating using a Docker file and had some Maven packages. And this one came from Red Hat. And Red Hat's been an early adopter and contributor to Six Store as well. And they've done a great job here. So in this case, they have created attestations using the Intodo framework in the salsa providence format around that. So as you get a little more mature past your scripting your builds, you might wanna say that you actually have a build service, right? So in this case, and they're using, this was Equinix and they're using making attestations around their specific build. I think they're using GitHub actions and they're making attestations around that. So that's important. So not only you're adding on, right? So you're not saying not only was it scripted, but I actually had a build service to do that, right? So it wasn't just a one-off running on someone's laptop. I'm actually managing that from a central place. I can start doing lockdowns around that. And now I have to do providence on that too, right? So I have to sign it to say that it was created with that build service and I can verify that using cosine to verify the attestation. You can see how you get more mature as you go up to levels. And one of the reasons why I like Salsa specifically is it gives people an incremental path instead of just an entire list. It's like, hey, here's the crawl walk run path to secure your software supply chain. Level three, so you're building on that again. Not only do you have a central build service, but now you're building as code, right? So it's more locked down. It's becoming a little bit more closer to hermetically sealed and you have non-false viable provenance. So you know exactly, you have cryptographic evidences now mandated at level three for your build system and for your build as code, right? So you're not, there's no way really to interact with the system and there's limited paths to interrupt that process, right? So you don't have secret keys also in that system. You're using an external KMS to automatically pull that. So this very fits very well into GitOps, but GitOps isn't mandated here. It just mandates that you have a build system and that you can, you have cryptographic evidence that it came from that build system. This was another real life example using the Salsa framework. They were using KO and GitHub Actions around that and they've created attestations that they did come from that. And if they had build as code, if you scroll, if you click on the example, you can scroll down and actually see all the materials that were used also for level three. Level four, so this is the highest level. This is really where you start to get more in depth around some of the harder parts of software supply chain. So you're doing things like reproducible builds, which is a very big challenge. Not all build tools are reproducible. So if I go to build something with Docker, for instance, and I could build it multiple times, actually have different binaries. So it's hard to reproduce that. And this was really critical. SolarWinds gets brought up in terms of the hack and stuff that happened, but they actually, they've been addressing it really aggressively. So if you looked at their talk, I think at KubeCon last year, it was really cool. And one of the things that they did was they actually created reproducible builds. So they actually have two pipelines now that should produce the same binary. And so even if breaking into an IDE isn't really complex as we saw in that attack, but now someone broke into their IDE for whatever reason again, they would actually be able to, even if they started signing stuff that had been compromised at level four, you have reproducible builds and parallel pipelines. So you know, for instance, even if somebody did get in and was able to circumvent almost everything, well, you know that the binary didn't match. So you can go investigate that. And that's really, you know, salsa level four is really designed to be kind of foolproof there. So you also have prominence information around your transit dependencies and all those things. One of the other things about salsa level four is that it includes code reviews. So this one was one that I made up. There isn't a standard to do code reviews. It's not approved yet, but this has been submitted by someone at Schengard to upstream as a standardized way to create code reviews. And it just looks like this. So again, it's just a JSON or YAML document. That's all it is. And you can sign things. So you did a code review. You want a two peer review. That's part of salsa level four. So in this case, stand signs and Kim signs. And then you both sign that at a station. And because you can sign things multiple times, of course. So then you can go later, go back to verify that it was signed multiple times. Now that's specific to salsa. Again though, it's a, no matter which framework you're adopting, it is very similar. So I just highlighted some things from the software supply chain security guide from the CIS benchmarks. You're signing and verifying commits. You're signing verifying releases, the S-bomb, the build pipeline, the versioning. It's all signatures, validation, signatures, verify, signatures, verify, signatures, verify. So you can see the pattern. It's not going to be any different if you adopt a separate framework. It's going to be kind of a very similar story. Again, secure software development framework from NIST, very similar, constantly signing things. You want to be able to create an immutable log about what you signed. That's RECOR. It's the immutable log for audibility reasons. You want to be doing signing commits. You want cryptographic evidence and hashes. You want to be able to verify how things were built. Again, sign, verify, sign, verify, sign, verify, sign, verify, and all that needs to be automated. And that's really where six store comes in. I've got two slides left, I think. Git sign is something else we've been working on. And this is really what the GitHub big announcement was about with NPM. The reason why Git sign is so important is because it's really just so easy to use. And I'll show you a demo here and we'll actually stand everything up from scratch in a repo that hasn't been touched yet. But you can do keyless signing. So you can do git commits with signing six store. We're there in a couple of ways. You can set it up where every time you do a git commit, all you have to do is just add a flag to do the signing. Or you can actually set it up so you're just doing signing by default every time. And this is important for a lot of reasons. So if you saw the frameworks, you said there's a lot of information about you actually had to do sign commit commits, this is a great way to do it. But it also can be critical to doing things like two peer reviews. So if you use GitLab or GitHub, there's ways. If you have the enterprise version where you can do those things and then you can easily integrate it into that. And one of the key things from GitHub, if you read their blogs around the announcement that I thought was really interesting was, they were very committed to having, they're very committed to increasing software supply chain security, but they were also very committed to having the developers not for it to be very easy to use for developers, right? And that's really where why six store was so important and what they chose to help do that. So when you do sign something, you'll see this little certificate that'll say it was created with six store.dev. And this was a tweet I saw this week from Derek Shepard where he, someone actually tweeted at him that somebody had faked his email, which is something you can do with GitHub. I can go in and I can change my Git configs to any email and it'll show up that way in the log. So he's saying, oh, I better sign this now. So actually there's cryptographic evidence that it was me that signed it. And really six store is becoming very important behind the Git sign project there. So I'll do a quick demo for you with Git sign and there. And this is a new repository and I've actually put my demo scripts in there also. So if you wanna see what those look like, you're welcome to go do that. Nothing really in here yet. There's no even Git file, no, cause there should be just the basic Git files in here. So there's just the Git folder in there. And this is, I'm gonna run a couple of commands. This is all I have to do just one time, just the first time I set up the project, Git config, I'm gonna set the GPG sign equal to true. The GPG piece is more of a legacy piece, but this will tell me to sign all commits. So I can do that. And again, I only have to do this one time when I set up the repo. The next piece I'll do is I'll actually tell it to use Git sign to sign those commits. So there we go, use Git sign. And then I can just run this last one and I'll say the Git sign expects X5 or 9 certificate. No, okay. So now I can just sign anything I want. Let's see. Let's see, F, text, and add that. And now, if I go to Git commit, there we go. And it's gonna ask me to log in just as it did before. And there it goes, there it goes, there it went. And if I can look at the Git log and I can take a look at that, done. And yes, there's my commit message. It says that use Git sign. You can see the six store pieces here and that'll be in the recore log also if we want to go look at that. And I can also use six store to verify this. So I'm just gonna run a couple of commands here so I can pull out some of the information out of recore just to make it easier. And if I wanted to verify it, I can just use cosine verify. Now that I got the signature pieces out and it'll tell me the recore log entry. So if I actually go back to the website here, I can actually check that out. And this is what we just signed. Again, it came from me, Jay Osborn at Chingard. Zoom in here. I realize I forgot to zoom in the last time I was here. Another key thing here is the key usage. So this can only be used for artifacts. These aren't signatures you can use for a website or anything like that. The usage is just code signing and there shouldn't be too much else out here other than the verification. Again, that's the inclusion proof. If you wanted to verify that came from me, you could go do that and that it's in the recore log. And again, it came from six store. It was only used for code signing and it came from me and that was the piece there. Now I go to push it and you should be able to see it in the repo. Again, if I go to Jay Osborn six store repos. There you go. And there we go. Sign it. You can see the commit to come back here. Now it says unverified because GitHub hasn't added the six store public, the six store certificate into its trust store. I think that is something that's gonna happen, especially now with the announcements. So at some point that'll say verified, but you can see that it was signed and that it was signed by six store. And to the end, a couple other key things. Why we do all this? Eventually, if we wanna make risk management based decisions, this is an upstream project. I'm talking about six store, but this is a chain guard. We work kind of half and half. So we work upstream a lot with a lot of different projects. Quite a number of them actually in standards also, but on the product side, this is the other half of it. So we're basically building products that are going to take all those artifacts and allow you to do risk management based around software supply chains. So policies, continuous verification, eventing alerts, those types of things. Last thing I'll mention, last slide. This is very important. We did work with the Linux foundation in the open SSF around a free six store training course. So that's been launched and you can check out our blog. It's on EDX. You can Google it also. There's an approach to get there. But our team, got a couple of people, John and Lisa and our team is an amazing job on it. I've taken it and I think it's really great. And if you get a chance, go do it, it's free, it's not too long and it's great. Appreciate you sticking with me on this whenever I'm recording at night, but whenever you're watching it, I hope you enjoy it. And again, my name is John Osborn. You can reach out to me on Twitter or email me josbornatchengar.dev and happy to talk. You have any questions? Thank you. Bye everyone.