NCSC's quiet 'go slow' on AI vulnerability finding

NCSC’s Vulnerability Management Group lead, Ruth C, published a blog post on 11 May 2026 titled 10 questions to ask when using AI models to find vulnerabilities. The post is short, calmly worded, and entirely in the NCSC house style — brief paragraphs, no marketing, the polite institutional shrug of an agency that has watched a lot of technology cycles. Read at face value, it is a checklist. Read as a piece of institutional signalling, it is the politest possible “go slow” memo NCSC could have written to UK boards, vendors and CISOs being pushed to “do something with AI” by the people above them.

The questions themselves are unsurprising. What are you trying to achieve. Is AI even the right tool. Do you have a vulnerability management process. How will you prioritise. What are the security risks of the AI tooling itself. Which model. Where do you start. What is the long-term plan. Where do you invest in people. Do you understand your patching regime. The framing is operational, not technical: NCSC is not telling readers how to use AI for vulnerability discovery, it is asking them whether they have any business doing so before the basics are in place.

One number in the post is doing most of the structural work. In 2025, around 40,000 CVEs were assigned. CISA’s Known Exploited Vulnerabilities catalogue tracked about 400 as actually exploited against real targets. Of those, approximately 40 were zero-days at first contact — i.e. exploited before a patch existed. That puts the ratio of “vulnerabilities catalogued” to “vulnerabilities ever used against anyone” at roughly 100 to 1, and the ratio of catalogued vulnerabilities to genuine zero-day pressure at 1,000 to 1. Most vulnerabilities, in other words, never become anybody’s problem.

The implication is the point of the post. AI models — including the current generation of frontier models marketed at developer and security workflows — accelerate vulnerability discovery. They do not accelerate remediation. If an organisation already cannot deploy the patches it has for the vulnerabilities it already knows about, plugging an AI into its codebase makes the situation worse, not better. The dashboard gets louder, the backlog gets longer, the blast radius does not change. The board sees a higher count of “vulnerabilities found.” The attackers, meanwhile, continue to use the same hundred or so issues that were already exploitable last week.

NCSC’s earlier blog on the “vulnerability patch wave” sits directly behind this post and is referenced inside it. That piece argues that AI-accelerated discovery is going to drive a surge in disclosed CVEs over the next two to three years and that organisations need to prepare their patching cadence now, not later. The two posts read as parts of the same argument. The May piece is the operational checklist; the earlier piece is the structural warning.

A note on what the post deliberately does not say. NCSC is silent on which AI models it considers fit for purpose, silent on hosted-versus-on-premise tradeoffs beyond a general nudge towards considering jurisdiction, and silent on attribution of any specific vendor offering. That is consistent with the NCSC editorial line and with its statutory remit; it is not an omission. The agency’s position is repeatedly that experience — start with any model, build the muscle, evaluate against your own attack surface — matters more than the specific frontier model chosen.

The bit not in the post that defenders should add for themselves is the segmentation lens. The reason remediation is structurally the bottleneck for most organisations is that vulnerability management has been treated as a discovery-and-patch programme, full stop, for two decades. The silent compensating control when patching cannot keep pace is containment: reducing the blast radius of any one compromised host or identity so that the unpatched vulnerability is materially harder to use. Identity-tier isolation, network segmentation, egress posture, administrative-plane separation — these are the controls that buy time when the patch programme is behind. AI does not change that calculus. It is more likely to expose it: the discovery volume will rise faster than any remediation pipeline can keep pace with, and the only sane response is to make the unpatched-but-not-yet-exploited window survivable by design rather than by luck.

Two questions worth adding to NCSC’s ten, in the order I would ask them.

First, “What does it cost to operate AI vulnerability discovery at scale, and would the same budget improve our patching cadence by more than the AI improves our discovery?” For most organisations the honest answer is that the patching cadence is the cheaper, higher-yield investment. For some — large product vendors, critical infrastructure operators with code obligations, regulated software providers shipping to the financial sector — AI-aided discovery is genuinely additive. The question is which of those an organisation is, and most boards do not ask it.

Second, “If we believe AI-accelerated discovery is going to drive a patch wave, what does our containment posture look like during the eighteen months it takes our remediation programme to scale?” This is the question UK financial-services CISOs in particular should be answering for their boards now. PRA, FCA Operational Resilience and DORA are not going to wait for the patching cadence to catch up. The compensating-control conversation belongs in the board pack before the discovery-volume conversation does.

What’s useful about the NCSC post in the meantime is precisely that it does not buy the framing it has been handed. The institutional answer to “should I use AI to find vulnerabilities?” is, calmly: yes, eventually, and probably less ambitiously than you think, and only after you can answer ten basic questions about whether you can do anything with the answer. That is a useful framing for any organisation currently being asked by its board how many vulnerabilities the AI has found this quarter. The honest answer to that question is almost always the wrong one.