 Hello, everyone, and thank you for joining me for this CNCF webinar. My name is Oshrat Nir, and I am head of product marketing at Armor. Today, I'd like to introduce you to a new way of thinking about vulnerability prioritization. I will also show you how we implemented it on Armor Platform. DevOps practitioners and platform teams are all overwhelmed with a lot of work and it needs to be prioritized. If we were to go one level deeper, security has shifted left, so there's still more work to be prioritized and done. Today, we will focus on that long list of vulnerabilities your vulnerability scanner presented you with. And that you need to work with the security team in order to patch. As Leo Di Donato tweeted last year, CVE shock is the state of total helplessness facing the overwhelming list of CVEs returned by the vulnerability scanner. Are you in CVE shock? Well, let's take a deep breath and press on. By the end of this webinar, you will have heard about a post solution to this problem. These are the high level steps to manage vulnerabilities. Discovery, assessment, reporting, remediation and verification. It looks like five steps, but we all know that each step actually requires more work than a box on a slide. Much more. In this talk, we will focus mostly on the assess step, though we will be touching on discover and report as well. Let's talk about how a vulnerability scanner works. It has to be able to list the software on the container image, which is the extracting of the SBOM. The second step is comparing that SBOM with well-known published databases containing information for each software package. This results in a list of vulnerabilities that were found for that image. The extraction of the SBOM is done by using different methods, like using the package manager on the Linux distribution, or even PIP for Python or JAR for Java. All of these contain the package or JAR names and their versions. As we all know, vulnerabilities, also known as CVEs, are rated by severity and range from negligible to critical. Critical vulnerabilities are perceived as posing the highest risk to an organization. Factors that contribute to a vulnerability's severity include its potential impact on the confidentiality, integrity, or availability of a system, as well as the ease with which it can be exploited. The security researchers at ARMO ran vulnerability scans on six images that most of us use every day. As you can see, just these six images expose users to thousands of vulnerabilities. 5,874 on the version we checked. A risk-based approach to vulnerability patching is a method of prioritizing the patching of vulnerabilities based on the risk they pose to an organization. This approach takes into account factors such as the severity of the vulnerability, the likelihood of it being exploited, and the impact it would have if it were exploited. But this still leaves us with the question of, where should we start? Ultimately, what happens is that teams will tend towards solving this by prioritizing vulnerabilities with the scores that put them in the critical and high brackets, which still leaves us with 1,224 high and critical vulnerabilities in the example we gave, and these still need to be remediated and verified. This implies months of work just on this snapshot, and we can't really know the impact that you are making on your security posture. This may lead to CVE shock. All of this was the preface to the best practice that I would like to introduce today. The solution to the problem of CVE shock. This practice is rooted in the relevancy of the vulnerabilities to your specific Kubernetes environments. We propose to look at the intersection of the three circles and deal with those vulnerabilities first, since they have the potential to hurt you most. So, how can we detect if a vulnerability is relevant? If a software package is used, then the files it contains are being used by the container. If a software package is not used, it is not relevant for vulnerabilities and can be removed from the S-Bond list to compare, and that's the filtered S-Bond that we create. The risk-based approach better explains why patch the vulnerabilities in the overlap first. The source of vulnerabilities with the most chance of becoming an attack vector are the software binaries loaded to memory, as well as their accessibility from the outside. And this is where the relevancy feature comes in. In case you were wondering what happens if we apply the concept of the Venn diagram to the example images of our security researchers testing, we can see a massive reduction of 75 to 98%. After so much slideware, you probably want to see this in action. Remember that Venn diagram from before? I will show you how relevancy manifests itself in ARMO platform. In this demo, I will be showing you how the new best practice plays out in ARMO platform. I skipped vulnerabilities already just to shorten the process and to get to the point quickly. As we can see in the cluster, in my test cluster, I have 11,453 vulnerabilities, and this is the list of the images in my cluster that are the source of my vulnerabilities. In order to understand exactly how the new best practice works, we'll take one image, post-press, which is something that I believe many of you use, in order to understand how the new best practice, that overlapping of the Venn diagram, actually helps you get the most bang for your engineering work on patching vulnerabilities. So we can see that this image has 401 vulnerabilities. If we were to select only the relevant vulnerabilities, I'm just going to remind you here that relevant vulnerabilities are the ones that are loaded to memory when the cluster is in use. We have now gone down from 410 to 197 vulnerabilities, roughly half. That's already very, very pleasing because that's half the work that we need to get on with quickly, that fire that we need to run to rather than walk to. But it's not over because we have an overlap of three circles in the Venn diagram. So the next step we'll do is we will check what is fixable because there's no point in working on stuff that has no fixes. We need to coordinate off. We need to do other mitigation strategies, but implementing a patch is not one of them. So if we were to go fixable, what we have is we are down to eight and that is not the end because the third circle on the Venn diagram describes remote code execution or access from remote because it can be injection as well as execution. And then we go to guess and we are down to two vulnerabilities. And let me just recap so you understand what we did here. We went from 401 vulnerabilities to 197 relevant vulnerabilities to eight fixable vulnerabilities to two that can be accessed from the outside. Our priorities around patching vulnerabilities have just become crystal clear. Let's look under the hood of the functionality you just saw. We added a new agent to the Cubescape in cluster components, which is called the Taster. The Taster uses Falco's EBPF libraries to look at the file activity of a container. When a pod starts on a node, the Taster will watch its containers for a configurable learning period. Our default is two minutes and store an activity. During the process of scanning a container, an SBOM is generated. It provides the vulnerability scanner's understanding of which components are installed on the image. When we scan for vulnerabilities, we also provide the engine with a filtered SBOM, including only the packages that relate to the files that were accessed during the learning period. This provides us a filtered list of vulnerabilities that are more likely to be relevant. In this webinar, we discussed the new best practice for prioritizing vulnerability fixes. So let's put it all together now. 1. Scan your cluster in order to get CVEs. 2. Filter according to has-a-fix, relevant, and RCE. 3. Plan to deal with the vulnerabilities in the overlap of the three circles first. Now, since we do not recommend leaving any vulnerabilities unaddressed, there are a few more steps. For the remaining vulnerabilities, which are relevant and fixable, either pull a fixed image in case there is one or you update the vulnerable binaries. For the vulnerabilities that are relevant and have no fixes, take other mitigation actions such as creating a workaround. Lastly, patch the remaining vulnerabilities. If you'd like to learn more or keep in touch with us, you can catch up with us on the ARMO website or our socials. If you'd like to learn more about Cubescape or Contribute, visit Cubescape's GitHub repo or join the conversation on the Cubescape channel of the CNCF Slack.