EP246 From Scanners to AI: 25 Years of Vulnerability Management with Qualys CEO Sumedh Thakar

Security running.

Hi there. Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here are myself, Tim Peacock, the Senior PM for Detection, UEBA, and Risk in Google SecOps, and of course, Anton Chuvakin, a reformed analyst and senior staff in Google Cloud's Office of the CISO. You can find and subscribe to this podcast wherever you get your podcasts, as well as at our website. cloud.withgoogle.com/cloudsecurity/podcast. If you enjoy our content and want it delivered to you piping hot every Monday, please do hit that subscribe button. You can follow the show, argue with us and the rest of our Cloud Security Podcast listeners on the Google Cloud Security Community page. Anton, we have a CEO joining us today. That's a new one.

Correct. Well, it's not really a new one.

A public company CEO.

Okay, fine. Yes, that's a new one. But the topic is also Simultaneously old, very old, and also very now. So, this is one of those topics in security that if you take a time machine, you fly to— let's not go to 2005. Let's just go straight to 1995. Yes.

When I was in kindergarten.

Yeah. When you were in kindergarten, the topic would be kind of somewhat familiar to a 1995 security leader, and it will be very familiar to a 2005 security leader.

So this is an evergreen topic.

It is. I really hope—

Is green the right word for something like this?

It's an evergreen topic, but there's a but. Let's take a time machine forward. Does it do forward?

Yes.

Okay, this one does. Well, it does now. Fine. Yeah.

You're the quantum physicist. You tell me how time machines work.

No. Yeah, actually, forward is easier than backwards, frankly. So we're going to take our time machine forward to 2035.

Okay.

And I'm willing to bet that in 2035, it would not be a hot topic.

Really? You think in just 10 years' time we won't be talking about this anymore?

Well, we live in the area, right? And how many people here believe in AGI in 2 years? And we don't believe in VM being fixed in 10 years. Oh, it's depressing. Oh, wow.

I mean, I, I don't think I'm in the AGI in 2 years camp, but am I in the VM will be solved?

But you met people who are. Your neighbors probably are. You're in San Francisco, right?

Yes, I do live in San Francisco, listeners. My neighbors are into a lot of things living in San Francisco. So, I don't know if AGI is the weirdest thing that my neighbors are into or not, but listeners, let's not have any further speculation about San Franciscans or time machines. Let's turn things over to today's guest. Today, we are joined by Sumedh Thakkar, the CEO of Qualys. Sumedh, thank you so much for joining us today. I would love to start out talking about the journey that vulnerability management has been on. And listeners, for context, Qualys was founded when I was in the 5th grade. So what has changed since I was in the 5th grade, please?

Thank you so much, Tim. That's a great way of dating periodic table elements, right? But I think it's a very valid question. But first of all, thank you for having me on this talk, and thanks to you and Anton for this conversation. It's interesting. Some things have changed and some things have not really changed, right? The fact that if you'll just look at last year's Verizon Data Breach Report, vulnerability exploitation as a way for breaches is the number 2 reason why breaches are happening. And actually, the way the trajectory is going is expected to exceed even credentials and phishing as a way to exploit and conduct breaches. And so, in many ways, that hasn't changed, that vulnerability management is really crucial for every company. You're not going to find a single company that says we're not going to do vulnerability management and patch management.

Right.

So, that stays the same. What has happened, however, and for me, being at Qualys for 21 years— thank you, when you were in 5th grade, I started here— is back in the day, I remember a gold star customer was somebody who would scan their entire network of 5,000 servers once every 90 days, and then they had 90 days to patch. And it was, you know, the time you had was a lot and enough. And so now what has changed is that the scale has changed. And the speed has changed. And so just in 2024, almost 40,000 new CVEs were reported, right? Just, and that was a 40% increase from the year before. And the speed at which the attackers are exploiting those vulnerabilities, you know, it used to take a long time to exploit vulnerabilities. I think that speed has now actually come down, like, I mean, as a 70% decrease in the time it takes to exploit the vulnerability. And so—

