The catalogue is not the boundary of the attack surface

Most vulnerability management rests on a quiet assumption: that the weaknesses worth worrying about will be catalogued before they are used against you. Somebody finds the flaw, it gets an identifier, the feed picks it up, your tooling matches it, you patch. The process works, and it has made the industry meaningfully safer.

It also describes a strictly delayed view of what an attacker knows. Worth being precise about where the delay comes from, because it is not a flaw in the system. It is the system working as designed.

Identifiers are assigned last, not first

Anthropic runs a coordinated vulnerability disclosure programme for weaknesses Claude finds in widely used open-source software. It is a useful thing to read closely, because it publishes its own pipeline rather than only its results.

The order of operations goes: a candidate finding is produced, external security firms triage and confirm it, maintainers are notified privately and given time to fix, and CVE or GitHub Security Advisory identifiers are assigned once the disclosure window closes. Anthropic's own documentation notes that identifiers are listed only after that point, and that not every finding necessarily receives one.

The weakness existed, and was findable, before it had an identifier. Anything relying on the catalogue was blind to it the whole time.

That is not a criticism of coordinated disclosure. Private notification and a patch window are exactly right. Publishing a working flaw before maintainers can fix it would be worse for everyone. But the necessary consequence is that the catalogue always trails discovery, and a defensive model built only on the catalogue inherits that lag by construction.

AI shortens the window on one side only

What changes when a model can reason over a large codebase and surface previously unknown weaknesses is not the existence of the lag. It is the rate at which findings enter the pipeline, and the assumption that discovery is scarce.

Security programs have historically been able to treat undiscovered vulnerabilities as a small, slow-moving residual: real, but not something a defender could act on. When capable discovery becomes cheaper and faster, that residual stops being negligible, and it becomes harder to argue that being current with known issues is the same thing as being defensible.

The honest reading is not that patching stopped mattering. It is that patch currency was always a proxy measure, and proxies get less useful as the thing they stand in for changes shape.

Most of what an attacker uses never had an identifier

There is a second problem, and it is larger in practice than undiscovered software flaws. A great deal of what an attacker actually exploits was never a candidate for a CVE, because it is not a software defect at all.

• An authorization check that returns another customer's record when the identifier changes
• A credential in a repository that still authenticates
• An OAuth grant that keeps working after the password reset that was supposed to contain the incident
• A SaaS permission broader than the role requires, reaching data nobody audited
• A checkout workflow that trusts a value the client controls
• An AI feature that follows instructions hidden in a document it was asked to summarize

None of those has a version number to compare against a database. They are properties of one environment, arising from how its applications, identities, permissions and models interact. There is no feed that will tell you about yours.

What replaces the proxy

If patch currency is a proxy for defensibility, the thing it stands in for is straightforward, if harder to measure: whether an adversary can reach anything that matters, in the environment as it is configured today.

That question can only be answered by trying. Not by inventory, and not by severity scores attached to weaknesses whose reachability nobody established. It means attempting the attack inside authorized scope, keeping the evidence of what succeeded, ranking by what became reachable rather than by label, and re-running the attack after the fix to find out whether the exposure is actually gone.

Keep the scanner. Broad, deterministic coverage of known weaknesses is genuinely valuable, and removing it would make a security program weaker rather than sharper. The argument here is not that catalogued vulnerabilities stopped mattering. It is that the catalogue was never the edge of the attack surface, and it is becoming a less adequate stand-in for one.

The attacker never asked whether a weakness had an identifier. They asked whether it worked. Eventually the security program has to answer the same question.