Attackers have a working exploit ready in a median of three days after a vulnerability is published. The typical enterprise takes between sixty and one hundred fifty days to patch it.
That gap is not a story about lazy security teams or under-funded IT departments. It is a structural condition, shaped by three forces pulling in the same direction: AI is accelerating how fast attackers weaponise flaws, the security workforce is short on the specific skills that matter rather than just short on bodies, and the tools most enterprises run were built for a slower era. For anyone evaluating or invested in cybersecurity companies, that convergence matters commercially, because the sector’s newest products are now organised entirely around closing this window.
Here is the practical use of what follows: a working lens for judging whether a security vendor’s AI claims address the real structural problem or quietly route around it. The data below is the foundation. The evaluation framework is the payoff.
The five-day window that makes enterprise patching irrelevant
Start with the sequence, because the compression only lands when you watch it happen milestone by milestone.
A vulnerability is published. According to Tenable’s April 2026 research, a functional exploit is available in a median of three days. Active exploitation, the point at which attackers are using that exploit against live systems, follows at a median of five days.
The number that reframes everything A functional exploit is available in a median of just three days after a CVE is published (Tenable, April 2026).
Now layer in what defenders actually see. Tenable found an average 15.2-day delay between a vulnerability’s initial disclosure and its publication in the National Vulnerability Database (NVD), the feed many security teams treat as their primary source. Inclusion in Tenable’s own Known Exploited Vulnerabilities list averages 42 days; inclusion in CISA’s KEV catalog averages 50 days.
Read those two timelines against each other and the problem becomes visible. Attackers are live in five days. Defenders relying on official feeds have not even heard of the vulnerability for more than two weeks.
| Milestone | Party | Timeframe |
|---|---|---|
| Functional exploit available | Attacker | 3 days (median) |
| Active exploitation begins | Attacker | 5 days (median) |
| NVD publication of vulnerability | Defender feed | 15.2 days (average) |
| Tenable KEV inclusion | Defender feed | 42 days (average) |
| CISA KEV inclusion | Defender feed | 50 days (average) |
| Typical enterprise patch cycle | Defender | 60-150 days |
That 60-150 day patch cycle, which Corelight cites as the enterprise norm, is not negligence. It was a rational process, calibrated for a threat environment where weeks of lead time existed. That environment is gone.
The offence-defence asymmetry extends beyond patching cycles: Palo Alto Networks’ internal AI scan compressed five to seven years of conventional vulnerability discovery into six weeks, setting a new baseline for enterprise exposure that legacy tooling was not designed to address.
What this tells you is uncomfortable: any security strategy built around reactive patching is structurally compromised, no matter how disciplined the patching programme is. You cannot patch faster than you can learn a vulnerability exists, and the official feeds are already two weeks behind.
Corelight warns the compression has a next stage. With advanced “Mythos-class” AI models, attackers could begin exploiting flaws before formal disclosure, collapsing the zero-day window toward zero. That is not a speculative future. It is the direction the timeline is already travelling.
When big ASX news breaks, our subscribers know first
Why SOC teams cannot simply hire their way out of this problem
The obvious response is to hire. Build a bigger security operations centre, staff up the analyst bench, and outnumber the threat. That answer is wrong, and the reason it is wrong reveals what the problem actually is.
ISC2’s 2025 Cybersecurity Workforce Study, published in December 2025, made a deliberate shift in framing. It stopped leading with a global headcount gap and started leading with skills, because skills shortages now eclipse staff shortages as the primary constraint.
The data behind that shift is stark:
- 59% of organisations reported critical or significant skills shortages, up from 44% the prior year, a 15-point jump in a single year.
- 88% experienced at least one significant cybersecurity event attributable to those skills shortages; 69% reported more than one.
- 33% said they lack the resources to adequately staff their teams, and 29% said they cannot afford staff with the skills they need.
For context, Fortinet’s 2025 Skills Gap Report, citing ISC2’s 2024 figures, put the global workforce shortfall at more than 4.7 million professionals. The headcount gap is real. But the ISC2 2025 data says the sharper edge is composition, not count.
That 15-point jump matters more than any single figure. It tells you the skills problem is accelerating, not stabilising. Security teams that have not already invested in AI-augmented workflows are not treading water; they are falling further behind each year.
AI-powered cyberattacks have already moved from theoretical to demonstrated: a three-person team using Claude Opus 5 moved from reconnaissance to a working exploit inside OpenAI’s code repositories in under 72 hours, and OpenAI’s own autonomous agents remained undetected inside Hugging Face’s production infrastructure for approximately two months.
There is a direct commercial read here for anyone assessing cybersecurity vendors. Products that reduce the expertise required to operate them address a real and worsening organisational constraint. Products that demand scarce, specialist analyst skills to function face a hard adoption ceiling, regardless of how capable they are on paper.
The two operational barriers that AI adoption cannot survive
Corelight identifies two specific skill deficits inside SOCs that compound everything above, and they are not vague “cyber skills” gaps. They are precise operational barriers.
The first is a network expertise gap. An analyst without network forensics knowledge cannot frame an effective investigation, because they do not know what to look for or how the evidence connects.
The second is a query language expertise gap. Even an analyst who knows what to investigate cannot retrieve the evidence if they cannot write the complex queries the tools demand.
Together these explain why tooling complexity, not just talent scarcity, is the proximate cause of slow AI adoption inside SOCs. The tools exist. The people who could use them cannot always drive them.
What AI-native SOC tooling actually looks like in practice
To evaluate the category, you need to see how it differs from the SIEM and SOAR tools most SOCs already run. Corelight’s September 2026 release is a useful illustration, not because it is the only option, but because it makes the category’s design choices concrete.
The release, announced on 15 September 2026, centres on two capabilities: Natural Language Query (NLQ) and the Agent Builder Library (ABL). The difference from traditional automation sits in one dimension above all others.
| Dimension | Traditional SOAR/SIEM | AI-native agentic tooling |
|---|---|---|
| Investigation logic | Static, predefined playbooks | Dynamic, agent-planned |
| Query interface | Query syntax required | Natural language |
| Reasoning transparency | Opaque | Chain-of-thought visible |
| Environment support | Cloud-oriented | Air-gap capable |
That contrast between static and dynamic investigation logic is the whole point. Fixed playbooks execute the same sequence against the same conditions. Against threats moving at AI-accelerated speed, static logic breaks the moment the attack does something the playbook did not anticipate.
Natural Language Query and the query syntax barrier
Remember the query language expertise gap from the previous section. NLQ is the direct answer to it.
An analyst asks a question in plain English. Orchestrated AI sub-agents translate it into a LogScale Query Language query, run it against data already collected in the Investigator platform, and return the result. The agent is context-aware, mapping a phrase like “connections” to the correct log type without the analyst knowing the schema.
The control features are where the design intent shows. The generated query is editable, the full chain-of-thought reasoning is visible, and Corelight validates each query before it runs against live network data.
That validation and editability is not a limitation of the AI. It is a deliberate architectural choice that tells you this category is built for environments where analysts must be able to explain and defend every investigative step. In a regulated or accountability-heavy SOC, an unexplainable query is a liability, not a feature.
Agent Builder Library and the codification of investigative knowledge
ABL answers the other barrier, the network expertise gap, by codifying expert investigation logic into portable artifacts.
The knowledge-codification ambition Corelight describes ABL as capturing over a decade of network forensics expertise into structured, exportable artifacts: triage playbooks, investigation decision trees, entity pivoting guides, and field explanations.
The underlying logic is deterministic and documented, not probabilistic. And the artifacts are exportable, which means they run in air-gapped and classified environments where cloud-connected AI is not viable. For government, critical infrastructure, and defence buyers, that offline capability is a genuine differentiator, not a checkbox.
The release also expands detection to cover AI supply-chain compromise, anomalous AI behaviour, and command-and-control or exfiltration activity from AI systems. The threats are shifting toward AI itself, and the detection surface is following.
The detection surface expansion Corelight targets reflects a broader shift in AI agent security: as enterprises deploy authorised AI agents at scale, the behavioural signatures of legitimate automation and malicious attack scripts converge at the network level, creating a classification problem that binary block-all-automation logic cannot resolve.
How defenders can close the gap when the tooling alone is not enough
Knowing the problem is not the same as knowing your own exposure. The value here is prioritisation logic, because the order in which you address these constraints matters as much as addressing them at all.
The convergence that defeats single fixes A 15.2-day NVD lag, a three-day exploit window, and a 59% critical skills shortage rate are three simultaneous constraints. No single intervention closes the gap.
Here is the prioritised sequence:
- Fix intelligence speed first. The combined blind spot of a 15.2-day NVD delay and a three-day exploit window means official feeds cannot be your primary source. Supplement NVD and CISA KEV catalogs with faster vendor-driven or proprietary exploit intelligence, and re-prioritise by active exploitation likelihood rather than treating every disclosed flaw equally.
- Reduce tooling complexity second. With 59% of organisations reporting critical skills shortages as the baseline you are working within, tools that require specialist skill to operate will stall. Agentic triage, as Corelight frames it, exists to absorb repetitive SOC task volume so scarce analysts spend time where judgment is needed.
- Address skills composition third, through the tooling itself. Natural-language interfaces and codified playbooks let existing analysts operate more effectively without waiting for hiring or training cycles to catch up.
That order is deliberate. Faster intelligence is worthless if your team cannot act on it, and better tools are worthless if your analysts cannot drive them.
The commercial read closes the loop. The vendors worth evaluating are those whose product design directly reduces the expertise barrier, rather than those requiring your analysts to first become AI practitioners. When assessing any solution, the question is whether it addresses all three constraints at once, or optimises for only one and leaves the others open.
What the asymmetry tells you before the next CVE drops
Pull the three constraints together and a single conclusion holds: the organisations closing this gap are not the ones with the biggest security budgets. They are the ones that correctly diagnosed which constraint to address first.
Exploitation speed, skills composition, and tooling complexity are one connected problem. Money spent on any one of them, absent a view of the other two, buys less than it appears to.
The forward risk sharpens the point. Corelight’s pre-disclosure exploitation scenario, driven by Mythos-class AI models, would compress reaction windows further and turn today’s AI-native tooling from a differentiator into a baseline requirement. What is an edge now becomes table stakes soon.
The timing is the whole argument. Critical skills shortages jumped 15 points in a single year while exploitation timelines kept compressing. The window for deliberate AI adoption is narrowing, and the organisations that move now are setting the floor everyone else will be measured against.
For buyers and investors, that is where the value accrues. Look for products that solve the expertise barrier at the tooling level, defined by these principles:
- Chain-of-thought transparency, so every investigative step is explainable.
- Editable, validated outputs, so analysts retain control.
- Deterministic, documented playbooks, not opaque probabilistic logic.
- Air-gap and offline support, for restricted and regulated environments.
Solutions that require headcount or skills acquisition before adoption are solving the wrong problem in the wrong order.
For investors wanting to understand how AI pre-disclosure detection works operationally, our full explainer on pre-disclosure AI detection at scale covers Anthropic’s Project Glasswing, which identified more than 10,000 high-severity vulnerabilities before public disclosure, and examines what that capability means for vendor differentiation.
This article is for informational purposes only and should not be considered financial advice. Investors should conduct their own research and consult with financial professionals before making investment decisions. These statements are speculative and subject to change based on market developments and company performance.

