Hi, everyone. Welcome, and thanks for joining us today.
If you are here for part one, you know we we had a ton of fun digging into the big questions around cloud native vulnerabilities. It was a really good conversation, and it it sets the stage for what we're here to to talk about today. So in this this session, it's all about action.
Gonna break down a straightforward four step framework to help you prioritize, act quickly, and better secure your cloud native environments. Get things started to get the juices flowing. I wanted to ask the audience, if cloud native vulnerability management had a soundtrack, what song would it be?
Drop your answers in the chat. I, connected with Erin right before this. She said hers would be numb by Linkin Park. Right song. Mine would be Electric Feel by MGMT.
Let us know what yours are, and maybe we'll make a soundtrack out of it. So alright.
Big thank you to Svi for being here today to guide us through this, and let's have some fun and get started. So, Svi, take it away.
Thanks, Joe. Thanks, everybody, for joining. My name is Svi, the field CTO at, at Aqua. And, we wanted to make sure that, we follow-up on a very interesting discussion that happened, in a forum that we did, last week. If you haven't caught it, you can look out for the recording and, and, and see what, what, some of our customers and and leading experts have talked about.
But when we talk about vulnerabilities, we're all drowning in vulnerabilities right now. We have a lot of work to do around vulnerabilities, and it's important to understand, what is the kind of best way to, provide a framework that will get us to reduce the number of vulnerabilities over time and then achieve some of the the metrics and the KPIs that we're gonna talk about a little bit, later. So, for those who who really, you know, haven't been, in in IT for probably the last thirty years, what is a vulnerability? Well, a vulnerability is basically a a software bug. It's a software bug that has some security implications.
The the big ones, usually get a name and a little logo. And if some of some of the things that you see at the bottom of the slide are actually, from, quite quite a few years ago, probably decades ago, and some of them are still are still with us. And, and and the problem with vulnerabilities is that we really don't know which bugs are going to have security implications, and we really don't know, what is the way that, a particular bug actually can be exploited, without doing a lot of research into it. So classifying the vulnerabilities as to what software bugs could have security implications and then, how do we counter them and how do we, secure against them is really the the topic that that we're gonna talk about. Today, we are dependent on a lot of external sources. We are dependent on things like the national, vulnerability database and, and the, maintainers of a lot of the open source packages that have vulnerabilities.
So it's it's it's a complex world. Now the reason why vulnerabilities are important, when I say that they have software bugs that have security implications, those security implications actually mean that somebody could, maybe use a vulnerability or a vulnerable workload. It could be a container. It could be a host. It could be a function.
And if there is a software bug in this, particular workload, then somebody could take advantage of it. And and they would wanna do what attackers want to do. They they usually have some kind of foothold that they wanna put in our workload. So it could be a, remote code execution, or it could be, an, a way to redirect and, and extra filtrate data, put in a malformed request into a service that will then give us more data than, than than we we bargained for.
So all of those things can happen once a vulnerability is exploited. But for the most part, what attackers want to do, they want to, get us to a point where, we actually work for them. Right? So it could be that they would wanna connect to our orchestration system to, maybe launch more workloads.
It could be that they would want to, gain a deepen, and and deepen their foothold inside of our of our host. If you're talking to a container, breaking the isolation between container and host is something that attackers will wanna do. And then everything that you see at the bottom of the slide is the the outcome, right, the business outcome. They might want to, in fact, propagate, create disruption.
A lot of times, they were gonna steal resources to run their own, you know, coin mining or or or any other, type of, of, program that they wanna run, or they wanna steal our information. Right? There are a lot of bad things that happen, and it all starts with the fact that there is a workflow that has a software bug in it, and, therefore, we want to, fix that software bug. We wanna get rid of that software bug so that attackers will not be able to to exploit it.
Now this sounds really, really simple. Right? So it's three steps. Right? Identify what packages, what files, what are the, component that you're using that have those bugs that have security implications.
You can cross reference that with, the public vulnerability database to get an understanding of of what are your components have have those vulnerabilities, and then you eliminate the vulnerability by changing something.
And that's there there's a lot of options for us to do. And this this looks like a very simple framework because we have the NVD, because we have a a database of of all the vulnerabilities out there, their associated components, and what could happen if they're exploited, it seems pretty easy that we'll be able to match them and then and then fix them. Now we're all here because we know that this is just not as simple.