过去一年，我们发布的大量数据显示，前沿 AI 模型已能够发现并利用安全漏洞。但展示未知漏洞如何被利用，只是前沿 AI 模型用于网络防御的开始。我们总结了关于自动化攻击面分析与缩减的初期研究：用 AI 模型绘制可达代码，再移除或限制特定部署不必暴露的部分。

过去一年，我们发布了大量数据，表明前沿 AI 模型完全有能力发现和利用安全漏洞。然而，展示如何利用此前未知的漏洞，只是前沿 AI 模型在网络安全防御中能做的事情的开端。我们在此汇总了关于自动攻击面分析与缩减的初步研究：这一流程用 AI 模型梳理可达代码，然后移除或限制某个给定部署本不需要暴露的部分的访问。

自动化的攻击面分析与缩减能在短期内显著提升已部署软件的安全性。单纯靠发现和修复单个漏洞来保障软件安全，扩展性很差：即使修复了一个严重漏洞，你对剩余漏洞仍然一无所知。相比之下，减少代码可达性能降低未知漏洞的严重程度，包括那些可能正在被实际利用的漏洞。这些方法并不会消除代码里的未知漏洞，但会让漏洞更难被触达，从而降低其危害。缩小代码库的攻击面，可以在完全不必发现或修复某个具体漏洞的情况下带来更好的安全性。

下面，我们预览了使用 Claude 对大型开源代码库应用攻击面缩减技术后收集到的一些数据。我们的目的是展示 Claude 能够通过我们下面介绍的方法，切实且低成本地提升软件安全性。我们让 Claude 分析了 25 个项目（涵盖多种语言），它共发现了 493 个问题。基于这些结果，我们也讨论了开发者如何把类似技术用到自己的代码上。

缩减代码库攻击面的方法

随着时间推移，软件往往会变得越来越复杂：新的抽象层、新的依赖和新的功能一层层堆叠起来。这常常导致软件的实际运行方式与最初开发者的设想大相径庭。这也是攻击者经常得手的重要原因：他们研究的是代码在实践中到底如何表现，而不是开发者原本意图或设计的行为。

自动攻击面分析与缩减技术的目标，是发现不必要的攻击面，然后把这些代码放到合适的“关卡”之后。这可能包括把代码从认证前移到认证后，从 0-click 移到 1-click，从默认开启移到显式选择加入，或者从协议的第一条消息移到会话状态机更深处。有些代码本就应该在这些阶段之前可达，但很多并非如此；而在数万乃至数百万行代码的变动中，功能被不必要地暴露出来往往没人注意到。

缩减代码攻击面的方法有很多。在我们自己的研究工作中，我们重点关注了以下三种：

• 默认配置。 我们找出在出厂默认配置下可达、但并非任何默认功能所需要使用的代码。
• 配置交互。 我们找出单独看都合理、但一起配置时会引发问题的选项对（例如会静默关闭某个安全控制，或者某个功能行为未定义但其代码仍可达）。
• 早期可达性。 我们找出在适当安全控制（如身份认证）之前、无需受害者交互、或在协议状态转换之前就运行的安全敏感且复杂的代码。

我们想了解 Claude 能根据这三种攻击面描述，在大型复杂代码库中多好地发现真实问题。我们分析了 25 个开源项目（超过五百万行代码），语言包括 C、C++、Java、PHP 和 Python。Claude 为这些项目建立了超过 17,000 个配置选项的清单，其中 3,842 个与安全相关的控制项或功能配置有关。

出于研究目的，我们把这些开源项目分为三大类：

• 公开类（Public）。 这类项目为任何能够访问它们的用户提供服务，或处理由无法识别身份的方所创建的数据（例如解析上游响应的 DNS 解析器，或解析源站响应的代理）。
• 受限类（Gated）。 这类项目旨在服务已通过认证的用户（例如持有密码、密钥、证书或已注册设备的用户）。软件仍允许任意客户端请求，但在用户通过认证之前不提供任何功能。
• 私有类（Private）。 这类项目为运营者自己的私有环境而构建和部署。在这种情况下，增加像认证层这样的控制是可选的，但不在软件本身的范围内。

