COMMENTARY: Over the decades I’ve spent working in offensive security, I’ve never met an organization that considered itself comfortably ahead of its patching cycle.
Teams were almost always behind because they couldn't establish quickly enough which findings were real in their environment, which ones an attacker could reach, which assets were impacted by legitimate findings, who owned these assets, and who was responsible for fixing them.
[SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Read more Perspectives here.]
In a sort of domino effect, the queue grew faster than anyone could qualify. So, remediation was never a patching capacity problem. It was always a validation issue.
It’s important to note that history, because the industry has drawn a similar wrong conclusion from what frontier models have done to vulnerability discovery over the last 18 months.
What AI actually changed
Frontier models have made vulnerability discovery dramatically faster. A model that writes code well reads it just as well and can explain why a flaw matters rather than just flagging that something “looks” wrong. That capability now covers the same ground an attacker covers: source code, cloud configuration, infrastructure, dependencies. We genuinely find more real issues, and find them earlier, than we were two years ago.
With that said, discovery was the half of the lifecycle that was already working well enough, and it was never what kept organizations behind. The half that was broken was validation. That's the part that determines whether a finding matters and warrants a fix -- and quite honestly, validation did not improve with frontier AI models. AI made the cheap half cheaper and left the expensive half exactly where it was.
Understandably, the market looked at all this and concluded that enterprises are now far more exposed than they were a year ago: more findings, more exposure, more risk. I'd argue that’s an incorrect framing. It mistakes a rise in findings for a rise in risk, and acting on it will send a lot of 2027 budget to the wrong place.
A finding is not an exposure
The framing I just made assumes that discovering a vulnerability and having an exploitable one that impacts a critical asset are the same event. In reality, they rarely are, and the gap between them is where nearly all of the difficult work still sits.
Take a code review that surfaces a flaw in a widely-deployed productivity application, the kind already installed across thousands of organizations. More than 40,000 CVEs were published last year, while CISA's catalog of flaws confirmed exploited in the wild holds roughly 1,300 accumulated since 2021.
While a vulnerability discovery may be a legitimate finding, nothing changes for any of those organizations until it means something in the context of their environment.
That context requires a set of questions only they can answer. Does the bug exist in the version and configuration they happen to run? Could an attacker reach it given how they've deployed the application, and what controls sit in front of it? Which assets does it touch, and which team owns them?
Only once those are settled does a developer have something they can act on. Only then does a team have enough confidence to rank that finding against everything else in the queue and give it a place in the schedule.
Consider what happens when a finding like that reaches the team that owns the code without those questions answered. We tend to respond with some version of: Is this actually reachable in our setup?
If nobody can answer it, the developer has to weigh a maybe against work already committed for the quarter, and the maybe gets pushed aside. Some may call it negligence, but it's the technically correct decision with the information available. Every unqualified finding gets triaged the same way, which means the queue can grow indefinitely without a single additional fix coming out the other end.
Discovery happens once, and the whole industry gets it. Validation happens separately inside every organization running the software, and none of it transfers.
Breaches happen in this gap. If we read the postmortem of almost any significant compromise, they follow a similar trajectory. The vulnerability had been published, the vendor patch shipped, and the finding was already sitting somewhere in the organization's own scan output. While nobody was necessarily “in the dark” about it, the finding simply never rose to the top of a list with thousands of other entries on it, because nobody could qualify those entries fast enough to know that this one belonged there.
Most organizations write these incidents up as patching failures, then spend the remediation budget on more automation and tighter change windows instead of on the ability to tell which patch mattered in the first place. That misdiagnosis shows up in the market. Some organizations saw through it and invested in validation, mostly those that had already concluded they would never patch their way out of the backlog.
Look at the Gartner Hype Cycle for Security Operations: adversarial exposure validation (AEV) sits roughly a decade from mainstream adoption and Pentesting-as-a-Service (PTaaS) two-to-five years out. For a category that addresses the industry's binding constraint, those are early timelines. The organizations investing in AEV technologies now, especially autonomous penetration testing tools that offer much-needed continuous validation, are moving well ahead of the market.
So, if validation has become the constraint, the planning question changes. Instead of asking how many more findings a new tool will surface, ask how many of the findings already sitting in the backlog the organization can currently qualify in a week. Most security leaders I talk to about this for the first time don't have a way to measure it. Their tooling counts findings and tracks patch completion, but can’t report how many findings the team can move from unqualified to assigned in a week. That figure, rather than the size of the backlog, determines how much risk the program actually retires in a year.
That number also changes how the conversation goes with the board. A report showing findings went up sharply this quarter gives them nothing to act on. A report showing the organization validates 100 findings a month, needs to validate 400, and can close that gap for a specific figure represents a different kind of document. The first is an observation. The second, a resourcing decision with a number attached to it, and we can frame it as a reasonable ask that gets approved.
For years, programs had a reasonable defense for an unqualified backlog, which was that nobody could find everything anyway. Discovery was the expensive part of the lifecycle, so a queue full of findings no one had gotten to looked like an unavoidable cost of doing business, but that defense has disappeared. Discovery gets cheaper every quarter, and an unqualified backlog now reflects a decision about where the budget went.
Look at what a CISO actually gets asked in a board meeting: the questions are which assets are at risk, whether an attacker can reach them, and who will fix them by when. Better discovery leaves all three unanswered. Validation answers them, and the organizations building that capability now will spend the next few years fixing the right bugs while everyone else works through a longer list.
Seemant Sehgal, chief executive officer, BreachLock
SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Each contribution has a goal of bringing a unique voice to important cybersecurity topics. Content strives to be of the highest quality, objective and non-commercial.
