Anthropic用Claude审计500万行代码：493处攻击面，OpenSSH修掉五分之一预认证代码

2026年10月20日，Anthropic Frontier Red Team研究员Chris Rohlf发布技术报告，披露了一项可量化、可核查的AI代码安全实验：用Claude分析25个开源项目，合计超过500万行C、C++、Java、PHP和Python代码，发现493处“软件已随默认配置出货、但无需暴露”的冗余可达路径。

最具说服力的数据点来自OpenSSH。据Anthropic官方博客披露，Claude追踪了OpenSSH 10.4版本SSH守护进程的输入路径，发现约4500行实验性ML-DSA-44后量子签名算法代码在客户端尚未完成认证时即可被触达——约占该版本默认sshd预认证代码总量的16%。OpenSSH 10.5随后移动了相关检查点，10.6完成全量修复，此次修复“移除了约五分之一的OpenSSH代码，这些代码此前可被未认证客户端触达”。

攻击面缩减：一种不靠找漏洞来提升安全性的方法

传统的软件安全工作围绕漏洞发现与修复展开：找到一个CVE，打一个补丁，再找下一个。Rohlf在报告中直接指出这条路径的根本缺陷：“修复一个严重漏洞，对于剩余的漏洞你一无所知。”漏洞存量是无法穷举的，攻击者只需找到一个尚未被发现的点即可得手。

攻击面缩减（Attack Surface Reduction）走的是另一条路：不去找漏洞，而是限制攻击者能够触达的代码范围。即便某处代码存在未知漏洞，如果攻击者在认证通过之前根本无法执行到那里，漏洞的可利用性就大幅降低。这种方法在理论上早已存在，困难在于人工实施的成本极高——软件随着版本迭代不断累积抽象层、依赖和功能，哪些代码在哪个执行阶段可达，仅靠人工逐行梳理几乎无法规模化。

Claude在这项研究中承担的工作，正是这个人力瓶颈：全量映射每个项目的代码可达图，标记三类问题——默认配置下不必要的预认证暴露、配置选项组合引发的意外行为、以及代码执行时序与预期不符的位置。据Anthropic披露，Claude在25个项目中共识别了17000余个配置选项，其中3842个被归类为安全敏感。在162组配置组合中，两个单独看似合理的选项同时启用会悄悄削弱安全控制；在其中94组情况下，组合效果是某个安全控制被完全静默关闭，既无警告也无文档说明。

三条技术路径，各自对应不同的攻击者入口

这项研究采用了三种互补的分析方法。第一是默认配置分析：检查软件在出厂默认状态下，哪些代码对外可达但实际不被默认功能所需要。

第二是配置交互分析：单个配置项无问题，但组合后产生意外副作用。这类问题的复杂度是组合爆炸式的——N个配置项理论上有2的N次方种组合，人工测试只能覆盖极少数路径。Claude在此处的优势是可以机械地遍历配置对并追踪其对代码执行路径的影响。

第三是早期可达性分析：代码在协议状态机中被触达的时序——哪些代码在认证前、握手前、或会话建立前就可以被外部输入驱动到执行。OpenSSH的ML-DSA-44发现属于这一类。Anthropic在受访项目中发现93处在默认配置下存在不必要的预认证暴露面，以及37处代码在认证流程前即可执行的位置。

这三条路径找到的都不是“漏洞”本身，而是“漏洞一旦存在时会被利用得多容易”的放大器。移除这些放大器，等于在不改变漏洞存量的前提下，降低了整个代码库被成功攻击的概率。

产业影响：开发者、安全团队、上游维护者各自面对什么

对于开源上游维护者，OpenSSH案例的正面意义在于：修复从接到报告到10.6正式上线整个链路完整且可查，AI工具实际推动了一次可度量的安全改善。但这同时也意味着，在AI工具大规模普及之前，类似ML-DSA-44这样的问题可能已在代码库中以相同模式存在多年。据cellcog.ai整理的研究细节，有一类证书验证绕过漏洞的配置组合模式，在多个项目中跨越了21年未被发现——不是因为没人看，而是因为单独看每个配置项都没有问题，只有在特定组合下才会失效。

