Using Claude to reduce the attack surface of code

What it is

Anthropic research by Chris Rohlf on using Claude to find code that is reachable but not needed, then gating it. Claude ran over 25 open-source projects (C, C++, Java, PHP, Python; over five million lines). It inventoried more than 17,000 configuration options, 3,842 of them security relevant, and reported 493 issues. The pitch is that reducing reachability lowers the severity of all unknown bugs at once, without finding any single one.

How it works

Projects were sorted into Public, Gated (authenticated users) and Private, which sets how much default reachability is expected. Three methods were applied:

• Default configuration: code reachable in the shipped config that no default feature uses.
• Configuration interaction: option pairs that look fine alone but silently disable a control together.
• Early reachability: complex code that runs before authentication, before victim interaction, or before a protocol state transition.

Findings the summary does not list:

• All 11 gated projects had unintended reachable code: 93 unnecessary pre-auth surfaces in default config, 37 places where code ran or state was recorded before auth, and 61 option combinations that silently weakened a pre-auth control.
• 162 security-sensitive option combinations were accepted with no error, warning or documentation. In 94 the combination silently turned a security control off. The other 68 were inconsistencies, such as a listener staying reachable though configured off, or precedence depending on option order in the file.
• Four unrelated projects shared one fail-open pattern. A deny rule written as a hostname or wildcard is compared with the client's IP as plain text when reverse DNS lookup is off (the usual setting). A hostname pattern never matches an IP, so the deny rule never fires. Documentation mentioned the DNS dependency but not the fail-open result.
• One server accepted a "require client certificate" option combined with a second option meant only to delay the check, but the pair disabled the check entirely. The pair had been present for 21 years.
• One project with auth off by default honored the TLS client-certificate option on most endpoints but ignored it on a few, which load TLS settings through a different namespace. The shorter setting name, used in most examples, is dropped there. A client with no certificate could complete the handshake and open a session, and nothing was logged.

OpenSSH case study

In the 10.4 release, about 4,500 lines of ML-DSA-44 code (about 16% of default sshd pre-auth code) were reachable by an unauthenticated client, even when the algorithm was excluded. sshd parsed the key type first and checked the allow list afterwards.

The 10.5 fix moved the check before parsing, but Claude found two gaps:

1. The check read the algorithm name the client advertised, while the parser was chosen by a type string inside the key blob. A client could advertise ssh-ed25519 and still send an ML-DSA key.
2. For certificates (enabled by default), sshd deserialized the embedded CA key and ran full signature verification for any supported algorithm before consulting configuration. This exposed every public-key verifier in the binary to any client that could complete key exchange.

The authors built a proof of concept. The final fix compares the encoded key type and the certificate's CA signature algorithm against the configured allow lists inside the parser, before deserialization or verification. It removed roughly a fifth of the pre-auth code reachable in a default build. The changes shipped in OpenSSH 10.6.

What to do

• Audit your own config handling for the patterns above: hostname-based deny rules with reverse DNS off, mutually exclusive TLS or auth options, and option-name aliases that behave differently per endpoint.
• Check that allow-list checks run before parsing or verification, and that they key on the parsed value, not the client's claim.
• Run the reusable Claude skill, which the authors are integrating into OSS-Scanner. It makes three passes (default configuration, early reachability, configuration interaction), each starting with an empty context plus a short note from the prior pass.
• Each pass inventories entry points and confirms findings with a dynamic trace.
• For default-config findings it implements a gate and requires the project's test suite and a black-box regression suite to match baseline results.
• Gates that would change non-default behavior go to a human.
• For the other two passes it proposes reordering a check, adding a state-order guard, or rejecting the combination at config load.
• The post also suggests comparing runtime logs with configuration to disable unused parsers, legacy protocols and dashboards.

Caveats

• The post says none of the pre-auth findings in gated projects were immediately exploitable alone.
• Some flagged option combinations may be non-standard or rarely used, though nothing stops an administrator from deploying them.
• The post calls this an early preview of its data. It does not name the 25 projects (apart from OpenSSH), give false-positive rates, or report cost figures.