 I'm going to be talking about reinforcing the defenses to secure cloud-native applications. My name is Vinay Venkatragvan. I'm with the Office of the CTO at Prisma Cloud with Palo Alto Networks. I wanted to first represent some of the trends that we're seeing in the dramatic increase in the adoption of cloud-native and container-native paradigms to deploy critical enterprise applications. What we've found is 70% of global organizations will run more than two containerized applications in production. And this is also substantiated by the fact that there have been 8 billion pools. That's a big B in Docker Hub in January 2020 alone. And Docker Hub also has 6 million code repos. And it's interesting that 10 million images among those 8 billion have had more than 1 billion pools in 2019. And 84% of our survey respondents are saying they're using containers in production. So these are incredible statistics when we stop to take a look at it that represents the dramatic explosion in the increase in the adoption of container-native technologies to deploy enterprise applications. However, along with these new innovation and deployment paradigms, there have been a lot of risks that we've identified as well. An open-source survey found that out of 356,000 images that were scanned, each of those images had about 180 vulnerabilities on average in each image. And of course, these vulnerabilities were spread across different securities, but there were a lot of critical high and as well as low and medium vulnerabilities as well. And we also found that images were not updated for greater than 100 days. And as you can imagine, these are signs of numerous compliance violations. And we want to make sure that the latest images with the latest updates are constantly being leveraged to deploy these applications. And we also know from the previous stat that 8 billion pools in Docker Hub in January 2020 alone. But the way this propagates is that these vulnerabilities that leverage these base images are then used by DevOps engineers to build their custom applications. So vulnerabilities present in those base images now propagate from those parent to these child images. And as you can see, this now starts to propagate across a whole bunch of different application images and deployment paradigms. And then security research performed by the Palo Alto Networks Unit 42 report found that 51% of exposed Docker containers have insecure defaults. Once again, these insecure defaults when leveraged and deployed in the runtimes leave these production environments susceptible to exploits and attacks. And the last significant risk that we have identified is 40% of our respondents say that security is a major challenge. So while a lot of this innovation is happening, security is a table state. So what we want to do is help DevOps teams understand the threat vectors and most importantly, how they can protect their applications against these threats. I wanted to perform a test for myself. And I took those eight of those 10 most popular images and I ran it through a very popular image scanning tool. And I found the results to be very, very alarming. As you can see here, some of the most popular images had a lot of vulnerability spread across both critical high, medium, and in total, there were a number of vulnerabilities in these images. And this should be very, very worrisome. And what we'd like to do is notify our DevOps communities about these attack vectors from vulnerabilities and malware and provide them the capabilities to address these. And that's what we're going to talk about for the rest of this presentation. So once again, when we put it in the context of a modern CI CD pipeline, let's talk about how these security vectors actually impact our production environment. All starts in the build phase with DevOps engineers using infrastructureless code, Docker files, Kubernetes application manifest, but insecure configurations in all of these different artifacts actually find their way into your runtime environments. Similarly, let's focus on the Docker file. This is where you specify all the packages and the base image, et cetera, that define the composition of an application. Now when the Docker file is used to build a container image, this container image is checked into a registry when then typically what happens in the deploy phase is a whole bunch of system integration and unit tests. And then a lot of these infrastructureless code templates are used to deploy these images. So now you can see insecurities in your infrastructureless code manifest as runtime misconfigurations that can be potentially exploited by malicious actors. So what is truly necessary is a full life cycle security for cloud native applications where DevOps teams have purpose built tools like scanning capabilities of images and infrastructure as code templates integrated into their IDEs, source code management and continuous integration tools. And then in the deploy phase, they integrate container image scanners to detect vulnerabilities and malware present in their images and make sure that all these images are compliant as per their enterprise security policies. For example, you might have a security policy that says if there is a critical severity vulnerability in image and if that vulnerability has a fix, that image should make sure that it's always fixed and addressed before it's propagated into your runtime. And finally, in the runtime, you need the ability to actually have full visibility and governance with protection across the entire stack, whether it's virtual machines, containers and serverless across all the multitude of cloud platforms out there. So now let's talk about how DevOps teams can actually leverage and what they should be doing. Firstly, we talked about the IAC scan infrastructure as code as a threat vector. So we need to make sure that security and compliance control checks, for example, no image should be run as the root user or the security context should not specify that a container can escalate privileges. All of these different misconfigurations can be detected and identified in the developer IDE or when a pull request is made and all of these whole slew of NIST 800-190 compliance checks, for example, can be identified in your infrastructure as code in the build phase. Additionally, moving on, now DevOps teams also have the ability to perform constant vulnerability management for their source code repos. So you can point and shoot purpose-built tools that have the ability to scan code repos to ensure and surface visibility into all the vulnerabilities, have a prioritization of vulnerabilities that also enable DevOps teams to take the remedial action. Similarly, in the build phase, we also have the ability to perform image and function scanning. We want to make sure that DevOps teams have a uniform capability of identifying all the vulnerabilities in container images, in serverless images, and even VM AMIs, for example, to have full visibility into the vulnerability and compliance posture of these images and to make sure that DevOps teams can comply with those security controls prior to the deployment of these images into the runtime. Next, moving on to the deploy phase, we want to make sure that in your continuous deployment capabilities, you continuously monitor these container registries and serverless repos, once again have full visibility into the vulnerabilities, the malware, and the compliance posture, and constantly make sure, and it's very important to realize that this is prior to your applications being deployed in your runtime, you identify the security misconfigurations and vulnerabilities, take the remedial action, and only once all of these policies have been met does your application actually get propagated into the runtime environment, which now brings us to the next phase, well, runtime visibility perspective. DevOps teams and security teams need the ability to have full visibility into the runtime posture of their environment, so that they can prioritize the risk and compliance with top 10 lists that are prioritized based on the actual risk associated with the vulnerability, as well as the fixed capabilities, so that now they can actually leverage the entire lifecycle through the build, deploy, and run phase to have full visibility into the security posture, have full visibility into how these vulnerabilities can be fixed, addressed, and to make sure that they're fixed early on in the application deployment lifecycle. I now want to bring all these capabilities that I just talked about in the context of the developer, and it's a DevOps teams, and that's where, which is the most important to make sure that security teams are empowering DevOps teams with contextual and early security failures, so that DevOps teams have the ability to address all of these failures. For example, DevOps teams need to be informed of security failures when they make a pull request, so that they have the ability to have full context, they're working on a feature, there's a security failure, they fix that failure, and once those failures are addressed and fixed in the pull request phase, only then does that code get checked into your source code management system, and it progresses to the next phase. Similarly, we talked about the fact that once the Docker images, for example, are used to build container images, those container registries are scanned for vulnerabilities and malware, and only when all these vulnerabilities have been appropriately prioritized and addressed does it actually get pushed into your runtime environment. So what is very important from our DevSecOps perspective is the fact that this is a process of continuous improvement. It is not a discrete event where security teams have a mandate and DevOps teams have to make sure that they address it. It's a constant process of monitoring, making the appropriate changes, and over time dramatically increase the security posture for critical applications. And finally, I want to talk about the security automation stack for developers. And as you can see here, we want to provide all the capabilities across the entire stack to be able for developers and DevOps team to be able to perform. Let's start at the lowest layer, which is the infrastructure as code. Make sure that you're scanning your infrastructure as code templates, whether it is Terraform templates or your Kubernetes application manifest to detect security violations, misconfigurations, or compliance violations, and to make sure those are addressed early in the build and deploy phase prior to deployment. Secondly, we also talked about the abilities to meet DevOps teams at their turf by providing the scanning for docker images and container images, AMI, as well as functions for vulnerability and compliance posture violations throughout the CI CD pipeline through your custom steps, for example, into your continuous deployment pipelines. And lastly, we also want to make sure that developers, once again, in continuing with the theme of early discovery of security vulnerabilities by scanning Git repos to have full visibility into what the compliance violations are. This way this is a win-win situation for both DevOps and security teams and truly adopt DevSecOps where security provides the capabilities and has full visibility into the security posture. But now DevOps teams have contextual information that they can then leverage and use to make the necessary fixes, which dramatically increases the ability of DevOps and DevSecOps teams to deploy secure software. And the key point here is making sure that security is injected throughout the application lifecycle, throughout the build, deploy, and definitely in the runtime phases. With that, I'd like to thank you very much for the opportunity to talk to you about the ideal state for integrating security throughout your application pipeline for cloud and continue native applications. Thank you very much for listening.