 We're now going to have presentation from Steve Lasker and Justin Cormack about building, signing, distributing SPDXS bombs as artifact reference types. Please take it away. Hi, thanks for the intro, good to be here. Yeah, so Ms. Diva here, we've been doing this work, this kind of work spun out of the CNCF Natory project and it kind of crosses over into many different areas. So we'll kind of cover that as we're going. But we're working on this as a general way to support supply chain work across artifacts. We'll talk about all that is in more detail. But the main thing we want, you know, just starting off artifact registries, you may know them as container registries, but we're going to talk about how they're useful for lots of other types of artifact as well. And we're going to talk about references and basically attaching additional metadata to images in order to support supply chain use cases. So one of the supply chain things might be to keep cameras working. So I apologize for my video coming and going. So we'll just skip that and focus on the content. The, you know, as Justin said, that we have started this work a while incubation of notary. We saw this general application. So that's how we've wound up here. I'm just going to use like, wow, I'm not sure why things are changing. Anyway, we're going to focus on not on the bugs of why things are moving by themselves and assume that maybe this PowerPoint should be signed. Anyway, so we have this content workflow model and one of the fundamental differences that we saw with notary as we were doing it versus v1 versus v2 is the best practice of intent from the internet is you take possession of that content into your environment. So there's this content movement of signatures of the content that should go. So I take an image from why the networks might be a software company that publishes some they put it on Docker hub, then they might find them and they consume them, but they shouldn't be pulling it from Docker rub or M sure any other public one, bring it into the Acme Rockets environment and consume from there. We want to make sure the signatures can go with that. Turned out that was a generally useful application. It could also be used for SPDX's or, you know, any other artifact type, maybe scan results. So that was the incubation that we did there. The, you know, where any reference type. So we've got a couple here. We've also been looking at security scan results that can be attached to an image or anything might be attached to a helm chart. And there are some formats even evolving there. The source of the product that you're consuming, you might want to attach it so that you can get it. The whole premise is that you shouldn't have to go to some other place to get the content that you need where, you know, the supply chain, secure supply chain reference types. It should be wherever that image is for the thing that you're doing. Yeah. So basically, we want everyone to be able to easily attach any of these additional forms of metadata of which signatures and S bombs are the ones we've seen initially the most demand for, but to any, you know, to any kind of content that they're moving around between registries or and across their environments so that you can always, you know, have the pieces you need available to check them, verify them, validate them, where you need them. Let's just be anything. So we see the artifacts are copied across these different environments. And that kind of sounds like a great optimization, but this becomes much more reality. We have yet to find a customer that doesn't want to put their production, the production environments in some kind of isolated vnet that limits the access, outbound access, possibly inbound access. So this is the traditional problem of as I move from public shared internal they are pulling their base images from a common location to dev to staging and production at some point that's gone into a vnet environment that they don't have access to Docker hub or quay or NVIDIA or any of the other public locations or you know, get up for that matter. So the idea is that they travel with and how would we do that because registries? Well, I'm jumping ahead. Yeah, where is this info? So container registries started off about seven years ago or so with Docker hub was the first one and they were simply used as a means of distribution of container images to production container environments, but they've really evolved a lot since then. We're now seeing an awful lot of different types of artifact being stored in container registries. So things like WebAssembly, Helm charts and open policy agent conflicts and so on. So the registries, you know, the registry expanded into general artifact registries and this is increasing and in a sense they've become yet another storage solution. They've become a generic way of storing content address binary artifacts that are cheap and easy to distribute and widely available as commodity services that you can either run yourself or get from a cloud provider or you know, whatever else. So they're often available locally in production clusters and they're available, you know, centrally in the in the cloud or a sense of services like Docker hub. So there's something that you can rely on in a way that other artifact distribution, it really hasn't hasn't given that kind of widespread availability of authenticated and easily available and available as a service distribution of artifacts. And you know, we've gotten as far as to experiment further with, you know, can this infrastructure be used for some of the existing things that are out there? I try to focus on things that don't yet have a solution and not really, you know, not if any broke, don't fix it. It turns out some of these things are broke. They don't necessarily have the vnet, the geo replication, the double encryption of rest. I mean, it picked the problem that people keep on piling on to the requirements they want from their quote package managers. It's hard enough to manage this with the existing services that are out there that support these. The goal with artifact registries is basically said, look, focus on your thing that you want to build. Don't worry about building another one and we'll kind of elaborate on that. So, you know, as Justin said, they're ubiquitous, they're everywhere, they're every one of these registries has a large number of teams behind them that are done with all the performance, reliability, security, capabilities, and on a monthly basis those are increasing to what the expectations are. Users don't want to have 10 different ways to manage their artifact content. They want fewer because each one of them requires a set of configuration and environments and so forth. And I don't know if the spdx community or the cyclone dx community or the helm community or any of the other ones really want to go build yet another package manager because not only do they have to build it, design it, somebody has to run it, so it certainly costs them some problematic. So, the goal here is that, you know, we definitely want, the multiple artifacts do exist. There's no one artifact type that sorbs them all. There's just lots of them, they're creating every day, that's the goal of this, right? But should they have to create a service that goes alongside of it. Now what we've been seeing with signatures and S-bombs and scan results, it's not just around storing individual artifacts in the registries, it's how do I create relationships between those. And the, yeah. So, reference types are essentially a way of associating additional, one additional artifact or multiple additional artifacts with a target. So, you want to attach an S-bomb, X-post to, you know, the binary or you want to attach a signature to a binary or you want to attach source code to a binary and so on. So, they're associated artifacts and we've seen this pattern of people wanting multiple associated artifacts of different types and to be able to move them around either with or separately and add more artifacts without changing the content hash of the base artifact, which is what you have to do if you build a new artifact combining these in a content address store. And the detachable thing solves not only the ability to not have to change the digest or the unique identifiers in registries that happens because the interesting one is, you know, it's two analogies I use, one going into the airport. And when you go to the airport, when we used to do it and for the folks that are returning, you know, you show up and you give them, and maybe it's more of a passport office, but if you go to the airport, you're giving them some document that they don't allow you through the security gate. You hand the document to somebody, that person on the other side of the gate is evaluating, you know, your passport, your driver's license, whatever, and then does it match the boarding pass that you're being requested to use to get onto the plane. If they agree, they'll stamp your boarding pass and you're allowed through. The similar thing we see with, you know, with registries and content deployment. I don't want to pull the binary to an environment and then evaluate a signature that's attached to the binary because now the binary is already in the environment. We want to say, hey, I wanted to play this thing by a tag or a digest and I'm the S-bomb client and I want to validate that. Well, I'm going to take the name of the thing, the net monitor image, let's say, net monitor V1. Hey, do you have any SPDXs associated with that? Yes, I do. Let me hand you that. I'm not going to bring you the binary yet. Here's the SPDX document and the client can evaluate. So we're taking that airport analogy and using it here as well for how we validate separable but referenced objects. So that's kind of what we're talking about here. If we look at this flow, Justin, do you want to take this one? Yeah, so if you're looking at a flyer where you've got a target artifact, so you've got this net monitor artifact here and you push that into your registry, then the next thing you can do is add a signature that refers to that artifact includes the signature and says this here is the signature for this artifact and then you can attach an S-bomb to the object as well. So this is the S-bomb for this object and then you can also attach a signature for the S-bomb which says, you know, I've signed this S-bomb. You can trust that this is what's actually in the object and so you can be sure that you can rely on the S-bomb to know what's inside the object because it's got a signature that you trust. So this gives you a set of, you know, three additional objects on top of the base object that all linked to it. So let's kind of set up. Let's do some demos here of how this all works. So I'm going to just build an image and I've just done some environment variables here to make things a little simpler. It's basically the registry web and networks is the name of the company and they have this net monitor software named V1. So that's great and I can push that image to a registry that supports the reference types and that's there. Life's all good. But and one of the things that we wanted to be able to show is, well, how do I see what this graph is? Well, right now I've only pushed the image. So this ORAS tool that we have, it's the CNCF project for how to work with registries and reference types and artifacts, we can see there's a discover command with a new tree view that lets me see what's there. Right now we just have the stump. To be a little more generic, let's just say I put something on disk called something.json. It doesn't really matter. I could push this as a generic CLI. I could push it to the repo with an artifact type of something and it's referencing the image, the net monitor image and then just add that file and now it's been pushed to the registry. If I do an ORAS discover again, what you'll see is there's the net monitor image and now here is that thing that I added to it and that's just the artifact type and that's just the digest of it. So you're starting to see that tree get built. Now, let's say that I wanted to do this with SPDX. What you could do this with ORAS and the tools like turn and so forth. What we've done here, this is a total mock-up. I want to be clear here. This is just a mock-up of the scenario of how I would push an SPDX that has a signature and maybe I want to validate it. So here we've wrapped turn to be able to run an SPDX document. So that's what's been generated here and but because it's wrapped in this SPDX push that if I were to discover, let me just clear this out here, we now see that in addition to that thing that I've added, I've also added an SPDX S-bomb and it's got a notary vt signature associated with that. So we kind of build up these really robust experiences by using the notary libraries, the ORAS libraries to be able to take something like an S-bomb and put it into the registry. Now, you can extend it further. Let's say I had an SPDX LS. This is a way to say, well, I actually only care about the SPDX documents associated with the image. So it basically says, hey, registry, what reference types do you have of artifact type org.spdx.sbombv3? And it says, well, I have one. And then it looks at anything that hangs off it as well like the notary vt signature. So it could validate it. Now, we've just approved that we've taken this as a mock up for an example of something. We've got an SPDX, we've added an SPDX validate. And what it's going to do is compare the images, compare the documents that have been generated as a policy and say whether this thing is my policy. Now, I'm making the interesting thing about SPDX and S-bombs is they're telling you the ingredients that went into the thing. If I'm looking, you know, at a physical assembly of parts, I can see what those pieces are. But if I have a bowl of soup, it's all the ingredients are mixed together. I can't other than do some DNA analysis on it. I don't know what's in that soup. There's, you know, on this side of the can, it says what the ingredients are. Great. Now I know. I might not like pepper or Justin may not like pepper like that or I'm allergic to pepper or allergic to peanuts or something. I can't tell by looking at the soup whether peanuts are in it. I have to look at the list of ingredients. So I'm going to validate this image and the policy here says, you know, the packages that are in it I'm good with. So the soup is good. Everything's wonderful here. And that's, you know, the package type that might have been referenced together in the S-bomb. I'm going to build another one that has some pepper ingredients and that might be fine for some groups. I can push the image that's the pepper image to my registry, my network's registry. And now I'm going to do an SPDX push of the pepper image. And you'll see there's more ingredients in this one. So it'll go a little bit longer. And as a result, once this is done, it's a lot of ingredients, I'll be able to ask the SPDX LS CLI for what is currently in the registry. So I can see that I have a pepper image. It's got an SPDX S-bomb, so it lists all the ingredients, including pepper, and it's got a notary signature to make sure that nobody's missing with it. In this case, if I try to validate this, I don't want pepper. So I get no soup for you, right? The validation has failed because this document has said what the ingredients are, and I don't allow those ingredients in my environment. So that's kind of a quick demo of how all this comes together with being able to add detached objects that are referenced to objects that are in the registry. And you can do this offline as well. One of the notary signature scenarios is definitely everything is built offline in a very secure, isolated environment. The images built, the signatures are added to the image, the S-bomb is built, the S-bomb signatures are added, and then I would push those up to a registry as a unit. There's still separate objects, but I don't have to push the image to the registry just to sign it. Those manifests can be built locally. And then just to kind of give an example of where this goes, if you look at, you know, today if you want to take something from Docker Hub and put it into your private environment, you can just run Docker pull, Docker push, right? Docker pull, Docker tag, Docker push to be complete. What we want to be able to do is enable this graph. This is why it's important to have things as standards for registry implementations so that we can build lots of interesting tooling around all of this so that there's an SPDX tooling, there's an S-bomb, a notary tooling, there's the food tooling, the security scan results, whatever somebody wants to build that you can create a graph. And now if I say, and I just totally made the CLI up of OCI Reg copy, what's the source? What's the target? And now it can copy that graph because it can read from the registry in a generic way. It doesn't need to know about S-bombs or signatures. It says, let me understand that graph and I can copy it across. Now that content is available in that air-gapped environment so that my environment can work guess what all the different artifact types are. Because they're well-known, this is not just like, let's grab on some random annotation and put something in there, we can start doing things like include references or exclude references. So you have this deeper ability to how that graph is managed. Justin? Sorry, I was just looking at, sorry, we're just answering the questions. Nisha was asking about, can we attach other signatures like a GPG signature? I was saying that, I mean, this is a very generic scheme where you can basically reference any kind of object to any other kind of object and you can use it very generically, but we are working on common standards that are basically acceptable and widely used by common tooling. Because, you know, as you see from all the Steve's examples of this tools are going to mock up, the more specific tooling is, the easier it is to actually use. And so while we can make very generic tooling, that means the user has to do more work and specific tooling for specific use cases makes things easier. So we're working on standardized signature formats as part of Notary V2 project. And we're assuming, you know, we'll be supporting standardized formats for how, you know, this is how you store SPDX in a registry. This is how you store other types of things, just so that the tooling can be, you know, can adapt to the specific use cases. But all these standards are extensible if people want to do, you know, different things. And if people have different use cases, there is this generic underlying set of tooling that you can use to do anything. There was a question of what was in the SPDX that triggered that. So it was, we used turn to generate those. And there was a package in there, I think, actually, I think we're struggling with a little bit of the details. So we totally did a soup, a soup mirrors, a thing in mirrors on just hacking it for now. The idea is that in this case, if there was a package that happened to have pepper versus salt or something that that would get excluded. We need to do more work there or we'd actually like to work with the SPDX community to have them figure out what does a validation mean. And then the idea here is really what we're trying to show is that you can have the SPDX alongside the container image or the home chart or whatever it is you're trying to deploy because you can associate anything with anything in a registry. And then the no suit view is the example of obviously this isn't the final version of what you would do. So there's a question about with the registry be a store publishing non image SPDX S bombs. I'm not sure. In other words, if you have an SPDX on a home chart or on a binary that you want to deploy. Yeah, I mean, again, as Steve was saying earlier, people are using registries to store more and more different types of content. It's a content addressed blob store in effect. So absolutely no reason why SPDX should be limited to container images. There is a lot of demand for S bombs for container images and there's a lot of work, you know, in going on and actually building that kind of ecosystem out. But it's of and containers are kind of useful because they from, you know, they are fully self contained and useful things to, you know, to ship around with which S bombs are useful for but it's completely not limited to that use case. In the Q&A we have a question where can the user find details on why there's no soup for them? I'll have to ask Tasia where she put that but we need to clean it up. It literally, I think that about 11 o'clock last night we wound up just basking on the tag. But the design, the intent was there's a list of packages in the S bomb and there was a package named soup. So sorry, there was name pepper. I'm hoping we'll actually get that demo updated and we could make it more publicly accessible. Justin and I were joking about is the soup for you, the new cats and dogs demo for doing SPDX or other validations. So there's a question about is there a compatible registry and reference implementation that people can run? Yes. So all these prototypes, the reference implementations are there. There's a fork of CNCF distribution project which is the open source reference registry implementation. So the ORS project fork there has these features. So ORS project is now, is recently moved to CNCF and is where we're prototyping all the artifact reference work at the moment. So that's where you can find all this and we have weekly meetings on Wednesdays just a couple of hours. I think the real answer is that we're finalizing what that spec work is. There's an artifact spec that supports the reference types and that we have a reference implementation through distribution. We want to make sure people can validate that and not be coupled to any one cloud provider. We want to make sure you can run this locally, be comfortable with it, including the various registries. And then what we're working on is various registries are committed to shipping this so that we can enable the secure supply chain. And you'll see that with Azure, AWS and Docker where we're working to finalize this and ship this. And from an Azure perspective, we're working to get this shipped in the next couple of months. We want to get it out before people consume stuff for the holiday season and we're committed to shipping that capability by then. There will be, it won't be blocked on just this. We have some other interesting things we'll do so that it will work across all registries. But we want to make sure that the registries as a whole, the standards are moving up so that we can actually do these kind of interesting capabilities, these rich graphs of content so nobody has to build yet another package manager. We really want to continue to do the investments to make sure that the registry APIs enhance to support those. And that's the work we're focused on. So there's a question about what's the relationship between the AORUS project and the Notary Project. So AORUS is where we're doing the ACIP, the registry pieces about references. And Notary is where we're doing the pieces around signing and signature formats and standardization around those. So we're using both to do signing and obviously with detached artifacts and artifact references, signing is really important for anything because you need to know whether you can trust some artifact that says it's related to your things that we expect people to use signatures for most of these things. And so there's a question about trustworthiness again. We're assuming that people are going to use signing to validate their trust chains from the original provider to their consumer because that gives you an end-to-end signature that so you know that nothing's been modified on the way. And the Notary Project's defining how to determine who you trust and PKI pieces that relate to that and so on so that you can configure how and who you want to trust different providers for artifact or for S-bombs and so on. I think we're out of time now. Thanks for all the questions and You can follow up on, you know, there's info for contact info or the various projects and how you can get engaged and let us know what interesting things you guys are looking to store in registries. So thank you for the time. Thank you. Thank you very much. So that was excellent. I appreciate that very very much. I'm sure lots of other folks here do too.