这些类别有助于理解我们的结果。比如，我们预期公开类代码库中有相当大比例在默认配置下就是可达的（因为它本来就要服务任何用户），但受限类项目的情况应该正好相反。

Claude 的发现

Claude 用上述三种方法发现了 493 个问题。它的结果中有几个主题很突出。

第一，Claude 发现全部 11 个受限类项目都存在非本意可达的代码（尽管这些代码在任何项目中占总行数的比例都不高）。具体来说，在受限类项目的默认配置中，Claude 发现了 93 个不必要的认证前攻击面、37 处代码执行或状态记录在认证之前发生的情况，以及 61 种会静默削弱管理员所配置认证前控制的组合配置。这些问题单独来看都不会立刻被利用，但它们造成的攻击面远大于必要水平。

第二，Claude 在缓解配置交互问题上的工作产出了一些最有趣、也最有影响的结果（在所有项目类型中都是如此）。Claude 发现了 162 个安全敏感的配置组合：它们既不会引发错误或警告，也没有任何文档说明其交互的预期行为。其中 94 个组合会静默关闭某个安全控制。另外 68 个是同一安全机制内部的不一致（例如：配置里说某个监听或登录路径已禁用，但它其实仍可达；两个设置互相冲突，而哪个优先取决于它们在配置文件中的顺序；或者管理员配置的保护措施根本不起作用，而其代码仍然可达）。虽然这些配置组合有些可能并不标准或不常用，但没有任何东西能阻止这些项目的管理员以这种方式配置和部署代码。

Claude 还发现了一个在四个互不相关的项目中独立出现的具体模式。其原理如下：管理员会用主机名或通配符模式（而不是 IP 地址）为远程客户端编写访问规则。客户端连接时，服务器会把这条规则与客户端的主机名进行比对。服务器能否获知该主机名，取决于另一个控制反向 DNS 查询的选项（大多数项目默认关闭了该查询）。查询关闭时，服务器只有客户端的 IP 地址，于是会把规则与这个地址当作纯文本比对。但主机名模式永远无法匹配 IP 地址，这意味着拒绝规则永远不会触发，名单会失效开放（fail open）。部分受影响项目在文档里提到主机名规则依赖 DNS 查询开启，但没有一个说明以这种方式编写的拒绝名单会产生失效开放行为。

第三，Claude 经常发现两个配置选项会以某种方式冲突，从而静默丢弃一项安全检查。在一个案例中，管理员可以要求每个连接的客户端都用证书证明身份；而另一个案例中，代码本意只是把这项检查推迟到需要时再做，结果却完全禁用了该检查。于是，一台配置为只接受受信任客户端的服务器，会接受任何人的连接。这把一大段本应位于证书检查之后的请求处理代码暴露给了未认证客户端。该软件在默认设置下会同时接受这两个配置选项且不发出警告；文档也从未提到证书要求已被丢弃。这组冲突的配置选项已经在软件中存在了 21 年。

最后，Claude 在一个项目中发现了一个问题：该项目默认关闭身份认证（并期望管理员去开启）。要求 TLS 客户端证书的选项在大多数网络端点上被遵守，但在少数几个端点上被静默忽略（这些端点通过具有不同命名空间的路径加载 TLS 设置）。这意味着没有证书的客户端也能完成 TLS 握手，并在受影响的端点上开启会话。被忽略的设置不会留下任何日志。该选项是否生效，取决于管理员在配置中使用的命名空间：一种写法的设置在所有端点上都有效，但大多数示例使用的简短写法在受影响端点上会失效。

案例研究：OpenSSH

