Ask anyone who has spent a career patching security holes and they will tell you the same thing: fix one, and the ledger of what is still open does not get any shorter. Anthropic's frontier red team recently took a different approach. Rather than hunting for the next bug, it asked a different question — in this particular deployment, which pieces of code were reachable that should never have been reachable in the first place?
In a research post published on October 20 (https://www.anthropic.com/research/attack-surface-reduction), Anthropic calls this attack surface analysis and reduction, and ran it with Claude across 25 open-source projects spanning more than five million lines of code, in languages including C, C++, Java, PHP and Python. Claude built an inventory of more than 17,000 configuration options across those projects, of which 3,842 related to the configuration of a security-relevant control or feature. It ended up reporting 493 issues.
Three techniques, and none of them are bug hunting
The post draws an explicit line between finding vulnerabilities and reducing reachability: the former targets specific defects, while the latter lowers the severity of defects nobody has found yet.
The first technique looks at default configuration: code that is reachable out of the box but that no default functionality actually uses.
The second looks at configuration interaction: options that each look reasonable alone but break when combined. Claude found 162 security-sensitive combinations that were accepted with neither an error nor a warning, and with no documentation of the expected behaviour of their interaction. In 94 of those, the combination silently switched off a security control. The remaining 68 were inconsistencies inside the same mechanism — a listener or login path that stays reachable even though the configuration says it is disabled, for instance, or two settings whose precedence depends on their order in the configuration file.
The third looks at early reachability: security-sensitive, complex code that runs before an appropriate control (usually authentication), without victim interaction, or before a protocol state transition.
The most surprising cohort was the one that requires you to log in
Anthropic split the 25 projects into three categories: Public (10), built to serve anyone who can reach them; Gated (11), built to serve authenticated users; and Private (4), deployed for the operator's own environment. Logically, Public codebases should have plenty of reachable-by-default code, while Gated should be the reverse. Instead it was the Gated cohort that produced the most surprising results: 93 unnecessary pre-authentication surfaces in the default configuration, 37 locations where code executed or state was recorded before authentication, and 61 configuration combinations that silently weakened a pre-authentication control.
Two individual cases make the point even more sharply. One fail-open reverse-DNS pattern turned up independently in four unrelated projects: an administrator writes an access rule using a hostname or wildcard instead of an IP address, but reverse DNS lookups are configured off by default, so the server only ever has the IP. A hostname pattern can never match an IP address, so a deny rule never fires and the list fails open. Some projects document that hostname rules depend on DNS lookups being enabled, but none state that a deny list written this way would let traffic through. The other case was a certificate-check conflict: an option intended to delay verification actually disabled it entirely, so a server configured to accept only trusted clients would accept a connection from anyone. That conflicting pair of options had been present in the software for 21 years.
OpenSSH: the most heavily audited code in the world still leaked
By percentage of total lines of code, Anthropic says OpenSSH saw the largest attack surface reduction of the 25 projects. In the 10.4 release, Claude traced the input paths of the SSH daemon and found roughly 4,500 lines of new, experimental code for ML-DSA-44 — a post-quantum signature algorithm — that an unauthenticated client could reach under the default configuration. ML-DSA is not enabled by default, and the code stayed reachable even when an administrator explicitly excluded the algorithm: the daemon parsed whichever key type the client sent (and, for certificates, verified the embedded CA signature) before checking whether that type was allowed. Those 4,500 lines amount to about 16% of OpenSSH's own pre-authentication code in a default sshd.
Version 10.5 moved the check ahead of parsing. Claude then flagged two remaining gaps. The check inspected the algorithm name the client advertised, while the parser is chosen by a type string embedded inside the key blob — so a client could advertise ssh-ed25519, pass the check, and still send an ML-DSA key. And the certificate path was not gated: given a certificate supplied by an attacker, sshd would deserialize the embedded CA public key and run a full signature verification for any supported algorithm before consulting the configuration, exposing every public-key signature verifier in the binary. The eventual fix moved the checks inside the parser itself, comparing the encoded key type and the certificate's CA signature algorithm against the configured allowlists before the corresponding deserialization or signature verification. Anthropic says this removed roughly a fifth of the code an unauthenticated client could previously reach in a default build.
That part checks out against OpenSSH's own 10.6 release notes, which record the addition of checking key and CA signature types during key parsing against allowlists such as PubkeyAcceptedAlgorithms as early as possible, noting it reduces the attack surface presented by disabled algorithms. The notes credit Chris Rohlf in collaboration with Claude and Anthropic Research with the suggestion and extensive feedback (https://www.openssh.com/releasenotes.html). The same notes mention that the team has recently received a large number of security reports, many of them findings from AI models or made with AI assistance, and will therefore be releasing more frequently.
How to use it, and what I make of it
Anthropic packaged the techniques into a reusable Claude skill that it says it is working to integrate into OSS-Scanner, its opt-in vulnerability-finding service for open-source projects. The skill runs three passes over a codebase, each starting fresh in an empty context window except for a short piece of context inherited from the prior pass. Each pass builds an inventory of entry points and confirms every finding with a dynamic trace of the program. Changes to default configuration are gated: the skill runs the project's own test suite alongside a black-box regression suite and requires identical results, while anything that would alter a non-default configuration is set aside for a human to decide.
My read is that the value here is not "an AI found another N bugs" but the change of unit. The number 493 sounds unremarkable, and on its own it is very unlikely to constitute any security incident. What actually changed is the denominator of severity. When code as heavily audited as OpenSSH can ship with 4,500 lines of experimental parsing code reachable by default, then the quantity security teams have never been able to measure — the unknown vulnerability — finally gets an actionable proxy: you do not need to fix the bug, you only need to make the unreachable code unreachable.
That framing is especially practical for whoever runs production infrastructure and internal services. You may not need a bigger scanner. What you need is to know what your own deployment actually exposes. The post's suggestion of comparing runtime logs against configurations is the same idea extended: shutting down unused parsers, legacy protocols and empty dashboards costs very little and buys security directly.