Anthropic Uses Claude to Audit 5 Million Lines of Code: 493 Attack Surfaces, OpenSSH Removes One-Fifth of Pre-Authentication Code

On October 20, 2026, Chris Rohlf, a researcher on Anthropic's Frontier Red Team, published a technical report disclosing a quantifiable and verifiable AI code security experiment: using Claude to analyze 25 open-source projects totaling more than 5 million lines of C, C++, Java, PHP, and Python code, and finding 493 "redundant reachable paths that ship with the software under default configuration but do not need to be exposed."

The most compelling data point came from OpenSSH. According to Anthropic's official blog, Claude traced the input paths of the SSH daemon in OpenSSH 10.4 and found that about 4,500 lines of experimental ML-DSA-44 post-quantum signature algorithm code could be reached before the client had completed authentication—about 16% of the total pre-authentication code in that version's default sshd. OpenSSH 10.5 subsequently moved the relevant checkpoints, and 10.6 completed the full fix; the fix "removed about one-fifth of the OpenSSH code that could previously be reached by unauthenticated clients."

Attack Surface Reduction: A Way to Improve Security Without Finding Vulnerabilities

Traditional software security work revolves around vulnerability discovery and remediation: find a CVE, apply a patch, then find the next one. In the report, Rohlf directly points out the fundamental flaw in this path: "Fix one critical vulnerability, and you know nothing about the remaining ones." The stock of vulnerabilities cannot be exhaustively enumerated, and an attacker only needs to find one undiscovered point to succeed.

Attack Surface Reduction takes a different path: instead of finding vulnerabilities, it limits the scope of code that attackers can reach. Even if unknown vulnerabilities exist somewhere in the code, if attackers cannot execute that code before authentication, the exploitability of the vulnerability is greatly reduced. This approach has long existed in theory; the difficulty lies in the extremely high cost of manual implementation—as software iterates through versions, it continuously accumulates abstraction layers, dependencies, and features, and determining which code is reachable at which execution stage is almost impossible to scale through manual line-by-line review alone.

The work Claude undertook in this study is precisely this human bottleneck: fully mapping each project's code reachability graph and flagging three types of issues—unnecessary pre-authentication exposure under default configurations, unexpected behavior caused by combinations of configuration options, and locations where code execution timing does not match expectations. According to Anthropic, Claude identified more than 17,000 configuration options across the 25 projects, of which 3,842 were classified as security-sensitive. Among 162 configuration combinations, two options that each appeared reasonable when enabled together quietly weakened security controls; in 94 of those combinations, the combined effect was that a security control was completely silently disabled, with neither a warning nor documentation.

Three Technical Paths, Each Corresponding to a Different Attacker Entry Point

The study used three complementary analytical methods. The first is default configuration analysis: examining which code is externally reachable under the software's factory default state but is not actually required by default functionality.

The second is configuration interaction analysis: a single configuration item is fine, but combinations produce unexpected side effects. The complexity of this type of problem is combinatorial—N configuration items theoretically have 2^N combinations, and manual testing can cover only a very small fraction of paths. Claude's advantage here is that it can mechanically traverse configuration pairs and trace their impact on code execution paths.

The third is early reachability analysis: the timing at which code is reached in the protocol state machine—which code can be driven to execution by external input before authentication, before the handshake, or before session establishment. The OpenSSH ML-DSA-44 finding falls into this category. Among the projects Anthropic examined, it found 93 locations with unnecessary pre-authentication exposure under default configurations, and 37 locations where code could execute before the authentication process.

None of these three paths found "vulnerabilities" themselves; rather, they found amplifiers of "how easily a vulnerability would be exploited if one exists." Removing these amplifiers is equivalent to reducing the probability that the entire codebase will be successfully attacked without changing the stock of vulnerabilities.

Industry Impact: What Developers, Security Teams, and Upstream Maintainers Each Face

