There’s a lot of noise around AI and cybersecurity right now. What’s actually important is far simpler, if often lost in the hubbub. Vulnerability discovery is getting faster and happening at a much greater scale, while defenders still have to work out which findings actually deserve their action.
In the first half of 2026, a whopping 35,853 CVEs were published, roughly 49% more than in the year before. Yet only 495 were catalogued as exploited in the wild during that same period, and 116 were already under attack on the day they became public. Meanwhile, Anthropic’s own disclosure data shows Mythos-class models surfacing 26,153 vulnerability candidates in open-source software, with only 421 of those getting patched upstream.
That small exploited subset is a very important point. It tells defenders that treating every vulnerability with a High or Critical CVSS rating as an emergency is not only impossible, it’s actually the wrong model. The critical task security teams face is deciding which exposures, on which assets, require immediate action, especially as both the number of findings grows and the gap between disclosure and exploitation narrows.
The CVSS Alone Can’t Tell You What Matters in Your Environment
The same CVE can affect hundreds of assets, but the impact is rarely the same across them. Some instances are unreachable. Some sit behind controls that interrupt the techniques required for exploitation. Others are exposed on business-critical systems where prevention fails, and detection never fires.
The CVSS gives you a common severity baseline. It can’t give you the context that determines impact to your organization.
This is why defenders need evidence from their own environment to find out whether the exposure is actually exploitable, which assets it affects, and whether those assets are reachable and important to the business. As vulnerability volume grows, this distinction becomes more and more important.
Automated Pentesting Alone Can’t Validate Every Exposure
Once you move beyond severity scores, automated pentesting gives you some of the strongest evidence you can gather. It can run real exploits, prove that an exposure is exploitable in your environment, chain vulnerabilities, credentials, and misconfigurations into attack paths, and show how far an attacker could actually progress across your network.
Yet coverage remains limited in practice. Omdia research found that while 95% of organizations rank pentesting as a top or high priority, only 32% of their average attack surface is tested each year. Agentic and automated approaches can expand that coverage, but they don’t remove every constraint of live exploitation.
For CVE-based exploitation, a working exploit still has to exist, and the target has to be safe to test. Newly disclosed CVEs may have no working exploit yet, while it simply may not be possible to test a live exploit on business-critical, restricted, and air-gapped assets. Those exposures still need an exploitability verdict, even when there’s nothing an automated pentest can safely run.
This is the gap automated pentesting can’t close on its own. It’s a required part of validation, but it can’t validate every exposure.
All for One. One for All Exposures.
This is where the pieces come together.
- Exploitability validation determines whether an exposure is, in fact, exploitable in your environment, including CVEs with no working exploit and assets that live exploitation can’t safely reach.
- Security control validation tests whether your prevention and detection controls actually block, detect, or miss the attack.
- Agentic pentesting safely runs real exploits and chains exposures to show how far an attacker can progress through your specific environment.
These methods answer different questions under different exposure conditions. Mythos readiness requires all three capabilities, brought together in one platform with the same goal: validating exposures across your unique environment. This doesn’t mean you have to always use all three against every exposure. The goal is to apply each method where it fits best and let the evidence contribute to the same decision process.
These three key pieces become even more powerful when they operate as one program. A finding can trigger the validation step it actually needs, new evidence can change remediation priority, and fixes can be re-validated instead of disappearing into a closed ticket. That keeps exploitability, control effectiveness, and attack-path evidence connected instead of leaving them to wallow in separate workflows.
This is also where Gartner®’s May research note points: toward validated attack paths, decision-driven response, and exposure reduction all integrated into operational workflows.
This also happens to be the working model behind our Validation Summit ’26.
What Security Experts See and How Leading Enterprises Put Validation Into Practice
On October 14 and 15, Picus Security will host The Validation Summit ’26 to bring together an independent view of what’s changed, our approach to validation, and lessons from security leaders who’ve already put it into practice.
Mikko Hyppönen will open with why this shift is different from past ones. Picus CTO Volkan Ertürk will then lay out what security validation needs to look like when attackers are powering their attacks with AI, and why exploitability validation, security control validation, and agentic pentesting work better together than on their own. The Picus team will then show the validation workflow live with a newly disclosed vulnerability. It starts with no patch and no working exploit, moves through validation before a PoC exists, tests the exploit against live controls once it appears, and then re-validates after the fix.
Then security leaders from Chanel, Atlassian, and the NFL will discuss what this looks like inside real enterprise environments: how mature security teams are adapting their validation programs, what they’ve changed, and the successes and failures they’ve experienced along the way.
Two hours. One validation blueprint. Join us for the Picus Validation Summit ’26.
Note: This article was written by Sila Ozeren Hacioglu, Security Research Engineer at Picus Security.