出人意料的是，按代码总行数的比例衡量，Claude 实现攻击面缩减幅度最大的项目是 OpenSSH。OpenSSH 是一个提供安全远程访问的高质量 C 代码库。Claude 跟踪了 10.4 版本中 SSH 守护进程的输入路径，发现大约 4,500 行用于 ML-DSA-44（一种后量子签名算法）的新实验代码，在默认配置下未认证客户端就能触达。ML-DSA 默认不启用，但无论管理员是否明确排除该算法，这些代码都可达。守护进程会解析客户端发送的任何密钥类型（对于证书，还会验证其中嵌入的 CA 签名），之后才检查该密钥类型是否被允许。配置未启用时，这段复杂且内存不安全的代码没有理由仍可达。ML-DSA-44 的这 4,500 行代码约占默认 sshd 中 OpenSSH 自身认证前代码的 16%。我们向 OpenSSH 开发者报告了这个问题并提交了补丁。10.5 版本把检查移到了解析之前。

Claude 随后注意到 10.5 的检查存在两处缺口。第一处是客户端声明的内容与实际发送的内容不一致。检查看的是客户端声明的算法名称，但解析器的选择却取决于密钥数据块（key blob）中嵌入的一个类型字符串。客户端可以声明 ssh-ed25519 从而通过检查，却仍然发送一个会被解析的 ML-DSA 密钥。

第二处缺口在 10.5 对证书的检查上。证书密钥类型默认启用。如果攻击者提供一个证书，sshd 会先反序列化其中嵌入的 CA 公钥，并用它执行完整的签名验证，然后再去查配置——而且是对任何支持的算法都这样。用户密钥签名路径被正确地限制在允许连接服务器的公钥列表之后，但 CA 签名路径没有。这使得二进制中的每一个公钥签名验证器，都能被任何完成密钥交换的客户端触达。我们构建了一个概念验证，并与维护者一起迭代了几版修复方案。最终的改动把检查放进了解析器内部：编码后的密钥类型和证书的 CA 签名算法，现在会在相应的反序列化或签名验证之前，就与配置的允许列表进行比对。

这一修复移除了默认构建中未认证客户端原本可触达的 OpenSSH 代码的大约五分之一。其中几乎全部是新的 ML-DSA 代码；现在即使客户端谎报密钥类型，或把 ML-DSA CA 密钥藏在一个原本可接受的证书里，这些代码也不可达。使用允许的 CA 算法签名的证书仍会被解析和验证，但检查现在运行在解析之前。维护者在 10.6 版本中发布了这里描述的改动。

OpenSSH 是世界上审计最严格的代码之一。如果不必要的可达性在这里都能存活，那它在任何地方都可能存活。这说明缩减代码库的攻击面，很可能在许多重要代码库中带来回报。

结论

也许无法衡量任何给定代码库里还有多少未知漏洞。有大量数据表明，只要时间充足，攻击者就能找到这些漏洞（尤其是配备了前沿 AI 模型时）。但防御者如果在自己的代码中减少不必要的攻击面，就能一次性降低该代码中所有未知漏洞带来的风险——包括那些已经在被悄悄利用的漏洞。OpenSSH 是世界上审计最严格的 C 代码之一，但它仍然发布了大约 4,500 行实验性签名解析代码，而这些代码在配置检查之前就可能被攻击者触达。

我们已经把上述攻击面缩减技术整合成一个可复用的 Claude skill，并正努力把它集成到 OSS-Scanner 中。这个 skill 会对代码库运行三轮检查。每一轮都从头开始（上下文窗口为空），只保留上一轮传来的简短上下文。

第一轮，skill 检查默认配置下是否有代码可达，但这些代码并未被任何预期功能使用。第二轮，它检查在任何配置下，是否有代码运行在硬性关卡（如身份认证）之前，或者运行在协议状态机入口点之前。第三轮，skill 评估哪些配置组合会静默关闭安全控制或削弱其效力。每一轮中，Claude 都会从代码里建立入口点清单，并通过程序的动态跟踪来确认每一个发现。对于默认配置类发现，它会设计并实现一个关卡，并确保这不会改变程序的默认行为：它把修改后的构建与基线一起跑项目自身的测试套件（以及黑盒回归套件），要求结果完全一致。任何会改变非默认配置的关卡都会被搁置，交由人工决定。对于另外两类发现，它会提出修改建议，例如调整配置检查的顺序、增加守卫以强制执行状态顺序，或在配置加载时拒绝该组合。即使不使用这个具体的 skill，我们认为这里概述的通用方法很可能也是有效的。

