Using Claude to shrink code attack surface: 493 issues in 25 projects
Anthropic shared research on using Claude to find code that a deployment can reach but does not need, then restrict or remove it. Across 25 open-source projects with over five million lines, it reported 493 issues. In OpenSSH, about 4,500 lines of experimental post-quantum signature code reachable before authentication were addressed in releases 10.5 and 10.6. It is a concrete method for teams using AI in security reviews.
Key points
- The method covers three angles: code reachable in the default configuration, risky option pairs, and code that runs before authentication or a protocol state change.
- Across 25 projects Claude reported 493 issues; 162 were security-sensitive option combinations, and 94 of those silently disabled a security control.
- A hostname-based deny rule can never match an IP address when reverse DNS lookups are off, so the list fails open.
- In OpenSSH 10.4, about 4,500 lines of ML-DSA-44 code were reachable by unauthenticated clients; release 10.5 moved the key-type check before parsing.
- OpenSSH 10.6 closed the remaining gaps, including mismatches between advertised algorithm names and embedded key types and CA signature paths.
- Review your own code for what is reachable before login and what runs under default settings, not just for known CVEs.
Anthropic published early research on using Claude to shrink the attack surface of software. The method finds code that a deployment can reach but does not need, then gates or removes it. That lowers the severity of unknown vulnerabilities without locating each one first. Across 25 open-source projects written in C, C++, Java, PHP and Python, Claude reported 493 issues, grouped into default-configuration exposure, risky option combinations and code running before authentication.
The OpenSSH case is the most concrete example. In release 10.4, Claude found roughly 4,500 lines of experimental ML-DSA-44 code that an unauthenticated client could reach in a default build. After Anthropic reported it with patches, release 10.5 moved the key-type check ahead of parsing, and 10.6 closed the remaining gaps around certificate signatures. The takeaway for teams using AI in security reviews is to audit what is reachable, not only what is known to be vulnerable.
Real-world use
- Auditing pre-authentication parsers in an SSH or VPN server before deciding which algorithms and features to enable.
- Checking a multi-option network service for config combinations that silently disable a security control.
- Trimming a third-party open-source server to the features your deployment actually uses, so fewer code paths stay reachable.
Why it matters
If you use AI for security review, the useful question shifts from only "which known bugs exist" to "what can an unauthenticated client reach in our default build". Configuration combinations that silently drop a control are worth checking as part of routine reviews.