对于使用这些开源组件的企业安全团队，这项研究的实践价值在于它提示了一种新的工作方式：在部署前用类似方法审查自己依赖的组件，确认默认配置下的暴露面是否与业务实际需要匹配。Anthropic官方博客披露，他们正在将这套Claude技能整合进OSS-Scanner，意味着这一方法有望以工具化形式向更广泛的开发者开放。

对于AI能力竞争格局，这项研究的意义不在于“Claude比其他AI更擅长安全”，而在于它展示了一种用AI做安全工作的具体范式：不是让AI写安全报告，而是让AI执行可验证的分析任务，结果交由上游项目独立核查。这种“结果可外部验证”的操作模式，与大量AI安全演示的根本区别在于，它不需要信任厂商的自我评估——OpenSSH 10.6的代码变更是公开的，任何人都可以核查那约五分之一被移除的预认证代码是否真的消失了。

对照与先例：21年的隐性漏洞和规模化的代价

安全圈对“配置组合静默禁用安全控制”这类问题并不陌生。TLS/SSL历史上多次出现过类似的问题：某个降级选项与另一个兼容性选项同时开启后，加密协议的安全属性悄悄消失，而服务端日志显示一切正常。这类问题之所以长期潜伏，正是因为它们在测试环境中不触发任何报错，只在攻击者主动构造特定配置组合时才成为武器。

传统的安全审计面对这类问题有两个选项：一是穷举测试所有配置组合（成本随配置项数量指数级上升），二是凭借安全研究员的经验直觉，猜测哪些组合可能有问题。前者对于有17000个配置项的代码库根本不可行，后者依赖稀缺的人力。这正是AI分析在此处的结构性优势——它不需要猜，可以机械地把所有组合都走一遍。

当然，这套方法本身也有边界。Anthropic在报告中明确表示：“测量一个代码库中存在多少未知漏洞，几乎是不可能的。”攻击面缩减降低的是已知或未知漏洞的可利用性，而不是消除漏洞本身。一个被移出预认证阶段的漏洞，如果攻击者已经拥有有效凭证，依然可以被利用。这是这项技术的上限，也是该研究没有试图掩盖的边界条件。

战略判断：接下来的关键信号

这项研究最重要的长期含义，可能不在于OpenSSH那4500行代码，而在于它验证了一种可复制的工作流：用AI生成可达图、按规则标记异常位置、提交给上游维护者、结果由上游变更可查证。如果这个流程能被封装进开发者日常使用的工具（即Anthropic提到的OSS-Scanner集成），那么“出厂前跑一遍攻击面分析”有可能成为开源软件发布流程的标准步骤，类似今天的静态分析工具或依赖漏洞扫描。

验证这个判断的观察信号有三个：一是OSS-Scanner集成后的实际采用率，能否覆盖主流发行版的构建管线；二是除OpenSSH之外，其他24个被分析项目的修复状态——Anthropic目前未披露逐项修复进展，这个数据的公开程度会直接反映上游社区对这类AI报告的接受意愿；三是其他安全厂商是否会跟进发布类似数据，形成方法论层面的竞争与相互验证。

从防御安全的角度看，攻击面缩减与漏洞修复并不互斥，而是互补关系：前者降低未知漏洞的爆炸半径，后者消除已知漏洞的风险。将两者都纳入常规开发流程，需要的不仅是工具，还需要工程文化的转变——从“发现了再修”到“部署前先缩面”。AI能否推动这个转变，取决于它能否把成本降到足够低，让每个维护者都愿意在每次发布前跑一遍，而不只是在Anthropic这样的机构做大规模演示时才出现。