Claude's Automated Attack Surface Reduction for Software Security

Automated attack surface analysis and reduction meaningfully improves the security of deployed software by minimizing code reachability, thereby reducing the severity of unknown vulnerabilities without requiring the discovery or fixing of individual flaws.

Traditional software security relies on finding and fixing individual vulnerabilities, a process that scales poorly. By contrast, reducing the attack surface limits the code that is reachable by an attacker, making even unknown vulnerabilities harder to exploit. This approach minimizes the overall risk profile of a codebase.

Methods for Reducing Codebase Attack Surface

Attack surface reduction techniques aim to identify and restrict unnecessary code exposure that results from the complexity and churn inherent in large software projects. This process moves code behind appropriate security gates, such as moving functionality from pre-authentication to post-authentication, or from on-by-default to explicit opt-in.

Anthropic focused on three specific methods for automated attack surface analysis:

  • Default Configuration: Identifying code that is reachable in the shipped default configuration but is not intended for use by any default functionality.
  • Configuration Interaction: Finding pairs of configuration options that appear reasonable individually but cause security issues when combined (e.g., silently disabling a security control).
  • Early Reachability: Identifying security-sensitive and complex code that executes before an appropriate security control (such as authentication), without victim interaction, or before a protocol state transition.

Claude's Findings Across Open-Source Projects

Applying these techniques to 25 large open-source projects, representing over five million lines of code across languages including C, C++, Java, PHP, and Python, yielded 493 discovered issues. These findings were categorized based on the project's deployment model:

  • Public: Projects designed to serve any user who can reach them (e.g., a DNS resolver parsing upstream answers).
  • Gated: Projects intended for authenticated users, where functionality is restricted until authentication is complete.
  • Private: Projects deployed solely to serve the operator's private environment.

Gated Project Vulnerabilities

Claude found that all eleven gated projects contained code that was unintentionally reachable. Specifically, the gated cohort showed 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 configured by the administrator. While these issues were not immediately exploitable alone, they significantly expanded the necessary attack surface.

Impact of Configuration Interaction Issues

Configuration interaction analysis produced some of the most impactful findings across all project types. Claude discovered 162 security-sensitive configuration combinations that were accepted without error, warning, or documentation regarding their interaction.

  • Silent Security Control Disabling: In 94 of these cases, the combination of settings silently turned off a security control.
  • Inconsistencies: The remaining 68 cases involved inconsistencies within security mechanisms, such as a listener remaining reachable despite being configured as disabled, or conflicting settings where the effective behavior depended on the order in the configuration file.

One specific pattern found independently in four unrelated projects involved a fail-open vulnerability: an administrator using a hostname or wildcard pattern for an access rule, instead of an IP address, combined with a separate option controlling reverse DNS lookups being disabled. With lookups off, the server compared the rule against the client's IP address as plain text, which could never match a hostname pattern, causing a deny rule to fail open.

Case Study: OpenSSH Attack Surface Reduction

OpenSSH, a highly audited C codebase, was the project where Claude achieved the largest percentage reduction in attack surface. Claude traced the input paths of the SSH daemon in the 10.4 release and found approximately 4,500 lines of new and experimental code for the ML-DSA-44 post-quantum signature algorithm that an unauthenticated client could reach in the default configuration.

This code was reachable even when the administrator explicitly excluded the algorithm, because the daemon parsed whichever key type the client sent before checking if that key type was allowed. These 4,500 lines represented about 16% of OpenSSH’s own pre-authentication code in a default sshd.

Following this initial finding, Claude identified two gaps in the 10.5 release:

  1. Client Claim Mismatch: The check looked at the algorithm name advertised by the client, but the parser was chosen by a type string embedded inside the key blob, allowing a client to advertise one algorithm while sending a different, vulnerable key type.
  2. Certificate Verification Bypass: Certificate key types were enabled by default. An attacker could supply a certificate, causing sshd to deserialize the embedded CA public key and run a full signature verification before consulting the configuration. This made every public key signature verifier in the binary reachable by any client that could complete a key exchange.

The resulting fix, implemented in version 10.6, placed the configuration checks inside the parser itself, ensuring that the encoded key type and the certificate’s CA signature algorithm are compared against configured allow lists before any deserialization or signature verification occurs. This change removed roughly a fifth of the OpenSSH code previously reachable by an unauthenticated client.

Implementation and Conclusion

Anthropic has combined these attack surface reduction techniques into a reusable Claude skill, which is being integrated into OSS-Scanner. This skill operates in three passes:

  1. It checks for code reachable by the default configuration that is unused by intended functionality.
  2. It examines code that runs before hard gates (like authentication) or before protocol state machine entry points, regardless of configuration.
  3. It assesses configuration combinations that silently switch a security control off or degrade its efficacy.

For default configuration findings, the skill designs and implements a gate, verifying that the modified build passes the project's existing test suite. For the other two passes, it proposes changes such as reordering a configuration check or adding a guard to enforce state ordering.

While the techniques presented offer a limited view of what is possible, the methodology suggests that reducing the attack surface of codebases is a highly practical and effective way to improve security. By minimizing unnecessary exposure, defenders can reduce the risk posed by all unknown vulnerabilities in a codebase simultaneously, regardless of whether those vulnerabilities are currently being exploited.

Sources