So there's more of them and we're exploiting them faster.

Exactly.

Oh boy.

That's the thing, right? Like, you really— that has changed. And it's, I mean, it's natural because look, from compared to 10 years ago, 20 years ago, digital transformation, everything is digital today, right? Like whether, you know, you have countries where you're paying by scanning QR codes and thumbprint data and, you know, you are your today or medical, everything is digital. So there's just more software being written and more software being deployed and a lot of new assets, right? And so that's natural. I mean, and I'll say that having been a programmer myself for many years, it's just physics. The more lines of code you write, the more vulnerabilities total you're going to have in the codebase. And so that's what organizations are feeling now. And that's kind of the state where we are, where it is important. It is a key factor. However, it is too much and too fast. So now the question is, how do we address that?

It's not as if people are going to stop writing software. So what do we do?

Yeah, I mean, that's the thing, right? Like you're going to have, and, you know, we'll see how AI writing software and all of that. But I mean, you know, just as a, a little bit of a facetious thing. I say that the AI writing software has been trained on the same code that has had all these vulnerabilities. So, so it'll remain to be seen. Is it good at reproducing those or is it actually good at not reproducing those? Right. But no matter what, I think it is gonna be something that vulnerability management still continues to be a significant defense mechanism for almost every organization. It is just that let's reset this, right? Like at the end of the day, cybersecurity is a risk management exercise for a business.

Yes.

And so when you talk about risk, the first question is how much and the money part of it. And so now when you're talking about so much volume of vulnerabilities and so many patches and stuff like that, it costs money. And so that's where now today we are where it's like, well, how much should I be spending? I cannot fix every vulnerability that's out there. I cannot even fix 10% of the vulnerabilities being detected. So which are the ones that I should spend my money in fixing so that I get the maximum risk reduction for my organization? And that's the maturity journey that we are on. And that's, I think, is evolving with vulnerability management. Other than, of course, you have more vulnerability sources that are coming in, OT and IoT, and a few things that were not there a few years ago. And some sources really didn't materialize, right? Like bring your own device and mobility was such a big concern a few years ago, but today we don't see that as a key vector for people to make significant compromises at scale. So, That's the journey that we are on right now is like, well, you have too much happening too fast. You have a certain limited amount of budget that you need to spend on defending. And then where do you put that budget for vulnerability management?

But so to introduce a bit of a same versus new model beyond what Tim asked is, you brought up an excellent point. The remediation is often about, I have a fixed amount of money and what are the vulnerabilities I have to remediate? given that budget. And I think if we take a time machine to 2005, and that frame would be very familiar to a CISO back there. Like, it's logical. It's people occasionally in some industries, we have people who say, I want to fix all highs, all mediums, and take a shot at lows. And we'd be like, no.

Yeah.

No. But in a more sane way, you're right. It's the fixed amount of money, what to fix. That part seemed to be the same, but what is different from what we had to answer that question today versus, well, I don't know, pick a year, 2005 is just a nice round number.

Sure. Look, I think back then, I would say that, again, it's the volume, right? The number of vulnerabilities that you had to fix and patch was not as high as it is today, right? So that was the first thing. We have also been on a maturity journey in cybersecurity over the last 20 years, right? And so part of this was, and even till now, a lot of cybersecurity, what we do today is a best practices-based approach. Oh, we should do this, we should do this, we should do this. Second maturity journey has been CVSS scoring. You know, back then that was the mechanism people used, and even people use that today. But we did this study a couple years ago with Qualys. We know, obviously we do billions of detections, and we said, hey, let's look at the vulnerabilities detected across our customer base. And we found out that almost 80% of the findings we had were CVSS critical and high because people were not even scanning for the low and the mediums because they were barely—

Wow.

So when you are looking at billions of findings, so that's where the maturity of that approach still has to evolve. And so the mechanisms we were using 20 years ago to prioritize are not the same mechanisms that are really working today because just because your CVSS is 9.8, but if there is no exploit associated with it or this or that, it's not a priority today because you would rather put your money on the 6.3 CVSS score, which actually is part of a kill chain for a particular platform.

