 So, hello, everyone. My name is Roberto. I'm a senior software engineer in Red Hat and today we're going to talk about chocolate cakes. So, I like very much all of them. And, you know, many people have lots of allergies and tolerances. So, how do you make sure that you won't get sick by eating one of these? Usually go to the ingredient list, right? And the thing is, how do you know that you can trust that ingredient list? Well, usually there's lots of food supply chain regulations in every country. There's guidelines on how to handle food. For example, if you touch something that contains nuts, then you should not touch something else in a restaurant. So, usually we don't get sick from eating food in that state. So, this is actually very similar to what a food supply chain is very similar to what a software supply chain looks like. So, this is like a typical software supply chain, very simply outlined. Everybody consumes artifacts made by these kinds of pipelines. Basically, even if you have one of these smart electric toothbrushes, chances are the software in it is getting built by one of these pipelines. So, yeah, if it gets some malicious code, then you're not brushing your teeth today, sorry. Yeah, and basically every time you use GitHub Actions or some GitLab CI or Jenkins jobs, you're probably using one of these. It can get really, really complex. So, trust me, it can get super complex. And each item that you put into the pipeline makes it more vulnerable. So, yeah, basically each of the triangles represents a kind of thread to a software pipeline or software supply chain. No need to read all of them. Basically, no need to read anything in this presentation. Yeah, and imagine if, for example, in the build, if we could, in one of the builders, put some small script that would detect when the build is triggered and would input some malicious code into the code that you're building. This is actually a real case. It happened to SolarWinds in 2020. And it was very famous case of supply chain, software supply chain attack. So, what Solsec comes to solve is how do I make sure that the code that the developer wrote is what it's actually being run in your computer, what the binary actually contains, and it was not tampered in some way. So, this is, Salsa is a set of incrementally adoptable guidelines. It's of course a guideline. It doesn't make your pipeline or your software supply chain like unbreakable, but it should help with hardening it. So, basically, what it brings is a common language. Words are kind of easy to trick, and companies can usually do it very well. So, it's safer to say, hey, I'm compliant with Salsa level one because the specification is super clear on what it means than whatever kind of company talk you can do. It's also a way to evaluate how much you can trust that the code that the developer put together is what you're running. I've actually seen in the Arc Linux user repository, I've seen people trying to get Salsa certification for some of their packages. Actually, the most important thing is that it actually helps you improve the security of your software supply chain, making it less likely that the software, the artifacts generated by the supply chain, contain malicious code. And there's many security standards that you need to comply in many cases. One of them is NIST Secure Software Development Framework. There are executives ordered in the U.S. being released that make compulsory to comply with this, but they usually only tell you these standards, other standards, usually only tell you what the final stage should look like and not how to get there. So, to start with talking about Salsa, most part of it, it's about provenance. There are three key words here, verifiable, where, when and how. It's actually four words. Basically, provenance, in plain words, it can be whatever you want. But it could be a JSON file that states how some artifact was built. For example, if you have a C program that you're building, you're compiling, which command was used with GCC, which flags were used, which dependencies are we using, where did we download those dependencies from, what the digital signature of those dependencies are, digests, all of these connects. You get a document that tells you exactly how an artifact was built, whether it is a container or a binary or whatever it is. It's very important, the concept of provenance. Basically, it's a document that explains exactly how the artifact was built, and you can verify that this is actually true. So, Salsa is divided into three tracks, one for each kind of thread, source track, build track, and dependency track. Each track has four levels of certification. The current state, Salsa version 1.0, was just released in April 18th this year. So, it's early stage, and it only covers build threads and the build track. And actually, for the build track, we only cover until level three. Level four is probably coming very soon. But yeah, creating a specification of this kind is not very easy. Basically, if you read any RFC spec, you probably saw that words are super precise. They are actually intended to mean what they are exactly intended to mean. The Salsa working group is also prioritizing stability. They don't want to put any requirements for each level that is not achievable or that they do not agree that is secure. And basically, everyone involved in this, there are many organizations involved and individuals, has to come to an agreement on what it means to be secure. So, yeah, it's kind of tricky to reach all of that. For example, well, for the build track, we basically have here the requirements for each level. Basically, for level one, you only need that the provenance document exists. It doesn't have to be verified, signed. It doesn't, you know, just document, provenance exists. For level two, it also requires you that you have hosted build platform. This is because usually when you have a build system that is very specific, it's usually easier. The attack surface is reduced and it's easier to harden it. If you have a system that only works for one specific thing, that's why it requires hosted platforms. And it also requires you to prove that the provenance is authentic, which means probably in most cases, digitally signed by the builder. And for level three, it also requires you that the builder is, all of the builders are isolated between each other so that credentials or private keys for the digital signatures cannot mess around with each other. The cool thing about Salsa is that you're not on your own. They provide a lot of tooling. For example, if you have an action job, then it's, in my opinion, personal opinion, it's kind of easy to, if the workflow is not super complex, then it's kind of easy to actually get salsa certification for your artifacts. They're also doing a proof of concept in Jenkins and they of course provide salsa verifier. So yeah, you're not on your own, as in other standards that just tell you, hey, you have to be like this in the end, but they don't tell you how to get there. As for community, it's an open community. Anyone can contribute. They're a GitHub. You can feel free to create comments, issues, merge requests. They have monthly meetings. You can basically attend. I think they are basically a video call, so anyone can go. They have mainly Salsa L. And yeah, it's probably not the golden standard yet, but in my opinion, it has pretty good chance. And even if it doesn't become this super important standard, then the actual measures that you implemented in your workflows will help you protect the supply chain. And also, being very early in stage of development, it also allows you to new contributors to actually influence the specification. So if you think something is wrong in the specification, feel free to go to their meetings and tell it or to create a GitHub issue. And also for the tooling, you can create new implementations for maybe for the Jenkins that we just saw, or I don't know. So yeah, that's everything, and thank you very much. If you have any questions, maybe we have some time? Okay. Any questions? Go ahead. It's self-certification. Well, you check if you comply with the requirements. You have the Salsa Verifier to check if the provenance is generated correctly. Yeah, I guess that at some point, we will have some certificators that will certify your pipelines for auditors. Yeah, thank you. Any more questions? Go ahead. For S-bombs. They are both independent things. You can have Salsa without having S-bombs, but you can very easily generate S-bombs from Salsa provenance. And it's usually S-bombs are generated in a non-verifiable way, right? Having the provenance makes it actually verifiable. So yeah, both things go well together. Thank you. Any more questions? If it's self-generated, you will ultimately hit up something like a chain of trust problem. Yes. How the Salsa Working Group thinks it's deferred to be addressed later? Well, basically, the consumer of the software decides who did they trust. So basically, has any other certification authority that you have on your browser, you're deciding or Firefox is deciding for you, or Trump or whatever, who do you trust? So it's very similar structure. Thank you. Any more questions? Okay, if you have any more questions, I'll be outside probably. And if you want to take...