For open-source upstream maintainers, the positive significance of the OpenSSH case is that the entire chain from receiving the report to the official release of 10.6 was complete and traceable, and the AI tool actually drove a measurable security improvement. But it also means that before AI tools became widely available, issues like ML-DSA-44 may have existed in codebases in the same pattern for years. According to research details compiled by cellcog.ai, one configuration-combination pattern for a certificate validation bypass vulnerability went undiscovered across multiple projects for 21 years—not because no one looked, but because each configuration item appeared fine on its own and failed only under a specific combination.

For enterprise security teams using these open-source components, the practical value of this research is that it suggests a new way of working: before deployment, review the components they depend on using similar methods to confirm whether exposure under default configurations matches actual business needs. Anthropic's official blog discloses that they are integrating this set of Claude capabilities into OSS-Scanner, meaning the method is expected to become available to a broader group of developers in tooled form.

For the competitive landscape of AI capabilities, the significance of this research is not that "Claude is better at security than other AIs," but that it demonstrates a concrete paradigm for using AI to do security work: not having AI write security reports, but having AI perform verifiable analytical tasks, with results independently checked by upstream projects. The fundamental difference between this "externally verifiable results" operating model and many AI security demonstrations is that it does not require trusting the vendor's self-assessment—the code changes in OpenSSH 10.6 are public, and anyone can verify whether the roughly one-fifth of pre-authentication code that was removed has really disappeared.

Comparison and Precedents: A 21-Year Latent Vulnerability and the Cost of Scale

The security community is no stranger to issues such as "configuration combinations silently disabling security controls." Similar problems have appeared many times in TLS/SSL history: when a downgrade option and another compatibility option are enabled at the same time, the security properties of the encryption protocol quietly disappear, while server logs show everything is normal. These problems remain latent for so long precisely because they do not trigger any errors in test environments and become weapons only when an attacker actively constructs a specific configuration combination.

Traditional security audits face two options for such problems: one is exhaustive testing of all configuration combinations (cost rises exponentially with the number of configuration items), and the other is relying on security researchers' experience and intuition to guess which combinations might be problematic. The former is simply infeasible for a codebase with 17,000 configuration items, and the latter depends on scarce human resources. This is precisely where AI analysis has a structural advantage—it does not need to guess and can mechanically walk through all combinations.

Of course, this method itself has boundaries. Anthropic states clearly in the report: "Measuring how many unknown vulnerabilities exist in a codebase is nearly impossible." Attack surface reduction reduces the exploitability of known or unknown vulnerabilities, not eliminate the vulnerabilities themselves. A vulnerability moved out of the pre-authentication stage can still be exploited if the attacker already possesses valid credentials. This is the ceiling of this technology, and it is also a boundary condition that the study does not attempt to conceal.

Strategic Judgment: Key Signals to Watch Next

The most important long-term implication of this research may not lie in those 4,500 lines of OpenSSH code, but in the fact that it validated a replicable workflow: use AI to generate reachability graphs, flag anomalous locations according to rules, submit them to upstream maintainers, and make the results verifiable through upstream changes. If this process can be packaged into tools that developers use daily (that is, the OSS-Scanner integration mentioned by Anthropic), then "running an attack surface analysis before release" could become a standard step in the open-source software release process, similar to today's static analysis tools or dependency vulnerability scanning.

There are three observational signals for validating this judgment: first, the actual adoption rate after OSS-Scanner integration, and whether it can cover the build pipelines of mainstream distributions; second, the remediation status of the other 24 analyzed projects besides OpenSSH—Anthropic has not disclosed item-by-item remediation progress, and the degree to which this data is made public will directly reflect the upstream community's willingness to accept such AI reports; third, whether other security vendors will follow up with similar data, creating methodological competition and mutual verification.

From a defensive security perspective, attack surface reduction and vulnerability remediation are not mutually exclusive but complementary: the former reduces the blast radius of unknown vulnerabilities, while the latter eliminates the risk of known vulnerabilities. Incorporating both into routine development processes requires not only tools but also a shift in engineering culture—from "fix it once found" to "reduce the surface before deployment." Whether AI can drive this shift depends on whether it can lower the cost enough that every maintainer is willing to run it before every release, rather than having it appear only when institutions like Anthropic conduct large-scale demonstrations.