Actually, sorry for interrupting for a second, but I imagine myself in that moment talking to, let's say, a CISO or somebody from his team where I open my mouth and say, hey guys, yeah, this is 9.8. It's almost the maximum. Don't fix it. Don't fix it first. Well, fix it, but don't fix it first. I would bite my tongue a little bit. Like I'd be like, I know the algorithm, I trust the logic that you run and other, some other vendors maybe run, but I would be like still very squeamish or, you know, squirming before I say that. So how does it work?

Well, absolutely. That, and, and that is what you have to be able to provide is the justification and the explanation of why a 6.3 should be fixed.

Mm-hmm.

And why a 9.8 is not as important and explaining that. And so that's why I say it's a maturity journey that we are on right now, right? If you had all the time time and the money and the resources to fix everything that was critical and high? Yes, sure. That's great, right? And again, right, what today 9.8 is not exploitable or not important might in 4 days become. So your program also needs to be something that is not static. It is not like once it was 9.8 and we decided not to fix it, we don't fix it anymore, right? And that's where the evolution of this sort of vulnerability management, and I always joke about how we At the end of the day, the only value that you get in the vulnerability management cycle is if you actually fix it. And so, when I introduced patch management 4 or 5 years ago, everybody told me I was crazy to do that. Nobody would use it. But Qualys, we have 110 million patches deployed just in 2024 by our customers because remediation is super important. And so today, it is really about how do you operationalize the entire workflow of detecting all your assets, detecting the actual vulnerabilities, prioritizing them, based on the threat intelligence, but I will also add the business context of the machine. And then if you cannot get it remediated, what's the point of all this investment, right? I mean, we could— you can build all these dashboards and take selfies with it, but if you didn't fix the vulnerability before an attacker got there, what was the point, right? So this operationalization journey now is super important, you know. Otherwise, I know it's like if you just keep scanning, scanning, scanning and not having a good program to fix the right one, then that's like, you know, you weigh yourself 4 times a day, but you don't go to the gym.

Okay.

Yeah.

I mean, I'm stuck now. You put a very interesting image of taking selfies with dashboards in my head. So, unfortunately, this now poisoned my mind and it's gonna spread, and I'm gonna tweet about it like crazy and all that stuff. So, this is definitely a really good metaphor. And people do effectively do that. Like, they increase the frequency of scans without any change in process. Even in quote-unquote days when I did this thing at Gartner, I've had people who say, I want to switch to daily scanning. And I said, well, is your remediation process any better compared to 5 years ago? And they said, nah, it's the same process.

Okay, wait.

So, explain this one to me. You want to scan at 3x higher frequency, but you remediate at exactly the same speed. And they would say something about, like, how awareness allows them to respond if there's It is somewhat of an answer, but it's still a bit of a sad answer.

And it is the feeling that, okay, that's IT team's job, right? And that patching is IT team's job and asset management, IT team's job. And I, you know, I ask CISOs, right? Well, if there is a breach and you are in front of the SEC or something like that, you think the IT person who did not apply the patch is the one who is gonna say, hey, you know what? Nevermind. I will go and face the music. No, it's still the security team who has to be in front of the board and everybody. And so security team needs to have a big stake in helping and making sure that remediation actually happens. And that's why 4 or 5 years ago, when I noticed that vulnerability volume was going up too much, and it was— people were not going to focus on finding more things, people were going to focus on getting the right things fixed. And we introduced patch management. Yep. It validated that, you know, 110 million patches deployed by Qualys just in one year really validated that security teams are actually a key part of making sure that they're getting these things fixed. And so, That's where the evolution has happened is we started saying, let's use threat intelligence. But even after using threat intelligence, right, you still have a lot of findings. And so how do you make sure that they apply from a business perspective? And I always give this example of like, if I tell you that you have 2 business units, one has a risk score of 900 on 1,000, which is pretty high. Another is 750 on 1,000, which is, you know, not so high. Which one would you prioritize to fix first? People pick the 900. Say, but let me tell you that the $900 million is on the business unit that makes you or business $2 million a year. The $750 million is on the one that makes $500 million a year. Immediately your prioritization flipped 180 degrees.

