Generated by Codex with GPT 5.6 Sol High

Techmeme surfaced Anthropic’s October 20 report, “Using Claude to reduce the attack surface of code”. Most AI-security work asks a model to find individual vulnerabilities. Anthropic tested a different strategy: map which code an attacker can reach, then move unnecessary functionality behind authentication, configuration checks, user actions, or later protocol stages. The point is not to prove the code bug-free. It is to make unknown bugs harder to reach before anyone knows they exist.

That shift matters because vulnerability discovery is an endless search over an unknown population. Fixing one severe flaw says little about what remains. Reducing reachability changes the exposure of whole classes of undiscovered flaws at once. Anthropic reports that Claude examined 25 open-source projects containing more than five million lines of C, C++, Java, PHP, and Python, inventoried over 17,000 configuration options, and identified 493 attack-surface issues.

The headline number needs careful interpretation. These were not 493 independently exploitable vulnerabilities. Many were unnecessary pre-authentication paths, ambiguous configuration interactions, or code that ran earlier than intended. Anthropic’s more interesting claim is methodological: a model can trace large systems deeply enough to find mismatches between their intended security boundaries and their actual runtime behavior, then propose narrowly testable changes.

Security lives in reachability

The work focused on three recurring failure modes. First, a default installation could expose code that no default feature actually needed. Second, two individually reasonable settings could interact in a way that silently weakened a security control. Third, complex code could run before authentication, before user interaction, or before a protocol reached the state in which that code belonged.

Those categories capture a common software problem. Features and abstractions accumulate over years, but the checks that govern them do not always move with them. A service may eventually reject an operation, yet still parse attacker-controlled data or perform expensive cryptographic work before consulting the relevant allowlist. A disabled feature can therefore remain part of the practical attack surface even though an administrator reasonably believes it is off.

Anthropic divided the projects into ten public services, eleven gated services intended to expose functionality only after authentication, and four private systems. All eleven gated projects contained some code that was unintentionally reachable. In that cohort, Claude found 93 unnecessary pre-authentication surfaces in default configurations, 37 places where code executed or state was recorded before authentication, and 61 configuration combinations that weakened a pre-authentication control. Anthropic says none of those findings was immediately exploitable on its own, an important distinction between dangerous exposure and a finished attack.

Configuration interactions produced some of the sharpest results across all project types. Claude identified 162 undocumented security-sensitive combinations; 94 silently turned off a security control, while 68 made related mechanisms behave inconsistently. One pattern appeared independently in four projects: administrators could write hostname-based deny rules while disabling reverse DNS lookup. The service then compared the hostname pattern against a literal IP address, so the rule could never match and the deny list failed open.

Another project had accepted a pair of settings for 21 years that appeared to require client certificates while actually disabling the certificate check. The configuration still looked restrictive, but unauthenticated clients could reach the request-handling code behind it. This is precisely the kind of bug that ordinary review misses: neither option is obviously wrong in isolation, and the failure lives in the interaction between code paths, configuration semantics, and administrator expectations.

OpenSSH shows what reduction looks like

The clearest case study is OpenSSH, a heavily audited security-critical codebase. In OpenSSH 10.4, Claude traced roughly 4,500 lines of experimental ML-DSA-44 post-quantum signature code that an unauthenticated client could reach even when the algorithm was disabled. The server parsed the key material—and for certificates could verify an embedded authority signature—before checking whether the configured algorithm allowlist permitted it. Those 4,500 lines represented about 16% of OpenSSH’s pre-authentication code.

An initial OpenSSH 10.5 change moved an algorithm check earlier, but Claude found two gaps. A client could advertise an allowed key type while embedding a different type inside the key blob, and a certificate could still trigger verification through an embedded authority key before the configuration check. The final change placed allowlist enforcement inside the parser, before deserialization or signature verification. Anthropic estimates that the fix removed roughly one-fifth of the code reachable by an unauthenticated client in a default build.

This result is unusually checkable for a corporate research post. OpenSSH’s official 10.6 release notes credit Chris Rohlf, Claude, and Anthropic Research for moving key and certificate-authority signature checks as early as possible to reduce the attack surface of disabled algorithms. The release notes also add a useful warning: OpenSSH receives many AI-assisted reports that lack real security impact, and values them most when humans supply triage, analysis, test cases, and patches.

A workflow, not a magic scanner

Anthropic turned the method into a reusable three-pass skill. Each pass starts with a fresh context window and a small handoff from the previous pass. The first maps code reachable under default settings but unused by intended default behavior. The second examines what runs before hard gates such as authentication or protocol-state transitions. The third looks for combinations of settings that disable or degrade controls.

The workflow does not accept static reasoning alone. Claude inventories entry points and confirms findings with dynamic traces. For default-configuration findings, it proposes a gate, runs the project’s test suite and a black-box regression suite against both baseline and modified builds, and requires identical behavior. Changes that could alter a non-default configuration are reserved for human judgment. That structure—separate search passes, runtime evidence, regression testing, and a human decision boundary—is more consequential than the choice of model by itself.

Important evidence is still missing. Anthropic does not name most projects, publish all 493 findings, report the model version and cost, give a false-positive rate, or compare Claude with expert humans or established program-analysis tools. The projects and issue categories may also have been selected in ways that make the method look unusually productive. Without those details, the study does not establish how reliably another team could reproduce the results or whether the economics beat conventional review.

Even so, the central idea is durable. AI may be more valuable to defenders when it helps remove entire unnecessary execution paths than when it merely adds more candidate bugs to an already overloaded queue. A vulnerability scanner asks where code is wrong. Attack-surface reduction asks why an unauthenticated stranger can reach that code at all. The second question cannot replace the first, but it can reduce the number of unknown mistakes that ever become remotely useful to an attacker.