 Welcome everyone Welcome to improving the security of software supply chains with notary project time. I'm Toli Mladenov. I am a principal product manager at Microsoft I'm a senior engineer at Amazon area blues. Okay So today we'll go kind of through the update of notary project What happened over the last six months? So we'll start with some overview We'll talk a little bit about the release of the tooling that We had we'll talk about the features So folks who are not familiar with notary project can learn a little bit more what they can use it for we have a couple of demos and We'll talk about our roadmap at the end. You have the opportunity to ask any questions Notary project is a set of specifications and tools intended to improve the security of supply chains for software I would like to talk a little bit about our kind of philosophy and how do we think about the Supply chain as well as how we hear customers are actually approaching the security So the first thing is smooth transition. So when we say smooth transition We understand that everybody wants to go and look at the latest and the greatest But most of the customers that we talk with they already say look I have some Infrastructure lights whether it's infrastructure for managing keys infrastructure for Even signing some kind of legacy signing Approaches we would like to have an easy way without going and deploying a bunch of new things and and setting a bunch of Infrastructure to actually move to something more modern But we also don't want to be locked into this legacy infrastructure We would like to have a path that in the future we can use things like for example Manage keys or you may know it as a keyless signing for example something that Billint will Go and demo later on so that is one of the principles that we try to follow So we provide really smooth transition for our users The next thing is Signature portability so especially in the container space what we learned is that You sign containers in one place and you may use them in a completely different place Typical example is like you pull the containers from Docker hub as a base images that you use to build your application Right and whoever pushes the images to Docker hub. They need to be able to sign them But after that most probably what you do is you copy these images from Docker hub into your own registry Or you copy them from your own registry into some air gap environment You don't need to go and actually re-sign again and again every time when you do a copy, right? Because you want to trust of what you acquire So portability of signatures is another principle that we follow in our project granular trust Control is another thing that we are looking like for example Who do you trust to do you trust everybody who published that sign image in Docker hub or do you trust just certain publishers? How do you create these policies? How do you say I trust for this signature for this repository or for that signature from that repository? In notary project. We think how you can actually control this trust Revocation control is another thing that actually is important How do you know that for example image that is signed once it's still actually trustable? We have many examples where we discover that well this signed software was actually compromised How can I invalidate these compromised images, but still keep images that are still signed with the same? Signer but are valid and they don't have compromised bits inside Privacy is another thing You are in complete control Who signs what keys you use with signing and you don't need to expose that to external world you If you want to you can but you are not required to actually share with the whole world that I A study signed this image for my internal use And extensibility is another one so extensibility not only in the let's say the signing formats Notary project right now supports two different signing envelopes one is JWS the other one is cosy But you cannot addition or if needed and if use cases require but also extensibility in the tooling so Our CLI has a plug-in model where you can go and develop your own plugins and we'll talk more about this later on So this is the philosophy of the notary project and how we look at that In August we did a kind of our inaugural release It included many things and we listed here I'm not gonna go into too many details in each one of them But one thing that actually is important to know about notary project is that we have a specification that everybody can go and implement And if they implemented the signatures that they create will be Portable to other tools that other people are implementing So you can just take the specification and implement the signing and Not use anything that for example notary project delivers us bit Or if you are interested to start going and using notary project tooling We have a CLI that you can use and sign Container images at the moment and we are looking in the future to provide other Signing opportunities as well as we have and apologize for my Notifications we have Libraries that you can incorporate into your own bits or projects in order to to generate notary project signatures And we have a couple of adopters that are already doing that Another important thing and I already mentioned that is we have two different Signing envelopes so you can choose between JWS, which is a very common format Everybody knows that but you can also choose binary cosy signing, which is very applicable to let's say Not so powerful work walls. So cosy is used in IOT work Workwalls where you have very actually small compute workwalls and it's very efficient format for that One more very important thing that we also do did us our release is we Get involved with CNCF and they are security teams So we got a security audit and we also have a continuous first testing on every bits that actually we produce Here are a couple of adopters and I will not go into too many details Especially in the big logo names, but I will talk a little bit about for example Harbors or harbour integrates with notary project signatures and if you use harbour as a registry You will see for example, which images pushed or artifacts pushed to the harbour registry are signed with notary project Kibirno, they have policies to validate images that are signed with notary projects So you can do admission policies with Kibirno for notary project signatures Venafied they are if you are familiar with Venafied they are a company that actually does KPI infrastructure and they have Infrastructure for keeping signing keys so they actually are developing a plug-in for our CLI so they can use their own on Infrastructure, but they are more and more adopters that are actually using notary project and we are Talking with many new customers and also other projects to get integrations Let's go through a very small demo what I will demonstrate right now is Using github action to sign image, which is local Locally built even before I push the image to the registry So this is a github action. I will kick off the build It will take couple of seconds until the the build starts It is very fast and we will look at the Individual steps and what is happening there? So the build started the first couple of things are Just setting up the environment we have a Available notation action notation is the CLI that notary project produces So you can go in on github marketplace You can go and look for notation action and use it So we have couple of actions one is for setting up notation for signing We have sign action and we have verify action in this particular case What I do is I build an image and I use build X to export it into OCI layout So the OCI layout is laid out on the file system on the build agent So you can see here. Let me just pause it for a moment So you can see here that this is the layout of the image itself So the image did not leave the the build agent yet. So it is on the file system then you can see that we signed the image with notation and Let me just move it a little bit We can also list the signatures on the image So everything is laid out on the file system The image is not pushed the signature is not pushed to the registry. Why is this important? So first is we constrain Signing to the build agent What that means is that I am not exposed to a tax Let's say to the registry because between the time that I push the image to the registry and sign it Somebody may actually send me the wrong bits to sign. The other thing is I am not required to go and Actually push the image to the registry I may want to actually transfer this to a air gap environment in some other manners So I can take the OCI layout and move it to the air gap environment Okay, let's go back to the slides and we'll talk about the features. So Milind Hi, everyone. Thanks. Sorry So let's kind of recap on the features that Tati kind of cover So we have you can sign and verify any OCI artifact It can be container images, attestations, packages, files that you store in registry We talked about portable signatures Images are portable artifacts that can move from registry to registry and we expect signatures to be portable too You can have multiple signatures on these artifacts Because you have multiple actors involved in software development and they can produce signatures on the same artifact You have full control over the data being shared what we mean by this is signatures and attestations are stored in the registry alongside the images and They have the same privacy level as your images are especially important for attestations because they can contain Confidential data like the identities or infrastructure or tool chain that you use to build your images You can sign with your existing solutions. We'll get in depth with a demo on this You're able to integrate with your own organizational PKI existing signing solutions third-party Signing solutions as well. We have a flexible trust policy We understand that you cannot go from Say you're not signing images to signing images and turning on all the bells and whistles It it can be an incremental adoption So we give you switches that allow you allow you to dial that slowly and get to your required security posture Incidence response control is about Revocation control we feel that revocation is a very important control you can get started signing easily But when you have Incidences like signing key compromise you want to control that publishers can use The publishers who have signed the artifacts to indicate to all consumers of that artifact that this identity is no longer trusted artifact validity control is acquired through Signature expiry we allow you to Expire set a custom expiry on the signature so you can control the lifetime of the artifact This allows you to implement governance policies such as not trusting artifacts that are say older than six months We have extensibility built-in which is in in three ways the first is plugins This is these are changes that you can do yourself You can build plugins for notation both for signing and extending verification logic We are extensible for signature formats we built the notary project Specification and notation tooling to support newer signature formats in future. We currently support JWS and cozy We currently support x5 online based identities These can be CA issued end entity certificates signing certificates, or they can be as a Signing service that signs on your behalf and these are the two trust models currently supported and it's extensible to support other trust models as well Let's talk about experimental features. We have OCI 1.1 in experimental support that That enables you to have a better experience OCA 1.1 allows you to associate metadata with images Without relying on existing mechanisms like tags or indexes which can clutter up the registry You can sign locally without needing a registry that that was the demo that Totted it. So let's go through a short demo All right. Actually, let's talk about Like in the reference architecture, how would you integrate notation at different places? So here's a typical workflow where you're building images distributing and deploying it and now we are introducing sign and validate steps in your in your CICD tooling in the build step you would install notation and integrated for signing you can You can have notation sign the image by providing the image URL and your key ID along with a signing plugin It'll sign the image push these signatures to the registry and they can these signatures can move along along with the images as using say Or as or any other open source tooling in the deployment environment, you would have notation Integrate with admissions controller and this allows you to You have trust policies which allow you to specify which identities are trusted to sign which artifacts and When the deployment comes in the admissions controller passes the image information to notation Notation fetches all these signatures associated with that image uses the trust policy to determine if the image is signed with a trusted identity and then you either allow the deployment Or you can block the deployment or you have you have options such as strict enforcement which will block deployment for untrusted images and You have audit policies which allow you to still deploy and you will get like logged warnings So I'll do a demo with AWS signer AWS signer is a code signing service It provides managed signing experience, which means you don't have to manage PKIs keys key rotation Etc. While signing you just have a API which allows you to create identities and sign with them and verify them AWS sign you can use AWS signer with an AWS account Signing images is free and that allows you to use AWS signer along with notation to sign your images. All right so here I've already set up AWS CLI and notation along with the plugin and We are using notation Plugin list you can see the signer plugin. I'm saving that in an environment. We're able to use later on Here I'm creating a signing identity this is called a signing profile resource in signer and This allows you to sign and you can use the ID or arm of this resource to do verification So here I'm creating a signing profile with name Ben and it is using the notation platform You can see the signing algorithm there as part of it here. I'm copying the ID of this identity and Setting an environment variable for it. This is the image. I'm going to sign. I'm using a digest URL for the image Here we are doing the actual step notation sign the particular image I'm using the plugin. This is the AWS signer plugin And the ID is just the resource that I just created called the the signing profile called Ben And this will sign the image and push it to the registry I'm using the notation LS command to show me Signatures associated with the image. There's only one signature and you can use the inspect command to see the details of the signature So here you can see signed attributes and you can see the certificate chain In the next step, I'm I Have a policy which says for this particular image use the strict verification The trust or a signer and I'm using the Ben Ben as the trusted identity. This is the signing profile unique identifier I'm importing the policy into notation and verifying the signature All right, so So we saw a plugin in action Let's dig a bit deeper into plugins. So we have signing plugins and verification plugins Signing plugins allow you to offload the cryptographic operation so that you can bring your own Signing infrastructure be it on premise or KMS, HSM or signing services. You can see a list of plugins that are already available on the verification side notation will do the signature verification and It allows you to extend or bring your own custom logic for verification There's a plugin available for signer which uses this feature to allow verification with custom identities which was the signing profile in the demo and Allows granular revocation checks so you can do per signature revocation checks Back to you, Toddy. Thank you so we see what actually we can do currently with notation and notary project signatures, but We will not stop here. So we are looking at new things to add to increase the security of the signatures and also to enable other scenarios like for example Very often, you know that certificates expire after a certain amount of time and the Signatures can break if those certificates expire. I already mentioned that we are looking at Signing arbitrary blobs right now Notation only can sign artifacts stored in OCI registries Those artifacts doesn't need to be only images container images We can push everything to OCI registry and sign it with notation, but we would like also to have the ability to Again coming back to the build scenario So when you generate any piece of software on the build agent and you generate S-bomb You should be able to actually sign all these pieces of artifacts With notation. So we are targeting in December to have functionality in experimental phase to actually sign arbitrary blobs later in 2024 we will add timestamp authorities Support that will actually allow us to actually have the signatures extended to a limited time. So as long as You trust the timestamp authority as well as tax signing. So we learned about interesting scenarios where you want to not only capture the The digest of the image as part of the the signature, but also some additional metadata which is as The image has as properties at the time of signing and normally let's say for example for container images when you build the image You also assign a tag. It can be a As we call it a floating tag So this tag can be changed next time when you do the build but you want to capture this information for certain security scenarios to know like Okay, what was the state of this image when I signed it and later in 2024 we would like to add additional attestation Support. So we're exploring different options for all kind of attestations that you Either there will be standard attestations to the image or artifact as well as you can create your own custom attestations And when we talk about attestations, so it's more standardized format because we currently support attestations so you can go and actually Assign a touch s-bomb to the image and sign this s-bomb you can attach additional metadata So we are experimenting with things like for example provenance metadata or Life-cycle metadata for the images or if you want you can go and actually attach currently a vulnerability report and sign it We are looking at more standardized approach and to align more with other tools available on the market and in the community to Provide attestations That was mostly it. So if you need more information, we have the links to the notary project website As well as notary project github repository. So we are welcoming any contributions any questions We are very open to talk with customers and users of Notary project and incorporate this their scenarios if you are interested about the basics and To learn more about notary project. We did a very interesting podcast with Tansu Whitney she spent two and a half hours with us and we started from where notary project started with How it evolved? What are the benefits or you can go and look at that? And if you want to go get in touch with either me or Milind, we have a link to our LinkedIn profiles We are happy to actually talk with you and we'll open it for questions. So if you have any questions, there is a microphone there We'll be happy to answer anything in the remaining five minutes Thank you Yeah, we have another 10 minutes for Q&A Five right Any questions or so we'll be here if you want to talk with us We'll stay for another 10 minutes. We'll be happy to have any discussion. Thank you very much everyone. Thanks