Yeah.

So any conversation of prioritization without some aspect of value at risk is really not helpful because yes, you might still end up fixing a bunch of things that maybe not be so important to the business. So that's where they, when we introduced at the end of last year, the concept of a risk operations center was, right? How do we evolve vulnerability management into bringing all your assets, all your findings from multiple tools? It doesn't have to be Qualys as the only scanner. We can bring all the data from multiple tools, then apply threat intelligence, apply business context, get remediation and compliance done. And the Risk Operation Center is not a— it's a category. It's not a Qualys product, but— and the Risk Operation Center is expanding beyond vulnerability management as the CVEs and software vulnerabilities into— misconfigurations and identities as well. Because at the end of the day, when you look at holistic risk, these are the 3 things that come up together. Because you could have a machine that you patched all the software vulnerabilities, but the C drive is open read/write to the whole network. Well, it's not a CVE, but your risk is horrible.

This is a very '90s vuln, though, right? I mean, I know people have them now, but it's also a very classic one, so to say, that goes back older than Tim's 5th grade. You mentioned something that started to slowly trigger me because when you did bring automated remediation up, I was probably one of those people. I don't recall if I was still at Gartner, but if I was, I probably was in that crowd of people saying, ha, automated remediation, it would never work. These servers are too snowflakey. Everything is very fragile. If you automate, it's going to blow up. Everybody would blame you. So, I easily believe that I was in that crowd yapping that it's a bad idea.

Yes.

I was wrong, huh, about that. But I also, I know that it's hard to argue with facts and you did make it work. But why did it work? It was not supposed to work.

Yeah, great, great question. And yes, I think you guys were one of the ones that were skeptical, but that's the industry was. But look, I think the reason it's worked is that people started realizing that the attacks were coming too fast, the volume was too high, and at the end of the day, the outcome was only when you were doing patching. Now, Just like with anything else, it doesn't have to be a zero-sum game. So what our customers started doing was they started leveraging a risk-based patch management approach, which is, do I have to fix everything in a completely automated way? No. But if I can take, let's say, all my— so we have a customer that has 400,000 employees globally, and each of their laptops runs a Qualys agent that does patching. And as you know, Google Chrome likes to release their zero-day exploitable vulnerabilities on Fridays. And so teams don't want to sit all of the week trying to fix those. So what they do is they take a risk-based approach. How many times has a company's business come to a stop because you auto-updated Google Chrome across 400,000 assets? No. But how much time will it take manually for IT to push out these packages and stuff like that? So what we see is a lot of customers take a risk-based approach now where they're saying, look, if I can free up my patch team's time to focus on some, a lot more operationally critical assets, then I can leverage automation in many ways. I can leverage manual patching through Qualys in other cases. And so the desire to sort of say like, look, it's a tool that is available to us where we can use automation in many places. And it's always about balancing the operational risk with the security risk. And you cannot do automated patch management without prioritization because if your CVSS is telling you you have to fix 10,000 items, fixing 10,000 items can be 1,000 patches. 1,000 patches is 1,000 opportunities for operational things to go wrong. However, if you use prioritization, those 10,000 findings become, let's say, 1,000 findings. 1,000 findings, fixing those could be 15 patches. That's a much more appetite for people to say, look, I think for the sake of security, we can take a bit more of this risk because now we're not talking about applying 1,000 patches. And that's why it has worked, is that we've bridged the gap between Giving the IT team 10,000 CVEs and saying, good luck. And then they go to Google, they try to find a patch, apply the patch, come back, it's not applied. To like, hey, here's exactly what you need to do. We will do it for you. We can tell you, by the way, this patch has been deployed by a million other assets and there was no error. So it gives you more confidence. So we have made it more operational than just that. Patching has always been there. It's available. It's just we made it work a lot better with security.