这里介绍的技术只展示了攻击面缩减可能性的很小一部分。例如，Claude 还能分析运行时日志并与配置进行比对，以确保只启用了必需的功能：禁用未使用的解析器、遗留协议和仪表板，就能以很低的成本降低安全风险。

我们鼓励各类组织探索使用 Claude 来分析和缩减其所依赖软件的攻击面。我们预计，这将成为开发者能够切实改善全球已有代码安全性的最实用方法之一。

讨论气氛讽刺且不信任，主轴是 Anthropic/Claude 所谓“降低攻击面”是否可信。多数人认为其网络安全过滤与身份核验把防御者挡在门外，反而让攻击者用不受限模型占优；只有少数人给出 Claude 成功辅助代码模块化、缩小攻击面的实例，另有人强调长期只能靠形式化验证和极小可信计算基。

认为 Claude 的网络安全限制正在妨碍防御者

• Claude 遇到安全任务会降级或拒绝，防御者要绕过检测才能修复自己的漏洞；攻击者却能用不受限的 DeepSeek 等模型，因此有人转向 Codex 与开放模型。（较多人）
• 防御审计需要模型产出可运行 PoC，但先进模型拒绝配合，只有 GLM、Kimi 等完成，凸显反直觉的不对称。（较多人） > 在自己的代码库上做安全审计时，Claude 和 GPT 拒绝，Grok 也不给可运行的 PoC，最后是 GLM-5.3 和 Kimi 完成了任务。（@tilemarch）
• 甚至有评论把“不要用 Claude，也不要允许安装”当成基本原则。（少数人）

讽刺 Anthropic 自身技术栈与其缩小攻击面的主张相矛盾

• 评论指出，他们的聊天应用和终端界面分别使用 Next.js 与 React，这类重型前端框架本身会扩大攻击面，却来谈如何减少攻击面，形成讽刺。（少数人） > 用 Next.js 做聊天应用、用 React 做终端界面，却来谈减少攻击面，真是讽刺。（@owebmaster）

怀疑 AI 所报漏洞被夸大、成果发布过于仓促

• 有内核开发者在演讲中称，Mythos 宣称的 79 个内核漏洞大多不是问题或早已修复；评论据此怀疑实验室在没弄清底层问题前就急于宣布，这篇文章的质量也存疑。（少数人） > 大多数所谓内核漏洞要么不是问题、要么早已修复，实验室可能只是急于宣布结果。（@petermora）

认为文章拼写错误既像人工手写也说明校对不足

• 有人统计至少四处拼写错误，认为 Anthropic 连基本校对都没做好，削弱可信度；关于一处漏掉的撇号，则有评论调侃这恰是人类手写的痕迹，在 AI 生成内容时代反而让人觉得亲切。（少数人） > 少了一个撇号？看来这是人类写的！（@StilesCrisis）

认为 Claude 仍可通过模块化重构帮助缩小攻击面

• 有开发者用 Claude 系列模型把 Vix IDE 重构成多个 Rust crate 与 Cargo feature，安全用户可以按需启用功能，审计者也能逐个能力审查；提交信息质量也还不错。（少数人） > 把功能拆进带 feature flag 的 Rust crate，做出最小版本，Claude 成功完成了整个重构。（@jph）

认为长期只有形式化验证与极小可信计算基能抵御 AI 暴力攻击

• 随着开源模型的规模与可及性提升，非形式化验证的系统都会被“暴力算力”攻破；出路只能是全形式化验证语言、unikernel、极小可信计算基（TCB），最敏感场景还需要验证过的硬件。（少数人） > 未来一切非形式化验证的系统都会被开源模型的算力规模轻易攻破，只能走向全形式化验证语言、unikernel 和极小 TCB。（@mentalgear）