 So, hi, everyone. Good morning, good afternoon, good evening, depending on where you are in the world. Welcome to today's CNCF webinar, Modern Software Development Pipeline, a Security Reference Architecture. I'm Christy Tan. I'll be moderating today's webinar. We would like to welcome our presenter today, Vinay Venskarstigan, Cloud CTO at Prisma Cloud at Palo Alto Networks. A few housekeeping items before we get started. During the webinar, you are not able to talk as an attendee. There is a Q&A box at the bottom of your screen. Please feel free to drop in your questions and we'll get to as many as we can in the end. This is an official webinar of the CNCF and as such is subject to the CNCF Code of Conduct. Please do not add anything to the chat or questions that would be in violation of that Code of Conduct. Basically, please be respectful of all your fellow participants and presenter. Please also note that the recording and slides will be posted later today to the CNCF webinars page at cncf.io slash webinars. With that, I'll go ahead and hand it over to Vinay to kick off today's presentation. Take it away. Thank you very much, Christy. Good morning. Hello everyone. Thank you for joining us to talk about the modern software development pipeline. A security reference architecture. My name is Vinay Venkat Raghavan. I'm the Cloud CTO for Prisma Cloud at Palo Alto Networks. Just to give you a brief overview on what we're going to be covering today. I'm going to be starting by talking about the major drivers behind the incredible adoption of cloud and container native technologies. And while at the same time, I'm also going to talk about some of the pitfalls and the problems that this innovation has brought about. I'm going to talk about the security reference architecture for the modern software development pipeline. And finally, we'll wrap it up with four demos wherein I illustrate the application of the security reference architecture to address real world use cases. So let's get started. So the cloud is modernizing the software development cycle. And what that means is enterprises and businesses need to bring in new and innovative applications to market at a very, very rapid pace than what has traditionally been afforded through the waterfall method. And what that means is they're adopting agile methodologies to bring these innovative applications much faster to market. And consequently, they've also realized that in order to truly benefit from agile methodologies, they need to decompose these monolithic applications into their constituent micro services, which can then be in parallel develop deployed and run in production environments to meet the needs of their customers and at the scale in which they need it. As you can see, the picture and the middle of your screen is a real world micro services deployment at a social platform, and each of those nodes at the outset, if you will, is a micro service and you can see there are almost a thousand of them with each of them communicating in different ways with other micro services. So this is the scale that the cloud is a 40. However, the biggest benefit of these two advancements is the ability to deploy software much faster. Gone are those days when software is deployed at a six month development cycle and companies are bringing to market new technologies twice a year. And albeit, dare I say, there are many customers who are deploying software and bringing new capabilities to market on a weekly basis and dare I say multiple times a day. So therefore, as you can see, it's this, this all these paradigms of agility micro services and a DevOps paradigms truly help customer enterprises to bring in new innovative applications to the market. However, there is a final pillar that they've also realized that they need to adopt. It is a common cloud operating model, whereby they represent all aspects of their infrastructure and their applications as code in order to build repeatable and reproducible structures that can that converge on the concepts of immutable infrastructures building and tearing down infrastructures at a very, very rapid rate and in conjunction with automation truly allow their enterprises to build innovative applications according to the cloud native and cloud operating model at a very, very rapid pace. That sounds great. However, all of this cloud innovation as I mentioned comes with many security challenges. The Palo Alto Networks Unit 42 research team that analyzed more than 200,000 publicly available infrastructure as code templates, found some very, very scary pieces of information dare I say, which really renders a lot of this infrastructure exploitable to breaches. So for example, cloud formation templates terraform templates and other types of templates form the bedrock for the deployment of large scale infrastructure on cloud and container environments, and we found that 42% of cloud formation templates are insecure. So what that means is when these templates are actually leveraged and deploying these applications and production, they are such that they have misconfigurations that are susceptible to breaches and exploits. Similarly, the cloud native model has also seen a great increase in the adoption of open source software and technologies. So Docker containers, for example, are a very, very popular deployment model, as we all know, but we found out that 51% of exposed Docker containers use insecure defaults. Once again, you can see when these containers are actually deployed in the runtime, it is exploitable through to all our adversaries who are exploiting every single opportunity to exfil data and enable breaches. And as we move through the stack, as you can see the hosts also form a very, very critical component of this architecture, and we found out that 24% of exposed cloud hosts have known vulnerabilities. So it's very, very important to make sure that these vulnerabilities are patched and addressed in a timely manner, and more importantly, at the right junctures before being deployed. And finally, compliance is a big task in the cloud as well. There are mission critical applications that are being deployed in cloud and container native environments. But the hard part is that there is no single source of truth which says that here are the 37 compliance controls that enterprises need to enforce to ensure that the GDPR compliant or HIPAA compliant, for example. These are a whole slew of challenges that enterprises are battling with as they adopt this new paradigms of cloud and container native deployment patterns. So, let's now talk about the modern software deployment pipeline. So, typically, this concern consists of the build, deploy and run phases. And what I tried to characterize in this diagram here by the rectangular rounded rectangular circles is the how these threats actually manifest themselves in throughout your deployment pipeline. So, rather than starting at the in the right, which is your runtime environment, let's shift left and let's talk about how these security threat vectors precipitate across the software development pipeline. As we talked about it, its infrastructure as code is tremendously leveraged to deploy along with automation, repeatable and reproducible infrastructures. And we've talked about the fact that, you know, DevOps engineers cannot be expected to be security experts. So, therefore, there are a lot of misconfigurations that percolate through your build, deploy phases and precipitate in misconfigured infrastructures in your runtime. So, we need to make sure that we have full visibility into the misconfigurations in your infrastructure as code. Similarly, the Docker files, which are the building blocks for your containerized applications also contain numerous entry points, if you will, so to speak, where security misconfigurations can result in drastic implications in the runtime. And finally, a number and putting on my developer hat, you know, when developers find reusable software. I mean, that's what it's all about. You don't want to reinvent the wheel. So we leverage a new package that is out there in different software repos. However, we have no visibility into the vulnerabilities that are contained in these repos. So these are all the areas where these new threat vectors get injected into our software applications that move, for example, from the build phase into the deploy phase. So in the deploy phase, now that your artifacts have been deployed, artifacts have been built, for example, your container images, and now you're using these infrastructure as code and also representing all aspects of your applications as of your containerized applications, for example, as Kubernetes manifest, and now you're ready to deploy them. However, you have typically DevOps engineers are moving at a very rapid pace and don't pay particular attention into the configurations in their Kubernetes manifest that could actually result in exploits that are happening in the runtime. So just to give you a quick example, a simple example is the security context, for example, to make sure that a container, unless absolutely necessary, doesn't run in a privileged context. So we all know that the threat vector there is for malware and code that exploits privilege escalation can actually do a container escape, access the host, exploit the host and could exploit it in terms of denial of service attacks, data exfiltration, etc. So that's one example of how insecure configurations and that's the threat vector that actually injects itself in your Kubernetes and application manifest. And obviously, as we keep continuing to build the story. Now, these are the artifacts that are going to deploy your applications in your runtime. So you have a large number of containers applications running as microservices on your Kubernetes platform that have many potential misconfigurations, which can be exploited by your bad actors, etc. So it's very, very important to have full visibility into these threat vectors and also understand in the context of the modern software pipeline, what these threat vectors are, and to make sure that we can take the appropriate remedial action. So what is really needed is an integrated and a comprehensive approach is required. So what does that mean. That means that you know you need to have protection across the entire development lifecycle throughout the build, deploy and run phases so security needs to be integrated and automated and should not be an afterthought. So to contrast that with a legacy software development model where development teams deploy develop applications and throw it over the fence to the security teams to perform security scans, who potentially come back two weeks later with a whole laundry list of items that need to be addressed when the development teams have actually moved on to their next features that they need to actually bring to market. I mean that's a recipe for disaster. So what needs to happen is security needs to be injected throughout the build deploy and run life cycles and more importantly, it needs to make sure that it is a first class citizen and not an afterthought. Secondly, we all are very familiar with the friction, if I may say between DevOps and security. Security teams think that they don't trust DevOps to get security right. However, DevOps teams feel like security doesn't understand their need for agility, and they feel that security is always bolted on and actually inhibits the need for their agility and bring all these innovative applications to market. So what is really, really required is for security teams and DevOps teams to meet in the middle, and more importantly, for security teams to empower DevOps teams with the right tools and the capabilities to natively inject security throughout the build and deploy phases, because as we talked about it there is another dimension that's very, very important. It cannot be bolted on because cloud native applications, they're not static, they're highly dynamic environments that are built, toned down, they massively scale, so security needs to be deployed in a manner that scales to meet the DevOps and the cloud native continuum. So security teams need to bring the right tools and the capabilities to enable those positive and desirable security outcomes. And finally, I also talked about that fact, I mean change is the only constant. You know, it's not only containers but an application stack in the cloud is composed of virtual machines, containers, and serverless capabilities. Therefore, you need a uniform capability to bring in cohesive security for each of these applications, assets and paradigms. You can't have one kind of a security capability for your virtual machines, yet another kind of security capability for your containers, and yet another type of security capability for your serverless capabilities. So you need a cohesive uniform pattern for security that you can apply across the entire application stack. With that, I'd like to introduce the security reference architecture for cloud native applications and CI CD pipelines. This architecture is very, very important for two reasons. It gives DevOps practitioners, it gives security architects, it gives CIOs, CTOs and CISOs a bird's eye view into all the different components that comprise a comprehensive stack to deploy cloud native applications, cloud native and container applications in various different types of cloud platform, cloud and container platforms. So, but secondly, more importantly, this is the first time when we call out the numerous places in which security can be injected throughout the build, deploy and run phases. So as you can see, the light blue boxes are where you can inject security throughout each phase. The phases are logically broken up into the development phase where it's the developer that's the developer and the DevOps team that are building the applications and the infrastructure as code templates. And then we also provide the hooks necessary as pre-commit hooks, for example, and we get into the details on the operational view. And as I call this, this is the technology view, but there is the opportunity to inject security in the development phase. Similarly, there is yet another opportunity to build and inject security into the build phase, as well as the deploy phase and the run phase. So this provides a comprehensive view and a bird's eye view into what constitutes to build a comprehensive cloud native CI CD pipeline, along and ensuring that all of the security needs and components are also addressed and incorporated into such such an architecture. So I like to call this the technology view as we call out all the points of injection of the native capabilities for CI CD pipeline, as well as security from the, and if you look at the right from your code commit through your CI CD pipeline, as well as in the runtime in terms of your IAS pass and container as a service capabilities, coupled with a uniform policy layer that ensures that the appropriate policies are applied across the entire cloud development and deployment continue. So let's now take a pivot to take an operational view to recognize what this would actually look in a real operational environment. So as you can see, from a horizontal perspective, this is logically divided into the build phase, the development phase at the top. The middle layer, if you will, is the is the build phase. And then in the final in the layer you have the deployment as a runtime. So let's address each of these in turn. I really want very, very important aspect that I think is very crucial for cloud native deployment and and applying security is the feedback loop for developers. You know, as I talked about it in a traditional model where developers deployed code security teams did the scan at a much later point and came back with the results to make changes. I mean the developer and the DevOps architects have actually moved on to their next features that they need to develop and bring to market. So it's unreasonable to accept expect them to actually go back. So this instantaneous feedback loop is highly critical in order to make sure that you have the right security posture. So let's talk about each one of that. In the first phase, we talk about the developer IDE. This is where the DevOps teams are building their infrastructure as code. They're defining their writing their Kubernetes application manifest. They're developing the applications. And if you can get the feedback from a security perspective to the developer right in the IDE, it's incredibly powerful. It's very, very similar. And this is what I talk about where security is treated as a first class citizen, because you have that instantaneous feedback and developers have a tremendous appetite, because they take a lot of pride in their code to actually be able to fix all those issues that have been raised. So let's take a look at that. Right. So any insecure configurations that are detected in your Docker files and your Kubernetes manifest as well as infrastructure as code can be scanned as a pre hook pre hook commit or even in your IDE across your development and development environment policy. So I call it you have three distinct policy sections. One is your development environment policy where it's a looser set of policies because you need your developers to be able to develop applications, test it and play around it's a broader set of guardrails, but across those three, those four dimensions of making sure that you're incorporating static analysis, vulnerability scanning, infrastructure as code scanning, as well as a Kubernetes application manifest scanning. So it is the all the scans happen according to your dev environment policies. And if there are any failures, there is an instantaneous feedback loop to the developers and the DevOps teams to actually make the necessary corrections. So, once all the necessary dev environment policies have passed the code actually gets checked into your source code management system in step number five. And then what happens next is to actually go into your build phase, where you're now actually going through the phase of building all the different types of artifacts. In this for the purposes of our conversation here, I'm going to talk about the containers, but you can see how you can have a uniform posture across building your cloud AMI if you will your version machine images, the container images, as well as the server images. So your build process is actually going to execute the Docker files, if you will, to actually bring all the necessary packages build the container image, and then actually results in the in the in a container image that's checked into a container registry. The next phase is you also want to make sure that you're securing the software supply chain. So you can also have a policy which says that no image that has not been appropriately signed according to your enterprise standards can ever be deployed in your environment. You make sure that just images are signed. The next phase is your application testing. So you go through your unit system and integration tests. Once again, which is, which is a model that we are all very, very familiar with is if there are any failures that the feedback loop goes back to the developer, and they go any way, but if everything passes. Now you can go to the next phase where now we are incorporating infrastructure is code scanning for your Kubernetes application manifest, your terraform as well as a cloud formation templates. And as you can see we talked about it just to once again bring a little bit more of that context to showcase how you can surface a lot of those insecure configurations in your build and the deploy phases, prior to deploying these artifacts in the runtime. Similarly, you can scan all your container images according to your enterprise policies. Now you're executing it on your test environment policies, which is probably a much more stricter and narrower set of policies against which you perform all of these scans. If there are any failures, once again it the feedback loop goes back to the DevOps teams to make the necessary configured corrections. If all of that passes, we now go into the deploy phase where you perform the validation of the images, hashes and the signatures, if you apply the runtime policies and then it goes into the runtime. And from a runtime perspective, I want to talk about three, four different pillars, you need to make sure that your container orchestration platform is appropriately configured. I mean Kubernetes for example is an incredibly powerful and a complex system, but you need to make sure that it's appropriately configured to give you an example. The Kubernetes API server should never be exposed to the outside world. It's very easy to see how you can actually have a denial of service. The Kubernetes API server should also be very, very hard restricted access inside your cluster where if you have a container escape malicious actors can now potentially render your entire application and your environment by executing a denial of service attack. And then next step is also to make sure that the NIST 800-190 special publication is very, very container and container application focus where it calls out from a, in a very systematic approach where all the security controls that need to be instituted in order to appropriately secure your container applications. I just want to talk about one particular control that it calls out for example where you want to make sure that your container applications are limited in the way in which they can abuse resources and execute privilege escalation or execute unsanctioned binaries for example. So all of these different controls can be executed in your runtime and then you can also apply all of these capabilities for your hosts and apply compliance controls for your hosts. Make sure that you have fine grained micro segmentation as well as last but not least, make sure that you have the right container and part security policies. You're making sure that the only sanctioned processes files and from a network perspective, you have limiting only sanctioned access. So from an up this is a operational view on how to actually take all of these capabilities of the technology overview of the security reference architecture and bring it into from an operational as an operational perspective. And finally, before we go into probably the most interesting part which is the demos. I also want to talk about, you know, cloud native, what a very, very important characteristic is scale. So any manual processes is a recipe for disaster. So you want to make sure that you are automating all aspects of the modern security pipeline. So what that means is representing your security policies as code. You have a uniform policy layer, which addresses the policies for your dev environment, your deploy test production policies as well as your runtime policies, your security scanning for your infrastructure Kubernetes manifest happens in the build phase, as well as in the deploy phase where you have CI CD steps that perform infrastructure as code Kubernetes and container image scanning. And if there are any failures, it goes back into the feedback loop, and there is a very, very tight loop that gives the opportunity for DevOps teams to be very, very efficient. This is very, very cost efficient because both from a reputational as well as a as an operational efficiency addressing security issues earlier in the pipeline is a very, very powerful capability prior to your applications being deployed in your runtime. And then last but not least, obviously you have the necessary runtime protections that has that enforces capabilities such as least privilege access only sanctioned access, etc. If we have applied all of these concepts and principles in terms of automation and applying the cloud operating model in conjunction with making sure that security is deployed throughout the build deploy and run phases with continuous integration continuous deployment security is treated as a first class citizen and it's not an afterthought. So a tremendous benefit here is now the attack surface is is dramatically reduced by the application of the appropriate security controls. So the last point that I want to make here is, as you can see security now scales along with the applications to meet the needs of both the cloud native applications as well as the requirements of the DevOps teams. So let's put all of this in context now. As I mentioned earlier, it's very important to make sure that you have the capabilities such as performing the infrastructure as code scanning right at the developer IDEs. It can also be done as a step in your CI CD pipeline, which we will see very, very shortly, you have full visibility into the vulnerabilities as that are existing existing in your container images. You do perform the scanning of your Kubernetes application manifest to surface misconfigurations and as well as last but not least, you have very, very fine grained runtime capabilities. So this is what a modern development and deployment pipeline looks like. And most importantly, now you have security injected at the right and appropriate places to actually follow and not be the application as they deploy throughout this phase and security is no longer bolted on. Once again, but that's that's a recipe for disaster because continuous applications are highly dynamic. So you need security to go along with it. So now I'm just going to quickly talk about and retrait some of those concepts that I talked about. And one of the most important concepts is the instantaneous feedback to developers where an application or a DevOps persona is developing their applications or the infrastructure as code templates. And when they perform a pull request, this is what they do all the time. But if you can provide the security feedback to them in terms of non compliance and failures from a security perspective, the DevOps persona can actually make the necessary changes and go through their development process. They can if there's a failure, they can make sure that they fix it and it goes throughout the pipeline. Once it executes all the necessary steps from an infrastructure as code as well as an application manifest scanning. If all of those past, then it actually goes into your source code management system. The next step is now you can potentially scan your container images in your registry. You have a full manifest of all the different packages. You have all the vulnerabilities that exist. If there are fixes that are available. So now you can apply your enterprise by policies to make sure that, for example, all critical vulnerabilities are fixed. If they're not, they go back to the DevOps teams to make the necessary changes. And if everything passes, then you actually deploy to the cloud or the container environment. And it's very important to realize that this concept of DevOps, as well as DevSecOps, it's a continuous process where you identify, respond, detect and adapt. I just also wanted to showcase once again, this is a real world example of a financial enterprise deploying using these capabilities to deploy a very, very complex application in a cloud environment across both virtual machines and cloud, etc. Where now you can actually, if we didn't have these capabilities of infrastructure as code scanning, it's possible that you deploy very, very insecure configurations. For example, you deploy a database that's that's can be accessed from the internet or the database is not encrypted, etc. All of these misconfigurations can be caught in your build and deploy phase. It goes through a security scan, for example, through your choice of CI CD platform and tool, you identify and fix the security issues. This really this whole process really enables much better security outcomes that scales to meets the demands of applications and cloud native deployments. And finally, once again, where this this whole concept where we have the application team, the DevOps team and the security teams working in concert where applications push new application DevOps teams push new applications into the runtime environments and security teams can now reason about their policies and all aspects of their configurations as code and can now actually check in code they can reason about it goes through their deployment and code approval process, but then it's highly automated, so they can now no longer be road barrier roadblocks to DevOps teams, but can now meet the same types of agility of the security teams. With that, I'd like to now pivot to providing the demonstrating how you can actually leverage all of these capabilities and make it actionable to address real world use cases. So the first use case that I want to talk about is the identifying and scanning your Kubernetes manifests within your developer IDE. So I have a container here, I have a, for example, I have a simple container definition here. And as, as some of you might notice, there are some glaring issues and problems. So let's figure out what these problems are. All I need to do is with the right tools and capabilities, I can execute a scan. And as you can see, this scan gives me instantaneous feedback right within the IDE, which tells me that this container is running. It's a privileged container. So immediately the DevOps engineer should make sure that they need to go back and revisit to say, it does this container really need to be a privileged container because we all know the exploits that can be executed as a consequence of it. Secondly, we all know, even from the NIST 800-190 where you should never run your containers as the root user. So entry point of the container must be run with the user with a higher user ID. So we know that we shouldn't be. So, but the point here is that you can actually make all of these modifications right in the IDE prior to the deployment of this application. So now I want to quickly pivot to actually showcasing how we can perform a similar scanning for infrastructure as code templates. Second here. Okay, so now here what I have is I have my infrastructure as code that it also forms the bedrock for a lot of these capabilities. And now I want to execute the Prisma cloud scan on my infrastructure as code templates. So once this scan executes, so what this tells me is once again the theme here is, you know, DevOps engineers cannot be security experts and security experts have those deep expertise and domain knowledge. But what this tells me is my S3 buckets are accessible to the public. My S3 object versioning is a symbol. These are all compliance controls that can now be addressed right in your developer IDE. So let's take one of these and make the changes to ensure that we have the right posture, for example. So as you can see, I can make the changes right here in my IDE, and then I can go ahead and execute a scan. So as you can see, I've now ensured that versioning is enabled for my buckets, I've made sure that it's not world readable, these are these buckets are private. So you can see how we can provide this instantaneous feedback to the developers and the DevOps teams to make the necessary changes to truly afford a more robust security posture. The next two demos that I want to showcase is the integration with the CI CD pipeline. So what I have here is, I have a Docker file. Let's look at my Docker file. It builds a security adapter that I have implemented. But what I want to do is make a few changes to trigger a build in a pipeline to showcase how it automatically can detect and provide the security feedback to your DevOps and DevOps teams right within the GitHub workflow. So let's make a small change here. Let's add a new license. Let's save this change. I'm going to push this change to my Git repo. And as you can see now what we're going to see is this is now this is my new repo. I pushed it. And if you go to the actions, you can see that it's already picked up my new changes. I'm adding a new license. I'm actually taking my Docker file. It's executing all the commands. It's building a new container image and it's also going to perform the scan of the container image and we will have the results very, very shortly. So as you can see, we have now executed a scan on this image. We have the results right in the console and your Git workflow. So developers have full context. So now they know what the problems are. So for example, this is the particular CVE. It has a severity of critical and it also tells you which version, what is the fixed status, when was it published. So there is very, very contextual and powerful information that is provided to DevOps engineers. It also executes a whole bunch of compliance checks. So for example, this is now we're actually executing it when you perform a pull request if you think about it. And then it tells me that this image should be created with a non-root user. So you can see how based upon all the different compliance policies, you can provide very, very powerful feedback to the DevOps engineers to be able to make the modifications and the remediations and then go through so you can ensure that the images that are deployed are highly compliant and appropriately secured when they are running the runtime. So the final demo that I would like to demonstrate now is the scanning of infrastructure as code templates. So you can see the, from within a CI step of your platform of choice. So I'm going to now make a change here just to trigger a scan of this code. So let's look at it. I have my Terraform templates here, for example. Let's go and make a small change to this file. Create VPC for demo purposes. So I want to showcase once again where developers are met right where they are in their familiar tools and their familiar environments and they have very contextual information. So let's say trigger security scan. And now I'm going to push it to my code repo, which will then trigger a scan using a CI CD platform that I'm going to use for this particular demo. As you can see this one. So it's going to go through the different steps for this particular environment. It's going to clone the repository. It's preparing for scanning and very, very shortly in a, in a matter of a few seconds, we will have the results of that scan. So if the scan results don't match your compliance and enterprise security policies, the build will fail and you'll have very, very contextual information. And I'm going to showcase how we can actually use the information that is as a consequence of the security failure to actually make fixes. So what this says is the Prisma cloud IC scan failed with security issues based on the configuration of the policies where there is one high severity violation and there is a medium, a medium severity violation which meets or exceeds the failure criteria. So based on this feedback here, I know what the problem is and in the interest of time I just want to show you how we can address it. So I go into my template. So I know that I've exposed my all my VPCs to the entire world, which which is a very, very bad practice and it's and the security controls caught that and let's make the change to fix it to a more restrictive CIDR. Once again, let's make the changes. As you can see, you can it's picked up the new commit. It's going to fix it's going to look into the, let's look at that step. In a matter of a few seconds, you can have instantaneous feedback. So I really want to reiterate the concepts of meeting security. This is the concept of security meeting DevOps, and really, really transforming it transforming the build pipeline into a modern pipeline where security is injected right throughout the build deploy and the run phases at this kind of a posture really, really helps security scale and tremendously limits the attack and threat vectors. So, once again, I know that I have a policy which says that I need to have it's a very, very restrictive policy as you can see here. But I have a policy which says that I should not have any high severity or any, any, any, any security issues at all. But if you notice we had the high severity security issue we fixed it now the high security issue is gone. But as you can see, you we apply all these policies in a single console in Prisma cloud, but you can now apply it across the developer IDE in your build deploy phases of a CI CD pipeline, as well as in the runtime environment. So, let's now pivot back to our presentation so that I can, you know, summarize all these different capabilities of our platform, but the most important point here is, it's a modern software pipeline and for cloud and container native applications. We need to make sure that security is a first class citizen and deployed at the right interjection points throughout the build deploy phases because as we know very, very well, security cannot be bolted on and it doesn't scale to meet the needs of a highly dynamic environment. We have some resources that we provide to really help the community as well as our customers along this journey. And we've, you know, in terms of our cloud native security report, as well as a blog where we really are very, very conscious of what that posture needs to be where security teams need to really, really empower DevOps. I mean, that's the secret to success for cloud native security and a modern CI CD pipeline with that. Thank you very much. And Christine, maybe we can open it up to some questions. Yes, I think we might, excuse me, I think we might have had a question in the chat. I just, I think it might have disappeared. So if you have a question for Vinay, please drop your questions in the Q&A box. We'll just give folks a another quick second here and see if anything populates. Thanks again for the presentation. Thank you. Not able to see the question for some reason. Yeah, I wasn't able to, oh, I think we have it. It looks like this is kind of product specific. So we'll go ahead and have you answer that one offline just because we want to keep this more general and open source focused as it's a CNTF webinar, but I'll go ahead and forward it to you. And we'll get your question answered on. Are there any other questions for Vinay? We'll have another minute, shy group this morning or afternoon, I guess. Vinay, is there, I think you had it on your slide, but if people are want to contact you offline or find out more information, I think you might have had a slide on that. Do you want to pull that up just to find out more information. So, I can, I can provide my contact information in the chat. My apologies, we didn't add it here, but Perfect. All right. Great. Well, thank you again Vinay for a great presentation. Thank you all for attending. A friendly reminder that the webinar slides and the recording will be posted later today to the CNCF webinars page. We hope everyone has a great rest of the week and we hope to see you at a future CNCF webinar. Thanks everyone. Thank you very much everyone.