I think that the argument, the point about Chrome is kind of interesting because obviously Chrome has been auto-patching for between 15 and 20 years. And people were probably a little iffy in the beginning, but I haven't met that many people who actually complain about Chrome auto-patching.

Have you met any?

I've met some. Yes, correct. I've met people who hold Chrome patches.

Yes. But that's more reflective of their applications. You know, in 2025, if you have a web application that breaks because Chrome was updated, I think that's more of an issue on your application side and not so much on the Chrome side, truly.

Yeah, that's a skills problem.

Yeah, exactly. But I want to make another point here. We also went a step further to say, look, at the end of the day, the security team is not so much concerned whether you patch or not. They just want to make sure that the exploit doesn't happen. So let's take a moment to think about that. So patching is obviously one way of doing it. So what we did last year was we also introduced the concept of mitigation of vulnerabilities without applying a patch. And as you guys know that at DEF CON, we won the Pwnie Award for the best RCE. So we put a lot of investment in vulnerability research and all of that. So because of that, we analyze all exploitable vulnerabilities and we came up with small tweaks that you can apply on a machine that actually prevent the exploit from happening. Like in some case, you could just change the permission on a file and the entire exploit will be blocked, or you could change a registry key, or you could maybe shut down a service or something. We've expanded this universe of what I call mitigation to not just be patching, but now we give— and by the way, in some cases, in many cases, in fact, we see that the vulnerabilities on a software that has not even been used for a whole year on the server. So, you know, one of the mitigations is uninstall that software.

Uninstall the software. But it's advice that would have worked in 2005. I mean, again, it's not that I expect it all to be AI and unicorns from here to forever, So it's interesting that some of the stuff we've been telling people for 20 years was actually right.

But it is a volume thing, right? Like in 2005, the number of findings you had to fix on a machine was a lot less than number of findings you're fixing today on each machine, right? And that's what it is. So now what it is, is that the idea is that we have a remediation buffet, as I call it, right? Like you can pick, like when SharePoint vulnerability came out a couple weeks ago, the immediate action was to put a mitigation. And then when the patch comes out, now you can patch it. In some cases, you might uninstall certain things, right? So at the end of the day, we need to move the conversation from an operationalizing perspective to say, you know, and there are many nuances that are coming up now, right? Which is like, well, technically the vulnerability scanner is saying that I have this vulnerability, but by the way, I'm also running EDR on that machine, which has memory protection enabled. And so the risk of the exploit is actually mitigated.

So you can do it automatically?

That's what we're—

I actually completely missed this particular update.

Right. Because it's a volume game, right? People just want to really reduce the volume. So, you know, okay, you should fix it maybe, but you don't need to fix it in the first 4 hours if you already have a mitigation in place, right? So that's the journey that we are on with our Eliminate capability is not just giving them a patch, which we already did, and we have millions of patches, but give multiple options and give them the context using AI to say, hey, we analyze your machine and you're not using this software. You know, actually, if you uninstall the software now, Every customer is different. They may choose to uninstall it. They may have a conversation with their IT team, and maybe that works for them. Others might say, I don't want to take the risk, and I want to use a different method. But our goal is to give you maximum number of options so you get to the final goal for the company, which is fixing the things that are causing the issue. And this is where, Anton, I've been talking about recently this concept of everybody talks about attack surface management. Right. Which is good. But what we really need to focus on is risk surface management. And I'll give an example of this, right? So if you have a house that has 50 doors and windows and you spend half a million dollars in installing a super high-tech system to protect every door, window, sensors, cameras, heat sensors, everything. After you're done with that, basically you realize that the only thing of value that could have been stolen in the house was $50,000 cash in a drawer. a tax surface fixing, you spent $500,000 when the risk of losing something was only $50,000. And that's where now you kind of need to say, well, part of what I need to focus on is also how much impact is it going to have negatively to my business, right? And so that's where the prioritization, CRQ, and some of these things are also now becoming part of vulnerability management focus is not that CRQ is in something in a silo. All of these things need to come together. And so today, you know, you ask somebody like, what's your posture view? People say, I have 10 products and you have top 10 dashboard from each product. But what does that mean to my wealth management business, which uses all of the capabilities, right? You cannot tell. So we play this, what I call as the vulnerability whack-a-mole, right? Like we all went through this nightmare of Log4Shell.

