 Hi, everybody. Thank you for being here. Yeah, it's 3 PM on Friday, so we really appreciate the fact that you're here today. My name is Miguel. This is Daniel. We are the co-founders at Chainloop. Chainloop is an open source project that allows you to collect, secure, and distribute server supply chain metadata. But before that, we used to work at Binami and VMware where we did a lot of CI CD automation. And some of that automation is what's behind today, for example, the Binami container images or Helm charts that you might be using today. But today, we are here to talk about something else. Today, we're going to be talking about what does it mean, trustworthy software build materials, why you should care about it now. Then we're going to be looking at different solutions that can help us to reach that goal. Then we're going to have a demo and finally some closing thoughts about what could come next. So we're going to start with this traditional CI CD pipeline all the way from source code to production, so you might be building a Go binary at build time, then your packaging in a container image, and then pushing it to an OCR registry, and finally deploying it to a Kubernetes cluster. But the interesting bit and the reason we put this diagram here is because eventually, and this might have happened to you already, you will get all their stakeholders in your organization that they will have a saying on how you are releasing software. So for example, you might have a security team asking for a mechanism to manage vulnerabilities, or you might have a compliance team that want to double check, or they want to make sure that some open source licenses for some third parties don't go through. And of course, you might have an SRAD or a platform team that wants to make sure that the system is healthy, so on and so forth. And this gets more complex, that the Pickert organization is, and we're going to see that later. But in our experience, many of these use cases starts with source supply chain metadata. And by source supply chain metadata, we mean any piece of information, any context that you can get about what you're building, and how you're doing it. So this can go from CVS scans, VEX files, some legal security architecture reviews, QA tests, and of course, software building materials. So software building materials is a canonical example. And for those who hasn't heard of it, it's just a standardized machine readable list of packages, licenses, and so on. So you might have been asked, and this again, might sound very familiar to start taking care of adding, generating those work below materials on some parts of your pipeline, or running some CVS scans and creating some control gates. For example, you might have chosen to use SIF to generate a Cyclone DX S-Bomb when you're building the binary. And then you might be taking a S-Bomb and sending it to an artifact registry and publishing it to an OSIO registry, or you might be sending it to dependency track to WAG, so on and so forth. And this is a good starting point. This is a good starting point, but today, what we want to be talking about is we want to be challenging is this vision on this line. This line that we call S-Bomb trust or below material trust, all the way from the generation to the distribution or analysis. And we know that S-Bomb trust is a very overloaded term. So that's why the easiest way, at least for me, to come up with what we're looking for is just to ask questions. So these are the kinds of questions I will ask about my S-Bomb material gathering, generation, and distribution. So for example, can I uniquely identify the S-Bomb material that I'm looking for? If I know I'm looking for a specific S-Bomb, can I find it? Can I, is it gonna be available when I need it? If I need it for some auditing purposes for some analysis, is it gonna be there or was just recycled by some archival processing GitHub? Can I trust that the content hasn't been tampered? If I'm generating at a build time, can I trust that when I use it all the other end, it hasn't changed? And can I answer an equation of how it was built by whom? And the last two things, they look like very simple things, but actually they're very hard to do. Is the S-Bomb complete or consistent with the rest of pieces of evidence that we're creating? And of course, it doesn't even exist. And the answer to these questions might be no, some of them, it's in our case, but now the second question will be about why should I care? I have my pipeline here, I have my checkbox as I got my bonus, I'm doing S-Bombs, this is great, but why should I care about all this additional complexity? And the answer is, well, I have two answers. The real answer and the answer that you might, your company might care about, but in general, supply chain start attacks are on the rise and this is causing some regulations to pop up starting with the US, but the Cyber Resilient Act in Europe coming next. So this might prevent you from selling software in the future if you don't start taking this seriously. So from that point of view, so bear with me, I know that this is overly dramatic, but a silver bill of material that you can trust is useless and in fact, it should be considered dangerous because you're making, or you will be making critical decisions out of it. So when it's silver bill of material start uniquely identifiable, enforceable, complete and available, I'm gonna explain what are those properties next. So we came up with this diagram, and this diagram is just a set of properties that your system, a system that goes from the end to end from the generation of the S-bomb or the way to the distribution should have. So things like making sure that you can enforce the collection of the silver bill of material, making sure that you can sign it and you can verify its integrity, making sure that it's immutable, it cannot be overriding, things like that. And we're gonna be going through each one of those and we're gonna be looking at solutions for those properties. And the first one is gonna be provenance and verification. And for provenance and verification, basically knowing how S-bomb has been generated and making sure it hasn't been tampered with, for us it's easier to start thinking about S-bombs from the lens of yet another artifact in your silver supply chain. It's just another element that you're producing and you need to make sure if you're working on the security posture of your company, making sure that you can elevate the security posture of that metadata as well to the highest security posture that you can offer because they can get compromised too. And the good news are that actually there is a framework that describes different levels of assurance, different attack vectors, which is the salsa framework. And this can be applied here too. And there are two concepts that to me are very important which is applied here, which are integrity and provenance. So how can we achieve that? How can we achieve integrity and provenance? And the underlying component of all of it is what they call software attestation. And an attestation is just yet another JSON file that contains arbitrary information about your software, what you're building. So for example, if you're building a container image, you might store how you build it or what's inside of it, what build system configuration you had. And that will give you the provenance information, but then the second part, the second component of an attestation, it is authenticated, which means that it is signed and which means that you can then verify integrity out of it. So as you can imagine, there should be a way that we could take our sort of building materials and somehow wrap it in a attestation and enable integrity and provenance verification with it. And we have tools out there. We have the Intoto framework, which is this attestation framework. We have six store, you can use six store, you can use any other provider. We have witness and also there is this effort called Spomit that is actually trying to solve the how you're building, how you're creating S-bombs that you can trust. So with that, we could say that we can cover more or less the provenance verification. So we have wrapped S-bombs at this point. But now the next question is where do we store it and how do we store it? So we can also meet the uniqueness and integrity part of it. And for that, you could say you can store it in a database, you can send it by email or things like that, but there is a much older concept, the content that is for storage that at the end of the day is just a place where you retrieve data by the digest of their content. And not by its name, not by any of the metadata, but just by their content. And that simple change enables integrity and immutability out of the box. And the good news for that is there is a content that is for storage solution that we use every day, which is an OCI registry. So we can use OCI to store S-bombs, and that will give us the unique and identifiable properties of it. So we go back to our pipeline, we could technically take another station, wrap the S-bombs in it, and then store that sign at the station in an OCI registry. So we will get S-bombs that you can trust in identity, integrity, and origin. So that's pretty good. But now you might be thinking, this is hard to scale. And because what I show, this one pipeline, and usually the responsibility is delegated to the development team. So how do you scale this for organization without having the problem of having all the metadata scattered across silos because they may be choosing different artifact registries, or it may be inconsistent because it may be using different tools, instead of using SIFT, it may be using something else, or different formats. And of course, you cannot, it's hard to enforce the generation without metadata. So let's say that you could disable 3B at some point, and that release will go through. So how can you enforce that? And that's one problem, but the second problem is if you remember this picture of different stakeholders asking for information, it gets much worse than that. In a bigger organization, you might end up having the security team starting to ask you about integrity with Salsa we mentioned before, or they might be asking about ways of sharing S-MOMS. You might be in the process of doing SOC2, which is a lot of fun. You might need to figure out how to retrieve pieces of evidence for that. And of course, the platform team might be asking for SLOs and more advanced things. So you can tell this gets quite complex, and it's very hard to scale. And that's the reason we build Chainloop. Chainloop, as I mentioned, is a mechanism to collect metadata, like silverware materials, and then security, wrapping into the stations, and send it to different locations. It can be OCR, registry, dependency drag, work, and so on and so forth. But the important part of Chainloop is that we make sure that we define the separation of concerns between developers and security and other stakeholders in your organization. So the people on the right can decide what metadata they want to receive, they can decide where to put it, and they can decide what to do with it. While developers will just need to provide the metadata to stay compliant with those requirements. So I'll do more on that. This is an example of how you could, with Chainloop, enforce the fact that you want to make sure that a RAM, RAMs in GitHub, and it's sending a second on the X JSON format. Once you do that, that requirement will get propagated to developers, and they will need to provide it, and that will get verified before sending it. So that will give us the enforcement part, and the second part is when we talk about availability, and it's the fact that Chainloop can give you, we call it federated content-adressable storage, but it takes content-adressable concept and move it one step further across different backends. So you can have advanced routing and replication requirements, so you might need to have some specific piece of metadata for two years in Azure Blob Storage because of some compliance reasons, you could do it with Chainloop, for example. So if you put together this diagram, you will see that we have the same open-source components which are awesomely six-door in total salsa, so on and so forth, but we extend Chainloop extends on the enforcement side of things, and also on the distribution part with the federated storage. So next, Daniel's gonna do a demo. Hi, everyone. Okay. Can you hear me? Perfect. So now the tough parts. Let's talk about our use case first. We are part of the organization, building and delivering software. We have many teams, many different microservices. We use different tools, but in that very specific scenario, we use GitHub on developer side, on SecOps compliance side, we use dependency track for CV scanning and open-source license compliance. We use Guac and we have also Azure Blob Storage, compliance storage across organization and one OCA registry. What do we want to do? We want to start collecting all artifacts built by developers together with software bill of materials. We want to store it in the trusted way. We want to wrap it in total attestation. We want to push it to Azure Blob Storage in OCA registry and we also want to send it to all these different DevSecOps tools that we have, like dependency track or Guac and others. So we'll use Chainloop. We'll deploy Chainloop on the right side and we'll have an API, the contract, defined between SecOps and developers. We'll ask them to run all these different workflows in GitHub and start providing binaries, the jar files, together with Asbone files. So as I said, let's take a look at the right side. We will use Chainloop open source project. Chainloop has a few components, the console plane, the API service. We have CLI as well and the CLI can be used on the operator side or on the CI side, the developer side. So in my terminal, I have Chainloop CLI, the latest version installed. It's actually live. So we'll show you, I have a few cast backends already connected. I have AWS S3, Azure Blob. I have our inline storage OCR registry. Let's take a look at the integrations that we have connected. As I said, we have few instances of dependency track, Guac, we have also Slack. You can add more, or you can build your own integrations as well. And the last thing, Miguel was already showing it, we have a workflow created on the Chainloop side and we have a contract connected. This is a declarative version contract, so you can keep adding or removing things here and they're going to be propagated to all organizations and developer teams. So let's jump to other sites. We are on developer side. Now we have to start sending artifacts and S bombs. So if you use GitHub, you can use our reusable workflow. As you can see here, you need just two files or two changes, one in dot chainloop.yaml file and specify where can I find those metadata or artifacts? And below, you have just a job to use that reusable workflow. And you need the token. We call it Chainloop robot account token to be able to push metadata and artifacts to Chainloop. Of course, you don't have to use GitHub. You also can use, as I said, Chainloop CLI. So we have, we call it attestation guided process and we follow some principles from Git. So you can initialize attestation. You can add different artifacts and metadata. You can push things to Chainloop. We recently also added support for remote state. It means that you can actually run all these different commands in different jobs and state is kept on the Chainloop service. So now let me go to developer. So I have that project. This is the Java demo spring pet clinic project. I already showed you that we added that change the file to specify where you can find my binary. By the way, you can take a look at GitHub. It's one of our projects in Chainloop.dev. And now what's going to happen, a new job is created. It's called Chainloop attestation. And as part of this attestation, yeah, great job. You have met all compliance and security requirements. You can see that all the metadata has been recorded. Everything what security and compliance team ask you for, the artifact, S-bomb and different other environment variables, Git commit hash, et cetera, et cetera. You can add more. If you click that Chainloop trust report, you can actually go to the Chainloop report where you can find all this information I talked about, the contract, the in total statement with all information like Miguel made the last commit here. You have all information about our GitHub repository, artifacts and some other identifiers from Chainloop. So that was the developer side. If we get back to SecOps, now I would like to show you that magically Chainloop, through integration, puts all these different metadata, artifacts to other systems and other services. So you can see here the Penesit track. I have my demo spring pet clinic. Developers, they don't even have to know about these services. They don't have to have credentials to the Penesit track or Azure Blob storage. The only thing what they have to do, they have to just focus on their artifacts and push metadata to Chainloop. So I can just show you that it's real. I can search for the most important library in Java world, log4j. Or you can see here, the different metadata automatically pushed to our Azure Blob storage. I can also take a look at our CLI. So I can list all workflows for the very specific, workflow runs for this specific workflow. I can also retrieve attestations. So you can automate things on your site. This attestation is verified with the public key I have on my computer here. I can get more user friendly outputs where you can see that everything has been verified. The same output you have seen in GitHub. Now, I want to show you one more thing. Because Chainloop is the open source metadata vault for software supply chain. So as you can see here, we are storing information about spring, pet cleaning, jar file. And we are creating some kind of graph in our federated storage. We have information about S-bombs. But at the same time, our security team, our legal team, our compliance team, they can start producing different metadata with regards to the very specific jar file as well. So, I have already pushed some metadata like VEX files to Chainloop. And I will try to download them. So what are we going to do? I'm going to first check the digest of the jar file I have here. And now with the digest, I want to query Chainloop. So I will ask Chainloop, tell me everything would you know about that very specific version of the spring pet clinic. Now you will get, you know, machine readable list of different attestations produced by different teams, parties, automations. And you can do cool things about that. So as I can see here, for instance, the one attestation created by security team, it's called VEX registry. So we are storing all VEX files related to different artifacts. And this is the attestation actually created by the GitHub, by the development team. And more security attestations. I can download metadata. And I don't have to have credentials to S3 Azure Blob Storage. Let's see how the network works. So I just downloaded Sbom for the jar file. But I also can read more about one of the VEX attestations. And I can see that there are two artifacts there, open VEX and also artifact. And I can even try to download that VEX file and then use it when the CV scanning with 3D for instance. This way I can remove false positives or other CVs that are already reviewed by our security team. So if you want to get one thing about this talk, it's about, we believe that metadata compliance and security, the bar is gonna be, it's been raised as we speak. And sort of build a material trust or metadata in general trust is the next challenge. And the reason we believe it's important is because it's the foundation for the rest of the use cases that we have been talking about. We have been talking about control gates. For example, you can use a discovery endpoint to find information you might be using. You may want to start sharing Sbom not by email but actually through another mechanism. So for that we believe that trust, metadata trust, for build a material trust is gonna be a requirement for the future. But the good news is that we have a, the future is bright with open source. We have very healthy set of tools right now that we can put together. And of course you can use Chainloop and you can find it in that repository. So thank you very much for your time. You have any question, thank you. Hi, thank you for your talk. Discover, I'm discovering Chainloop thanks to your talk. I have a question, did I understand this correctly? With Chainloop, I can actually have my VEX updated over time, does that mean that, yeah. Yes, I mean Chainloop can be a way for you to share VEX files but it's you to create those VEX files and then push them to Chainloop. So this demo is just showing you a way to collect and then discover VEX files. Okay, thank you. So it will not allow me to update with the latest build their ability disclosure. I will do, I need to do that. You have to do it on your own and then you have to push it to Chainloop. Yes. Okay, thank you, but Chainloop seems great. Hi, thanks for the talk and one quick question. Are you performing on Chainloop side any validations? If, for example, the S-bombs that are pushed by S-bombs, the artifacts are real artifacts. Do we do some kind of validations there? We do some validation in the client. So when the operator defines that it needs some S-bombs, it will say the format of the S-bombs. I mean to start with meaning Cyclone DX or SPDX and that means that when the developer provides that S-bombs will make sure that it's Cyclone DX 1.5 and things like that. What's coming though is actually making sure that you can add policies to that. So the operator can decide basically run a regular policy against the content of the S-bombs to make sure that it was generated by the version of SIFT that you really care about that you want to make sure that it has all the dependencies. So that's coming. So long story short, we have validations in the client. Right now they're more basic, they're basic, but now you're gonna be able to customize it with custom validations as well before they get pushed. Thanks. Go ahead. Yeah, there's one more thing. Today integrations are asynchronous, right? But what we are thinking about in the future, at the moment that you are sending, for instance, Cyclone DX S-bombs to Chainloop will do synchronous call through integration to some, I don't know, service to validate that S-bombs or to scan for CVs. And if something is wrong, you will be able to immediately report back to developers and break the PR just to ask for some changes.