Qualys CISO on what security teams can do as exploit campaigns grow
In this Help Net Security interview, Nathan Smolenski, CISO at Qualys, talks about how security teams can handle the growing volume of AI-discovered vulnerabilities. He explains why CISOs should track the average window of exposure instead of standard MTTR, and why only a small share of disclosed flaws, under one percent in 2025, pose active risk.
Smolenski also covers how teams can build trust in autonomous remediation through asset tiering, human review, and rollback processes, and why automated fixes need reproducible evidence before anyone accepts them.
There’s a growing claim that AI will multiply the number of vulnerabilities and exposures security teams must deal with. Is that showing up yet in real telemetry, or is it still a forecast? Give me a number a CISO could use to size this before it lands on them.
The real world telemetry confirms this is not just a forecast; the shift in volume is visible in the data. Anthropic’s Glasswing reported more than 6,000 high or critical severity issues when it was used against 1,000 open-source software packages, and Mozilla found 22 issues in Firefox. This is a large number of issues, and a sizable percentage are rated as high severity or worse. According to FIRST, this year will see around 66,000 vulnerabilities reported.
The bigger challenge is not just the raw volume but the shift in quality, where AI discovered and validated vulnerabilities are more frequently leading to remote code execution. AI can move through different issues and link up multiple vulnerabilities that would otherwise all be rated as low severity, leading to exploitation. Managing this huge influx of CVEs and vulnerabilities will be important, but it is not the issue that CISOs should track.
The number to track is the gap between when a confirmed exploit is exposed in your specific environment, which could be a long time before discovery or disclosure, and when that issue is validated as patched or closed. This is not the same as the standard Mean Time To Remediate, or MTTR, where the clock starts at disclosure. Instead, this metric is the average window of exposure (AWE). Using this figure, you can point to very specific data around what issues matter to your organization, how those exploits represent business risk and how quickly they are remediated. Reporting AWE demonstrates how you concentrate on those problems that would get past your existing security processes.
When people talk about hyper-prioritization, autonomous remediation, and evidence-based detection, which of those is new, and which were good teams already doing under a different name?
Hyper-prioritization builds on your IT asset inventory and vulnerability data, your threat intelligence feeds and your risk decisions. Companies already have to prioritize what issues they fix first based on their specific business context or the level of risk that those issues represent to their unique IT infrastructure. Not all risk is created equal. What hyper-prioritization does is take that approach and turn it into real time decision making as opposed to monthly static spreadsheets – when you have a potential exploit in your infrastructure that is being targeted with automated, AI-powered attacks, you want to respond immediately. That can change in real time as new attack paths are discovered or combinations of exploits are chained together.
The evidence-based approach to risk is new for many teams but it really is an evolution to traditional risk based vulnerability management. They are used to making decisions based on general risk scores like CVSS and some limited risk factors, not based on what the specific risk is to the applications that run their business and what specific issues they have that are being targeted for exploitation. By putting a context-rich business case against each risk and updating that figure in real time, you can decide where to put the most effort to prevent the most potential financial loss.
Teams should focus on the small slice of findings that carry real business risk. In practice, how small is that slice, and when an automated system decides a vulnerability is not worth fixing, who carries the accountability if that call is wrong and it gets exploited?
In the latest Qualys Threat Research Unit (TRU) research paper, we looked at the tens of thousands of security issues that were discovered, and how many of them were actively at risk, weaponized and targeted by threat actors. There were 48,172 vulnerabilities disclosed in 2025 – of those, TRU identified 357 that were both remotely exploitable and actively weaponized. That is 0.74 percent of the overall total. That makes it much easier to focus on specific issues that represent an active risk.
However, the situation around potential issues will change all the time. As new issues get found, a past vulnerability that was previously discounted because exploitation relied on specific conditions might suddenly become an issue that is more critical to remediate. For example, a code execution problem is serious, but if the attacker needs local privileges and machine access to use that vulnerability, it is a more difficult one to exploit. Then a new issue comes up that affects privilege levels and bridges that gap – suddenly, those exploits can be chained together for a remote code execution that is much more risky.
That real time update to threat intelligence is therefore critical. You want to know when situations and circumstances change, and where those exploits become possible, so that you can make changes to your prioritization and remediation plans as needed to keep up with evolving risks. Responsibility for these decisions always remains with the company, so keeping that data up to date and relevant is important.
Autonomous remediation is the idea that makes seasoned admins nervous because patching breaks things. Walk me through the trust mechanism: can a team run it supervised first, what does rollback look like, and where would you tell someone never to let it run unattended?
Autonomous remediation has existed for several years, but getting teams to adopt this has been difficult. For many of them, they have seen the issues that a failed patch can cause, and they don’t want to create that kind of problem in their operations in future. It can be a career-limiting decision.
One fallacy here is that automated patching is an all or nothing approach. Using asset tiering, you can roll out patches to assets that are low risk. Once the patch is in place, you can then look at rolling out to the next tier of assets, and so on. This ensures that standard patches can be deployed on assets that are not mission-critical, so that they can be checked for potential problems before they are rolled out to everybody. Human in the loop guardrails are another way to ensure that, in initial phases, the automation does the packaging or configuration change and stages them for a human to review and approve next steps.
This frees up time for your team to work on those issues that are more difficult to deploy, or that are on mission-critical systems that need to be tested more thoroughly. You can also free up time by carrying out patchless mitigations or using virtual patching on applications to prevent exploits while you prepare the patch.
One of the ways to build trust is how you can use AI to test patches for reliability and check for potential problems before deployment, and to create rollback processes. Carrying those out effectively reduces the potential risk. In the past year, we rolled out more than 150 million patches and 40 million of them were fully autonomous – the roll-back rate was less than 0.1 percent.
This work is necessary. The speed is necessary. And trying to apply human labor faster is not going to be enough to keep up with attempts at exploits or with regulations being brought in. In the US Federal space, BOD 26-04 was announced in June and it enforces that federal agencies must patch specific critical issues within three days, with the addition of performing forensic triage. Deploying patches at that scale is hard, but the timescales are non-negotiable, they have to be met. It is possible to deliver on that deadline effectively, and in a repeatable way, but the approach needs to be different.
Cutting noise is a goal everyone shares, but AI systems generate their own confident-sounding noise. How do you stop an automated remediation layer from becoming one more source of false certainty that teams then have to audit by hand?
Getting to what is important is the goal for security. We don’t want to harden systems for their own sake, but because they support the specific business goals or objectives that are essential to the organization.
Reducing the amount of noise around issues is a first step. As an example, we had one customer that had more than 62.5 million security alerts and event data entries from Qualys and other third-party sources. We helped that organization filter through that by focusing only on CISA KEV data – this cut the data coming through by 94 percent, leaving 2.17million alerts. After this, Qualys looked at areas like asset context and how important that asset is to the business, which reduced the count to 304,000 alerts. Lastly, we ran an exercise to test exploitability using safe payloads, validating which of these issues were exploitable and therefore the highest priority. This cut the number of issues down to around 60,000, less than 0.1 percent of the original figure.
At the end of the day we have to decouple what the AI capability suggests and the validation of its suggestion. Additionally, it’s critical to require reproducible evidence from any AI / automation process to ensure that there is human-verifiable telemetry confirming a fix. This validation approach is essential for teams that have so many issues to track and manage. Avoiding the noise around AI and focusing on real, practical and repeatable processes and outcomes for security is the only way that teams can deliver what the business needs.