So before we get into that, I want to ask, One slightly different question and then we have to move to closing.

Yeah.

How has cloud fit into your future vision of this?

That's a great point. I think cloud has definitely created the problem of speed has become quicker and faster and complexity. But on the other hand, remediation has simplified in some cases because you don't have to fix every machine. You can actually patch the original image and then you can re-spin up, but that's where the mitigation capabilities are important because when a zero-day breaks out, you may not be able to rehydrate your machine and spin everything up in the 4 hours. So, first is to apply a mitigation, then second is to use patching on the base image. So, it just shifts. But the fact that if you have something that's running in the cloud or not, if it is exploitable, you are going to have the nation-state attackers immediately use AI and automation to start. And that's where it's imperative for the defenders to also use AI now in this world, right? Because I always say this, right? The vulnerability becomes a problem only when somebody finds it, because that's why we find something that's been in the code for 10 years. It was never an issue.

Wait, wait, wait, wait. Be a little careful here. If somebody finds it, yes. But if somebody on the bad guy side finds it and not tells you, it's still a problem, right?

Well, they count as somebody.

No, no, I know. But that's still somebody too, because you see like sudo, there was some code that has been there for 10 years. And the vulnerability is always there. It was never an issue. Nobody knew about it. But when it becomes— but so now if you have AI that is analyzing software, yeah, you can have bad guys are going to look at open source software out there to say, hey, can I just run AI on it to find out potentially more vulnerabilities now? So you have to be in an environment now where the risk operations center, and that's where we use agentic AI to also help you achieve tasks end to end so that, okay, you can prioritize it, you can focus on it.

But give us a use case with AI. I mean, we really, it's almost like the podcast would be invalid in '25 unless we ask about AI and agents. And you already have automated remediation to an extent. And of course, AI and other algorithms are used to judge what matters more for you. But can you run us through a few use cases that are real today in your platform and where AI helps VM? Absolutely.

I'll say that AI by itself is not enough. something that can run in a silo, right? Like, your AI needs an LLM, LLM needs to be run on, you know, your model has to be built on a large amount of dataset and everything. So I look at AI as something that is throughout the platform. It is not an add-on where it's only available in one place. And so, like, I gave the example of, hey, you could use AI to find newer vulnerabilities quicker. You can use AI to look— what are the attackers doing? They're a business, right? So they are also using AI to say, look, I have this huge attack surface. If I put all of this in in my LLM, can it tell me which has the highest possibility of success? They're using AI. So that's another case when you analyze your attack surface. Yeah, you might have thousands of things, but which have the highest possibility of a successful exploit? You can get to that. Again, when you look at patch management and mitigation, you can leverage AI to say which mitigations are the most likely to create the least amount of operational aspect. And then what is also happening, Anton, is that the simple things that you think are like simple for people is very complex. Like for example, Patch Tuesday, when it comes out, it is still a lot of process to go in and say, you know, did we scan, right? Is everything scanned? Was it scanned with the right version? Did we find the vulnerability? We apply it to a particular business context, and then are there exceptions to that? So what we have seen is where generative AI was good for asking questions, Mm-hmm. agentic AI has made these workflows truly end-to-end usable. And so the way we have approached this is while everybody says AI is embedded and it's magic and all of that, We made it a little bit different. We created a cyber risk agent marketplace in the product. And so what you do is you go in and you say, I have—

