 Hello. And I would like to talk about signing and validating serverless functions. So I prepared a kind of an introduction, a few slides, just to talk about code signing, why it's important. But I think after all these talks today, we can skip this very basic introduction. But I think one key takeaway I would take from this slide is that there's increasing attack and increasing no interest in attacking CICD pipelines. Cone can be modified, can be changed. You heard a lot about it. We can move ahead. OpenSSF was founded to address those supply chain threats. Project SIGStore started independently. Now it's part of SSF. OpenSSF to address the code pipeline phase. And I'm sure there'll be a few more talks even later today about it. And SIGStore is, of course, looking at how to sign and leverage this information in CICD pipeline. How does SIGStore work? And again, it's very, very just on a nutshell. So it can all be on the same line and just as a small background. So SIGStore is a collection of tools, created a very nice model of killer signing model. It also has the classical signing with private and public key. But if using the killer signing, you can use full SEO, which gives you a root certificate authority. Together with OpenAD Connect, you can get a timestamp certificate. And Cosign can use this for signing, creating a signature, record, this transparency log, which will be constantly queried and monitored to get verification and provenance. And as I said, Cosign can also be used in traditional key pair in case that your CICD doesn't support the killer signing model and you want to use it in traditional way. OK, that's just the introduction. We can move to the real topic of my talk. Now, serverless. Why is serverless so different? What makes them different than everything we heard until now? That I already talked about how identify the hash is, what we use. So container images typically identify with their hash. It's very easy. Today, it's a very common practice in Kubernetes to validate those images before deployment. So it's almost like build-in, whether using an open source tool like Gatekeeper or Keverno, whether using your own proprietary thing. This is a classical security precocious. It's been used by almost everyone to validate the images or not change or temper. Now, in serverless functions, usually you upload your source code into your cloud account so there is no hashes. Now, my friend here on the right side talked about drifts in your cloud deployments. And it applies also for serverless. You deploy with one permission. Eventually, you get some drift. You get some changes. So you probably don't want just to sign your code. You also want to sign the deployment file, whether using cloud formation templates, whether using any other infrastructure as a code. You want maybe also to sign it to verify that even those artifacts were not changed. So this is something which is probably a preliminary need. Now, in serverless, there is one more challenge because the cloud providers don't give you this admission controller. They'll give you this like validation function that can validate any action before you start executing the code. So those are the challenges why serverless is like a slightly different use case than any container image or the classical signing and verification process that we do. Now, there is one exception in AWS. So AWS has its own building solution. It's called code signing. It's a great step to secure serverless functions. You can use code signing to follow the functions. You can sign your code and then upload the signed code into the cloud account or to a three bucket. They need to create a signing profile which using the IAM permission to identify who and what can be signed. And then you can apply this signing profile to any lambda function that you want. And it verifies that the lambda is signed. And then before it execute, it verifies that it's signed and it's secure. So this is a great approach. What I would like to present is an alternative approach which using SigStore to sign it. So you can use SigStore and Cosign to sign serverless functions in their deployment file. It's a standard tool. So it can be used for any cloud provider, not just AWS. It designed to be used in CI CD. So it's very easy to implement and edit as part of your CD. So it's really simple. You have the keyless signing option, which is slightly safer. It's very nice at the moment. It's slightly still challenging to deploy, but it's a very nice and safer option. And of course, you can extend it not just to sign the function code. You can also sign the same deployment file. But SigStore still, at the moment, lack appropriate validation option. It has a validation admission controller for Kubernetes. It lacks a validation option for serverless functions. So what we did, and this is in Cisco, in the emerging and technology innovation team, we created an open source validation function. And we created a whole template for this validation mechanism. So how does it work? So again, use Cosign, bulb option to sign your code or sign any artifact that you want in your CI CD. You can use the key pair, private and public, or the keyless, which in turn requires to deploy record in your environment, or at least have access to it. Store the certificate and the signature in a secret storage. In this template, we use it in NWS, so we use KMS for it. And then you need to create a small mechanism for alert and eventing. So you need to get notification for any function creation or modification. So in this case, what we did, we used the cloud trail with the event bridge. So we created the rule that only trigger an event that trigger a function only when there is a new cloud function or modification to a lambda function. Now this rule allow us to invoke a validating function. So what we wrote is a validating function. This validating function take the key, whether the key or the certificate, take it from the KMS, calculate for the function which you deploy or the function which you update and calculate the hash, and calculate if the same key matches. And then it provides an output which can be used to whether you want to allow or to block the function invocation process. So it's like we created an admission controller that can be used for AWS account using the native tools like CloudTrail and EventBridge can use the same thing for in Azure or in Google Cloud. So what I want to say is that supply chain, the risk is increasing. Several of our special use cases, it's much harder to validate them. You can use open source tool like Sigstore, which for code staining, you can use open clarity. It's an open source repository. We can find templates. You can find validating function going to be uploaded in the next few days. And we encourage everyone to go ahead and use it. Give us good feedback. We'll be happy to fix and modify it. Could be for we're going to plan to upload a validating function for any Cloud provider. Thank you very much. Yeah, thanks, Ariel. This was really good. So I have one question. So does it have any performance impact? Because typically, people see with serverless, you need to execute very fine if you're adding these additional steps. Exactly. So yes, it has a performance impact. This is why in the validating function, we use the key pair, the public private key pair. So it's a traditional mode. But then you can really deploy it locally in kind of a minimal performance impact. OK, interesting. Any other questions? OK, let's thank everyone. Thank you very much. OK. Hello. Do you manage some custom root certificate for the key management of the six store to create the certificate to sign your lambda function? Or are you using just the default one of cosine? So I'm not sure. I heard the question. Can you just repeat? So you sign the lambda function via six store cosine or whatever. Yes. Which kind of certificate do you use, the default one or a custom certificate from a root certificate? OK, so you can use both, right? You can use their own if it's a keyless signing or you can use your own if you want to make it simpler to deployment. For the moment, the keyless is only working with certain frameworks like GitHub Action, so we use the classical traditional mode. If you want a good universal. But both options are available. Yeah, thanks, Ariel.