The Chocolate Factory Problem

You know the episode where Lucy and Ethel get a job wrapping chocolates in a factory? At first the conveyor belt is going slow, easy peasy. But soon it speeds up and Lucy and Ethel start pulling the chocolates off the conveyor belt, making piles of the backlogged confections, trying to buy themselves enough time to catch up. But as many as they pull off the conveyor belt, more keep coming, and fast! Lucy starts stuffing chocolates in her blouse, hat, and mouth to try to keep up. You can't help but laugh at her squirrel-puffed cheeks and wide eyes. But you also feel for her, because simple as the task seemed, it's become impossible.

Every security team I talk to right now is living this episode. All I can think about is that conveyor belt.

The Belt Has Been Speeding Up for Years

For decades, cybersecurity operated with a built-in buffer, a window of time between when a vulnerability was discovered or disclosed and confirmed exploitation. That window (sometimes months, sometimes years) was where security teams lived: assessing, prioritizing, patching, moving on.

Two things are happening to that window, both at once. The first: the time from disclosure to active exploitation has collapsed. According to Mandiant's M-Trends report, what once took years now takes hours. Attackers are incorporating newly disclosed vulnerabilities into exploit tooling faster than most patch cycles can respond.

The second is less discussed but equally consequential: AI has made vulnerabilities much easier to find. On the HackerOne platform, vulnerability submissions increased 76 percent year over year in March 2026. And the mix is getting worse. The share of critical and high-severity findings has risen to 32 percent, up from a historical 26 to 28 percent. More volume, higher severity.

So the belt is moving faster and more chocolates are landing on it. Most vulnerability programs haven't adapted to either shift, let alone both. Programs built around patch cycles, sprint cadences, and quarterly reviews were designed for a world where discovery was slow and exploitation was slower. And as many chocolates as security teams stuff into their hats, shirts, and mouths, the backlog keeps growing and the belt keeps accelerating.

What a Pile of Chocolates Actually Costs

Every vulnerability sitting in a remediation queue is a known entry point: validated, documented, and unaddressed. The dashboard may look manageable and the board may see green, but findings that are logged and not fixed are live risk. The gap between the appearance of progress and actual progress is where organizations get hurt.

Each one of those unresolved findings is a door you know is unlocked and haven't gotten to reinforcing yet.

Most organizations will not fail because they lack visibility. They will fail because they cannot act fast enough on what they already know.

Where the System Breaks

Here's the idea that sounds like it should work: AI can discover vulnerabilities and AI can generate code, so connect the two things and the problem solves itself. It's a reasonable inference, but it's wrong. Coordination is the binding constraint, and AI doesn't solve coordination.

Cyber has shifted from a detection problem to an execution problem. Speed of action is now the decisive variable.

On discovery, AI has accelerated both sides equally. Both defenders and attackers can find vulnerabilities faster, and with lower expertise required. The advantage defenders once had in time to patch before exploitation is what's gone. 

On validation, meaning actually confirming whether something is exploitable in a real environment, defenders are gaining ground. That matters, because not everything on the belt is equally dangerous. On the HackerOne platform, roughly 25 percent of vulnerability submissions are valid and exploitable. That's a high signal rate, but it still means most findings need filtering before they're actionable. Without fast validation, teams treat everything like a five-alarm fire, burning cycles on things that can wait while real threats languish in the queue.

Validation tells you which chocolates to grab first.

Smart triage means asking: is this system internet-facing or sitting behind a firewall? Does it hold sensitive data? Are there other controls already in place that change the math? Threat intelligence about what's actively being exploited right now belongs in that calculation too, because a vulnerability that matches a live attack pattern is a genuinely different problem than one sitting dormant. Going fast on the wrong findings is just a different kind of backlog problem.

Past validation, the cycle stalls on something no model has solved yet: coordination. Walk through what actually happens after a vulnerability is confirmed as exploitable. First, you have to find the owner. Asset records are often incomplete, and the team that built the affected system may have reorganized, handed off the codebase, or simply lost track of it. Figuring out whose problem this is can take days and only then can a solution to the problem be reliably scoped. In many organizations, the longest delays occur after a vulnerability is identified but before it is owned.

Once you find the owner, they have to understand the vulnerability. The person who picks up the ticket probably didn't write the original code, so they have to reconstruct enough context to touch it safely, because a careless change in a complex system can create a new problem while fixing the original one.

Then, engineering has to prioritize fixing the vulnerability the security team identified. That's a tough tradeoff versus shipping features. A remediation task is an interruption to a roadmap someone already committed to, and the handoff between security and engineering is where urgency goes to die, quietly, in a backlog, measured in weeks.

One last snag: if it's packaged software, after the vendor patches and communicates it, every customer has to procure and deploy the fix. If the software lives inside a physical device (such as medical equipment, factory floor systems, network hardware, etc.) a patch may require planned downtime, hardware access, or regulatory approval before anyone can touch it.

The find-to-fix cycle looks clean on a diagram:

Discover > Validate > Identify ownership > Prioritize > Fix > Test > Deploy

But each arrow is a potential stall: a handoff, a gap in the org chart, a Slack message that went unanswered, an engineer on PTO. These are coordination problems baked into the structure of how organizations build and run technology, and they don't get faster just because the threat does.

That's the machine. Now here's how to explain why it's breaking to the people who need to fund fixing it.

What to Bring to Your Board

Board reporting on cyber has mostly been a coverage story: tools deployed, compliance boxes checked, posture benchmarked against peers. Those things still matter, but the conversation that's harder to have (and more urgent) is about time. The Exposure Velocity Model defines it through three variables that determine whether risk is compounding or being reduced:

Time to validate: How quickly does the organization determine whether a vulnerability is actually exploitable? Time to remediate: How long does it take for the exploitable findings to be fixed end-to-end? Exposure backlog trend: Is the volume of unresolved, validated vulnerabilities shrinking or growing?

Top-performing programs are approaching single-digit days for critical remediation. Most organizations are still measured in weeks or months. That gap is structural, not a performance issue.

Most boards aren't asking these questions yet, and most CISOs haven't pushed them there. If incidents tell you what went wrong, your backlog trends and remediation speed tell you what could go wrong in the very near future. How long the organization stays exposed after it knows it's vulnerable is the real number, and most boards have never been asked to look at it.

The Window to Start Is Now

If you don't know what assets you have and who owns them, that's your number one priority. It's simultaneously simple and overwhelming — tedious and time-consuming, but a thorough audit is the most important thing you can do right now. Without that clear view, everything in the find-to-fix cycle slows down. Get that clarity and SLAs have somewhere to land, escalation paths become real, and the handoff between security and engineering doesn't risk hitting a dead end.

You do not want to be figuring out who owns a problem while that problem is actively blowing up.

CISA, SANS, and OWASP call it VulnOps. It's the operating model that makes this work at scale: a permanent function modeled on what DevOps did for software delivery, built for continuous vulnerability discovery and remediation. A running system with ownership, triage discipline, and cycle time measurement built in from the start; not a tiger team spun up when something blows up. That timeline assumes starting now.

The trajectory isn't reversing. Nobody's turning down the dial. In a zero-time-to-exploit world, delay is the risk.