Wait a second. Wouldn't some of them be risky if somebody brings an agent, given that you can't scan an agent? Well, scan to sort of— I'm a little nervous about it. Like, bring your own agent to Qualys? No.

So with the marketplace, we are providing out-of-the-box expert agents today. So we have Agent Sarah, who is a Patch Tuesday expert agent. And so she can go and do all the tasks related to patches there. We have Agent Nova, who is an external attack surface management agent, and that agent is very good at figuring out what we need to do to manage my external attack surface, right? In the future, we plan to have customers build their own agent through the platform so that they might have very specific tasks. So the use of agentic AI is more about, again, getting speed and accuracy. So something that defender in your team, a human, could take 2 to 3 weeks to perform, could be done with a few hours end to end. And so the paradigm shift is really, as a security leader, I think of my team as 25 people who are coming in the office and 7 digital cyber risk agents that are part of my team. And these agents are going and continuously triaging certain things, and then the humans are bringing the additional intelligence. And then, so that's kind of how I envision the future with agentic AI is is that we can definitely beat the attackers back quicker, faster with the volume of vulnerabilities and the speed at which these are coming to us. So, I think we are seeing very exciting evolution of vulnerability management right now. And the risk operations center has been something that is resonating really well with our customers and everybody in the industry, just because look, at the end of the day, you've heard this a lot of time, CISOs go to the board and the board doesn't understand what the CISO is really trying to do. And 5 years ago, CISOs wanted to be in front of the board because they're like, what we do is important. They got their first board meeting and then they don't want to go back. They're like, wait, the board didn't get what I said. I didn't get what they were asking. But that's because the conversation has to shift in terms of saying that, look, our $500 million business unit has a potential of $10 million per day loss up to 7 days if there is a ransomware attack. Currently, based on all my tools and all my indicators, we are at a 75% possibility of that loss happening. I want to have a risk appetite. And when you talk about risk, you have 3 things: risk mitigation, risk acceptance, and risk transfer to cyber insurance. So that is the strategic conversation that a CISO needs to have at the board, not go and show how many CVEs.

Wait, wait, wait. So you can't have a button in Qualys that says, I'm not patching it, insure it. Wouldn't you want to build one?

Well, that's— so we just announced at the end of last year a partnership with a cyber insurance company where we're not quite there yet, but if you share the overall risk assessment with the insurance company, they're giving 15% discount on the premium of your cyber insurance because they are getting a lot more customers who have lower risk score. And so their chance of paying out is also going down. So I'm telling you, like, this is evolving into something very interesting and more strategic. And so as a CISO, you want to be able to say, my 2026 plan is not just to go and enable CyberArk encryption on my laptops. Your 2026 strategic plan is to reduce the number of things our teams are fixing. Because I always say, right, if you are asking your IT teams to fix things that are not important to the risk, you are just taking away from the business to do something more important. So we're reducing what we're fixing, we are getting more accurate, and by doing that, we are going to reduce the possibility. And this is the conversation CFO wants to have. Tell me giving you $300,000 is going to reduce the possibility of losing $10 million by 80%.

Then you will get the money.

If you just say, I want that.

I really want that as long as you're right. You better be correct when you do this is what my point is. Like, I want that tech.

You know, like, I think, look, I will say that we can only look at where we are in this point of time in the world, right? What we thought was a planet is apparently not a planet anymore. So all I can say is that at this point of time, it's an evolution journey. Even if we're not super accurate, even if we are in the overall ballpark to say this This is my biggest business, this is my smallest business, and we are able to focus accordingly and give that visibility. That's what the board wants to know, right? That the risk is in an acceptable level for my large loss. That's all they want to— they don't care about CVE or IAM or this or that. They just want to make sure that you have that. And that's, I think, the evolution and the journey that we are taking everybody on. And so that's why I hired Rich Syerson, who's the author of the book, How to Measure Anything. anything in cybersecurity because he's our Chief Risk Technology Officer. And he's been really working with the CISOs to say, forget all this like little thing. What's the strategic conversation that we need to have? How can the CISO become a partner to the business rather than just somebody who's like reporting on some metrics? And that metric may not mean anything because, you know, I had a call with the CISO the other day and they said, look, we were at 31,000 open vulnerabilities and then we went to 28,000. And then the board says, well, that's good, but what does that mean to the business? And I couldn't answer that, right? And so how do we evolve that so that whatever we do in terms of mitigation, risk acceptance, and risk transfer is really where we need to go as an industry rather than just, okay, I find more and more findings and I throw them over the fence to the IT team.

