 So, when I first started in security and open source, when I go on security Twitter or Kubernetes open source, there's often this mention of geese and honking. And for a long time, I didn't understand what it means, and there was never a good time to ask. Thankfully, there are two great talks out there that I linked at the end that explain this greatly, but the lore is that the Goose is based after this game called the Untitled Goose Game. And in the games, this Goose go around and chain everyday object to wreak havoc on this village. And that idea of using everyday object to exploit and explore really resonated with the security community. And over time, the Goose has became this silly, goofy thing that the community used to come together to learn and talk about complex topics like cloud native, like security supply chain. So what is security supply chain? So that are security issues that are produced by third party components and technologies. So anything that has to do with your dependencies or your build configuration. So because our development cycle is faster today than it's ever been, we've seen a sharp rise in supply chain attacks over the past three years. And in May 2021, the Biden administration released an executive order 14-0-28 that outlines that any supplier that sells to the government must adhere by certain guidelines, and that means having S-bomb, that means having certain access station. And this creates a ripple effect, right? Because suppliers to the government will now ask their suppliers to add a station. On a wider scale, it's good for us as an industry to have a conversation about this. And so you're probably not new to like lock for a day, solo win attacks, stuff like that. Before we go into it, though, a little bit about me, I still go to school, fortunately or unfortunately depends on who you're talking to. And as part of my degree, I'm required to do six internships. And what that makes me is a professional intern. I need to onboard and create value really quickly. Over the past two years, I've worked on the Kubernetes release team. I will be leading 1.28 release, which is incredibly exciting. I also work in six security self-assessment. But all of this doesn't make me an expert, not at all. This talk is a result of two things. Number one, me being stuck in Palo Alto with two friends and zero ability to drive. Number two, this talk is the result of a great and welcoming community of folks who were so kind to me when I asked question. And my goal for this talk is I will tell you what I've learned so far along the way. So our agenda today is like this. We've covered the intro, my goal for you to leave this room and establish a foundation and familiarity to software supply chain security. And it's a hard subject. It's scary. Gave me goosebumps. So because you're attending a talk by a Gen Z, I was born after 9 11, if that puts things into perspective. I'm going to ask you to do something kind of scary. We're going to manifest together. We're going to do this once. We're going to do it. It's great. I have so much faith in the people in this room. I excel at new hard things. Let's hear it. So good. OK. Right. Instead framework, we're going to talk about salsa today because as an industry, we need language, common language to talk about best practices and standard. But before we can do that, we need to learn a few keywords. So if we were friends, which we are now, by the way, and I baked you a cake, you probably eat it. But if someone walks up to you on the street and be like, here, please eat this cake, I think you pass on it. And that is because you know me and you know that I baked the cake. And access station is almost the same way. It's a signed claim of things. So this can be claims on your network configuration and claims on your dependency claims on your building infrastructure. In the context of salsa, which we're going to talk about in a second, an access station takes a more specific step and he's an envelope in his predicate. But to simplify, I just think of it as signed claims. And now you have provenance. So literally, provenance means origin. What went into making your materials into artifacts that you release. And then lastly, we have software builds of material. So basically, this is about your dependency, but more specifically, like, what does your software looks like? So my biggest misunderstanding when I first approached the topic was I thought these exist in isolation. And that's not true because you can have an attested S bomb or your access station can refer to your S bomb or a provenance is a form of S bomb salsa. So salsa is a security framework. And when I say framework, I want you to think of like strategic framework and not no JS is a JavaScript framework framework. Essentially, it's a checklist of things that you can do in order to protect your software and your built infrastructure. And how it works is you have four levels. So if you know nothing about salsa, you start at zero. Number one is actually not that hard to obtain. You need documentation of your build process. You need that your build process is scripted. You need an unsigned provenance. And similarly, as we go through the levels, you have to do more and more things that secure your project. So what salsa does is it maps up the build process from developer to all the way to consumer and the weak points along the way. And it offer you solution things you can do to mitigate these attacks. So we'll look at two today, but there's more on the salsa website you can look at. So the first one is the Linux hypocrite commits. So what happened in this scenario was that a university research team submitted malicious code to the Linux kernel. And so one way that salsa offered help this is that on salsa level four, you need to review her in order to get code to March. Another one that we've heard lots about is solar wind. And now we know that solar wind happened because of a compromise in the build process. What salsa recommends along the way is to have infrastructure as code have an ephemeral build environment. And so these are things that you ask an engineer or in your organization can start talking about and be able to do something. And what I will say, though, is the salsa is not like talk to compliance, there's not an authority that like walks up to you and like make sure you do all these things. It's very much like a self assessment thing. If I use your software and I see that you are salsa level three, that gives me an understanding of where you're at in your security journey. Cool, landscape and tools. So we're going to talk about all the exciting stuff, six door in total tough. But before we do that, I do feel like we can't talk about securing the supply chain without understanding encryption, which is really, really big topic. And assuming an understanding of encryption are leaving folks out of the conversation. So I'm going to do my best to teach you quick and dirty road into asymmetric encryption. I haven't even taken the course yet. Hopefully this will work. So if you've ever go to a website and see that little pat lock there, that means that your connection is secure. It has TLS, which means that the very first hand shake was asymmetric encryption. They exchange a key and then that keys is due for symmetric encryption. This is a little different than what we're going to talk about, which is a digital signature for the most parts. Digital signature has to do with asymmetric encryption. OK, so imagine you are getting a binary from someone. You are the verifier, they are the signer. You want to make sure that the thing you got didn't get tampered with. And so what the signer will do is they will take the package, encrypt it with their private key and create a signature. And the signature comes with package. And so when you go and get this package from the registry, you are also able to obtain a public key from the certificate. And you use this public key to decrypt and get the binary. So and we're just going to pretend that hashing doesn't exist. And so the key here is you can encrypt with private key, decrypt with public key. You it also comes with a certificate. This is that's where you get the key from certificate is about identity. Keys and signature is about authenticity. That's all you need to know for the most part. Cool. Yeah. So if you use the public key, decrypt it and you got the same thing as package, you get great. So those are the basics into six door. So six door is comprised of three main components. The first one is Cosine, which helps you sign and verify software artifacts. Then you've got Fulcio, which is which provides ephemeral certificates, and then you got Wrecker, which is a transparency locks. For the most part, we'll talk about the public instance of Wrecker. Cosine. So we just talked about public and private keys, right? So there are really three commands that you need to know about Cosine to understand Cosine. The first is generate key pair, right? The public and private key we just talk about. Cosine can help you verify those. And by the way, Cosine is short for container signing. It's there. They're more optimized for signing containers. But you can also use it to sign other things. So you generate key pair and then you can sign with your private key. And then if you're getting a package from someone else, you can verify with your public key. And there's more nuance to this, right? If you are running a production system, maybe you want to point that to your KMS system to up your favorite cloud provider, but on a wider scale, what Cosine really offer and where the magic is, is a femoral key. So you don't have to create the key or manage your own key when you want to sign. Every time you sign, it creates a key that lasts for about 10 minutes. Fulcio. So Fulcio is a certificate authority. What does this mean? So when you buy luxury goods, it usually come with a certificate that said this thing is authentic, or the same is also true for birth certificate, right? Can't just come from anyone. It has to mean something. But Fulcio is specifically good at creating short lived certificate that is optimized for things like Cosine. And it's based on email address. So your identity is based on email address. And the anatomy of a certificate request is actually pretty simple. You have three things. The first one is your OIDC ID token. It sounds scary. Actually, it is just like you sign in with Gmail. If you if you went through Gmail, Gmail will will give Fulcio a token. And then your public key and a challenge. A challenge sounds a little dramatic. I thought it was like a dual in cyberspace or something. Not really. So because public keys are public, you need a way to tell Fulcio that you actually own them, right? And the way you do that is like imagine Fulcio give you like say a string. You encrypt it with your private key. If Fulcio can decrypt it with a public key, you gave it and get the same response. Then now you own the public key. Wrecker is a time for proof log of metadata from the software supply chain. When I first read this, it didn't mean a whole lot. Basically, when you sign, when when you own a package and you sign it, that creates a lock in Wrecker on the public instance that people can go in and check and look at the certificate and see if the certificate was valid when you signed it. And if you understand the basics of blockchain is kind of like that. This is a time for proof log. It's not actually based on the blockchain, though. There's a great block I will link at the end for when the folks at Sixth Door discuss the implication of why they didn't choose blockchain for now. Cool. So we like have these three tools. Let's look at them in a more applicable sense. So Kubernetes 1.27 just came out and say, I want to verify that this package I got from the registry is valid. I know the certificate identity. I know the issuer. I specify these things. And you can see the hash of the body here. And one of the parameter I get back is lock index. What does this mean? So I'm going to get this number right here, go to Wrecker, search it up. And what it will tell me is a signature. It will also tell me the certificate. And whether or not the certificate was valid when this package was signed. We're going to look a little bit under the hood of what Cosign is actually doing here by using a tool named Crane. And don't worry too much about Crane. It's just a tool that we're going to use to interact with remote images. And so I'm going to get the digest of this package right here. And I'm also going to get the signature because I know that Kubernetes released the package with a signature. And what that gives me is the hash, which is like the body of the package. It also gives me the certificate and the signature. And this is what Cosign is doing behind the scene, right? It has a signature. It's going to get the public key from the certificate, do its decrypting magic and compare that fact to the manifest. Cosign also saves a bunch of metadata in the process. A little side note of your if you're looking at the documentation, you're trying to do a home documentation is a little bit out of date as of Cosign 2.0. Hopefully we'll get to fixing it soon. Because Cosign or 6.0 right now is really optimized for container registry. Other folks in other parts of open source are also interested in adopting the same thing. Now that security supply chain is really top of mind for the industry. And so 6.0 Python has been made and there is a proposal to use 6.0 in the NPM registry. Cool. Next up, we have in Toto. And the way I think of in Toto is two part. The first one is the layout, which is policy, what you expect to happen in what order by whom. And the second part is the record, the link metadata follows that is created as you create your software, right? So I think of it as like a record player, what steps were performed by whom and in what order. So say when you're making your package, you can type in in total record start, do all things you need to do, interact with it, and then do in total record stop. And behind the scene in total work will record your identity and like the steps that you took along the way. And what that helps you with is that you can verify your attestation by comparing the layout to the link metadata file. So comparing what you expect to happen by whom and what order to what actually happened so that your attestation is actually true. And then tough was a tough one for me to comprehend. But really, it's about the last mile of package distribution. So the way the folks behind the tough think about this is that it's not a matter of if, but when your package or your key or your repo will be compromised. And so when that happened, what can you do to minimize the impact of that as much as possible? And so the threat model that they came up with is rule. So you have the person at the top or a few people at the top who are roots and that gives them permission to specify other roles. You have target, which gives you permission to indicate package validity snapshot, package version and timestamp is packaged last updated. So you can imagine it's like almost like a triangle. If the timestamp key got get compromised, you still can't do a whole lot with that. And tough really focus on key revocation and like minimize impact. So if you think back to in total and total and tough works hand in hand and that in total follows you throughout your development process and the top help you with the very last part, but also the roles that you specify in tough is the one that you could also use for in total to specify like, oh, Alice is only Alice should only be able to develop and Bob should only be able to release the package, things like that. Cool, we're at the very last part of the discussion here. And it's about misconception and discussion. And I think misconception is a little bit of a misnomer. What is more about is things to think about as we dive deeper into the conversation and now that we have context about the conversation. So it's just about the code, right? Right? No. As we see in the case with SolarWinds, it's about all the stuff that went in before the consumer get the package and to make sure that it's not tampered with the second misconception is that you might think you're probably not a good target and like, sure, if you're if you're not a crypto company, your risk profile might be a little lower or different, but that doesn't mean that you can't be used as a stepping stone in order to get to bigger targets. And then lastly, we can never fully remove supply chain risk in our software. It's really an effort of an entire ecosystem, which bring me to this XKCD picture that we've probably all seen before. It's a sure responsibility, right? It's a conversation that we need to have in open source about the fact that open source is often underfunded and maintained by folks who are overworked. And so how do we offer governance and support for them in order to help them get the resources that they need for them to invest in things like Salsa and supply chain security? So this is an incredibly exciting place to be. And a lot of standards are being made as we talk and very much in this conference. So I encourage you to to go talk to the folks who are maintaining these projects. And a lot of the standards are being open for discussion right now like Salsa. Things I didn't get a chance to touch on that are also important, things like vulnerability scanning, securing your build environment, patching your containers. So there are projects out there. So like Guac helps you make the most of your S-bomb. Right now, the way most folks are using S-bomb is that they like generate it or they like take it and they store it for compliance and audit process. So how do we make the most of what we have? And Guac help you graph it to like visualize it. Get up just announce a new feature where you can click a button and produce an S-bomb on your project, which is pretty cool. And then Docker now also have Docker S-bomb, which is an experimentation. Now that you have this foundation, you are very, very well equipped to attend all these awesome talks. Many of whom are by folks who have answered question and helped me make this presentation. So I highly encourage you attend them. And that is it, folks. Please hit me up on Twitter if you have question. I graduate in a year and I probably will need a job if you want to hit me up for that as well because it's not good. This is my first ever in person talk, which is really exciting to see a crowd. And so I really encourage you to give me feedbacks. And that is it. We're open for a question. I don't see any. So the question is in Toto is a recording for the steps that has happened. And so does that mean that it can create provenance? And so provenance in the context of Salsa looks like a very specific shape in like a schema that they've outlined. So like I don't think that the stuff that is generated by Toto, which is like link metadata files are provenance, but I'm sure you can get there. Oh, OK. Correction. That was from Justin, the maintainer of in Toto went up. And the answer is yes. Do you have another question? Oh, yeah. Go for it. Can I speak about the Kubernetes point of view? I don't know if I'm qualified to answer that question of the if the S bomb is included from like Kubernetes binaries releases. We do have manifests and S bombs and signatures and such. But I don't know if you're asking from the perspective of like Kubernetes user. OK. Yeah. So from if you are an admin of a cluster, how do you check your S bomb? And from my understanding so far is that there's not a standard in the industry because S bomb usually the most folks to store it for compliance purposes right now. Yeah. But the folks at Guac are also working on like making a dependency graph and stuff like that. Last call and we're good. Thank you for coming.