Anthropic 官方研究《Using Claude to reduce the attack surface of code》给出了一个值得工程团队认真对待的结论：与其只盯着逐个漏洞的发现与修复，不如系统性地削减代码的可达攻击面。研究用 Claude 对 25 个开源项目（合计超过 500 万行代码，语言覆盖 C、C++、Java、PHP、Python）做了自动化攻击面分析，共发现 493 个问题。这个数字本身不是重点，重点是它验证了一条可工程化的路径：让模型先映射“哪些代码在给定部署下真正可达”，再移除或收敛不必要的暴露。
为什么攻击面削减比逐个修漏洞更可扩展
官方资料明确指出，仅靠发现和修复单个漏洞来保障软件安全，规模化效果很差：修掉一个严重漏洞，并不能告诉你还剩哪些漏洞。而减少代码可达性，可以降低未知漏洞（包括可能正被利用的漏洞）的严重程度。这些技术并不消除代码中的未知漏洞，但让漏洞更难被触达，从而降低其危害。换句话说，攻击面削减不依赖“先找到漏洞”这个前提，它改变的是漏洞被利用的路径条件。
三种识别口径：默认配置、配置交互、早期可达性
Anthropic 的研究聚焦三类攻击面描述，这也是工程落地时最值得复用的审计口径：
- 默认配置可达：识别在出厂默认配置下可达、但并非任何默认功能所需使用的代码。
- 配置交互：找出单独看都合理、组合后却出问题的选项对，例如静默关闭某项安全控制，或让某功能行为未定义但代码仍可达。
- 早期可达性：识别在适当安全控制（如认证）之前运行、无需受害者交互、或在协议状态转换之前运行的安全敏感且复杂的代码。
Claude 在这些项目中建立了超过 17,000 个配置选项的清单，其中 3,842 个与安全相关的控制或功能配置有关。研究还把项目分为 Public（面向任意可达用户）、Gated（面向已认证用户）、Private（仅服务运营者私有环境）三类，用于给结果提供上下文。例如 Public 项目默认配置下可达比例高是预期之内的，而 Gated 项目则相反。
Claude 发现了什么：几个可复用的失败模式
在 Gated 类项目中，Claude 发现全部 11 个项目都存在非预期可达的代码：93 处默认配置下不必要的预认证面、37 处认证前执行代码或记录状态的位置、61 组静默削弱管理员配置的预认证控制的配置组合。这些单独看都不一定可立即利用，但制造了远大于必要的攻击面。
配置交互类问题最具工程警示意义：Claude 发现 162 组安全敏感的配置组合被接受，既无错误也无警告，且文档未说明其交互预期行为；其中 94 组静默关闭了安全控制，另外 68 组是同一安全机制内部的不一致。一个具体模式在四个互不相关的项目中独立出现：管理员用主机名或通配符写远程客户端访问规则，而服务器是否获知客户端主机名取决于反向 DNS 查询选项（多数项目默认关闭）。查询关闭时服务器只有 IP 地址，却仍以纯文本比较主机名规则，而主机名模式永远无法匹配 IP 地址，导致拒绝规则永不触发、列表 fail open。部分项目文档提到主机名规则依赖 DNS 查询开启，但没有一个说明这种写法的拒绝列表会 fail open。
另一个案例中，两个配置选项冲突导致安全检查被静默丢弃：一个选项要求每个连接客户端用证书证明身份，另一个本意是延迟该检查，实际却完全禁用了检查。结果配置为只接受可信客户端的服务器会接受任何人的连接，把本应位于证书检查之后的大量请求处理代码暴露给未认证客户端。该冲突组合在软件中存在了 21 年，默认设置下两者同时被接受且无警告，文档从未提及证书要求被丢弃。
案例：OpenSSH 的 4,500 行预认证代码
按代码行数占比衡量，Claude 在 OpenSSH 上取得的攻击面削减幅度最大。Claude 追踪了 10.4 版本 sshd 的输入路径，发现约 4,500 行新增实验性代码（ML-DSA-44 后量子签名算法）在默认配置下可被未认证客户端触达。ML-DSA 默认未启用，但无论管理员是否显式排除该算法，代码都可达：守护进程先解析客户端发送的任意密钥类型（证书场景还验证内嵌 CA 签名），之后才检查该密钥类型是否被允许。这 4,500 行约占默认 sshd 自身预认证代码的 16%。Anthropic 连同补丁报告给 OpenSSH 开发者，10.5 版本把检查移到了解析之前。Claude 随后又指出 10.5 检查的两个缺口：一是客户端声明与实际发送不一致——检查看的是客户端通告的算法名，而解析器由密钥 blob 内嵌的类型字符串选择，客户端可以通告 ssh-ed25519 通过检查，却仍发送会被解析的 ML-DSA 密钥；二是证书路径上的缺口。
工程化落地：工作流、削减策略与 CI 接入
从官方方法可以提炼出一条可执行的工作流：先让模型建立配置选项清单并标注安全相关性，再按三类口径分别提示模型追踪可达路径，最后把发现转化为削减动作。削减策略在官方资料中被概括为“把代码移到适当的门之后”：从预认证移到认证后、从 0-click 移到 1-click、从默认开启移到显式选择加入、从协议第一条消息移到会话状态机更深处。
接入 CI 与代码评审时，建议把攻击面审计作为独立检查项而非阻断式门禁：对新增配置选项和新增预认证路径做增量扫描，输出结构化发现（项目、文件、配置组合、可达条件、建议动作），由人工复核后决定是收敛暴露还是补充文档与警告。LLM 辅助审计的边界必须明确：官方研究中的 493 个问题均经过人工研判与上报流程，模型输出应视为线索而非结论；误报控制依赖清晰的审计口径、可复现的配置组合描述，以及对“是否可立即利用”与“是否扩大攻击面”的区分。攻击面削减的价值恰恰在于它不要求每个发现都成为可利用漏洞——只要暴露被收敛，未知漏洞的严重性就随之下降。