Okay. I really like that answer because I think that is really truly the highest level we can get to. of what vulnerability management becomes. I love that. I have to do the thing I hate doing, and I hate doing it extra when I've just said how much I love an answer, which is I have to ask our traditional closing questions. And so, do you have one tip maybe to help CISOs communicate to boards better? And 2, do you have recommended reading for our audience?

Yeah, I would say that my tip to CISOs specifically is that the first feeling you're going to have is CRQ is hard, but don't try to be perfect. Like at a high level, at least understand, because every company already has a risk management exercise that's not about cyber. Model your risk management based on that and start somewhere. And you don't have to be perfect. It's an evolution journey. So for CISOs, I'm going to say do that. My tip is really look up on the Risk Operations Center that we have. So we have a lot of material. Like I said, it's not a Qualys product, it's really the concept. And we are getting a lot of feedback on that. So if you go there, go to Qualys and, you know, you can read up. We have a couple of blogs on the Risk Operations Center. What are the components of a Risk Operations Center? How can you prepare a presentation that you can take to the board about what a Risk Operations Center is, what the outcome is? Like, we show that 65 million vulnerabilities after putting it through Risk Operations Center become 304,000 that really matter to your business. Like, that's the outcome you want to be able to show, right? It's not that you're showing I'm fixing 304,000. What you're showing is that I don't need to fix $60 million right now. That's the win, and that's the mindset shift that we need to have. And so, there's a lot of material out there on the risk operations center, and of course, Rich's book on cyber risk quantification is very high-level, but that's also interesting to read.

I love that answer. Anton, do you have any closing thoughts for us today?

No, no. It's actually a really good journey through what changed. At least it would make me not make too many '90s jokes about the EM, even though we know some companies haven't really gotten there. But I think you're making some of those tools much more accessible and some of the risk decisions much simpler. So, to me, that's— I don't want the just stick to highs, and I don't want the do what the compliance says. I do want the quote-unquote real risk.

Right.

And as long as we are getting there with business data, with asset values, with better asset awareness, I'm happy. I think that we can, and of course, automated remediation, which I did not believe in, and now I mostly do.

Yes.

I'll hedge a little bit. So, thank you for the journey for us.

Of course. Thank you very much for having me. And like I said, right, you know, 5 years ago, we had this idealistic vision that everybody was like, yeah, it would've been nice to have remediated automation, but nobody would do it. And we proved them wrong. And I think we're doing the same now, really, unlike other players in this space who are really a forward-looking approach of the ideal state where everybody needs to be in a couple of years and then working towards that. And so, I have no doubt that we're going to end up with a lot more people really thinking of vulnerability management and taking it as a much bigger business value conversation rather than, you know, kind of right now the frustration people feel with too many findings. And so, love having this conversation, you know, great questions, and always a pleasure talking to you, Anton and Tim.

Thanks for joining us. And now we are at time. Thank you very much for listening and of course for subscribing. Please subscribe so you can get new episodes piping hot. And if you love our content, please drop us a review on your platform of choice.

You can find this podcast on YouTube, Apple Podcasts, Spotify, or wherever you get your podcasts. Also, you can find us on our website, cloud.withgoogle.com/cloudsecurity/podcast. You can argue with us on the Google Cloud Security Community site, You can follow us on X, x.com/cloudsecpodcast.

Tweet at us, email us, argue with us, and if we like or hate what we hear, we can invite you to the next episode.

See you on the next episode of the Cloud Security Podcast by Google.