不找 bug，删靶子：Claude 给 OpenSSH 等 25 个开源项目"缩圈"

一句话：与其一个个修漏洞，不如让漏洞够不着

2026 年 10 月 20 日，Anthropic Frontier Red Team 的 Chris Rohlf 发表研究帖《Using Claude to reduce the attack surface of code》，公布了一项"防守向"的 AI 安全研究：让 Claude 扫描 25 个开源项目（超过 500 万行代码，覆盖 C、C++、Java、PHP、Python），不找具体的漏洞，而是系统性地缩小攻击面——把不该暴露的代码从攻击者够得着的地方挪走。结果：发现 493 个攻击面问题。

其中最抓眼球的案例是 OpenSSH——全世界被审计得最多的 C 代码之一。Claude 在 10.4 版本里揪出约 4500 行实验性的后量子签名代码（ML-DSA-44），在默认配置下、认证之前就能被未登录的客户端触达，约占 sshd 认证前代码面的 16%。OpenSSH 10.6 已经合并修复，删掉了约 1/5 的认证前可达代码。

Anthropic 的原话值得记住："If unnecessary reachability survives there, it can survive anywhere."（如果连 OpenSSH 里都有不必要的可达代码，那它在哪儿都可能存在。）

三种"缩圈"方法：默认配置、配置组合、提前可达

这项研究的方法论比数字更重要。Claude 被要求用三种固定视角去审视代码：

1. 默认配置（Default configuration）：找出"出厂默认就能被触达、但默认功能根本用不到"的代码。软件是给所有人用的（Public）、给登录用户用的（Gated）、还是只给运维自己用的（Private），三类项目的"应有暴露面"完全不同——很多代码的暴露纯属历史惯性。

2. 配置组合（Configuration interaction）：单看每个配置项都合理，但组合在一起会静默关掉安全控制。这是本次发现里最毒的一类：Claude 发现 162 对安全敏感的配置组合，被系统静默接受——不报错、不告警、不写文档说明组合后的行为。其中 94 对会直接关闭某个安全控制，另外 68 对则是同类安全机制的前后不一致（比如监听器明明配置了禁用，代码却还可达）。

3. 提前可达（Early reachability）：在安全控制生效之前就能跑到的复杂代码——认证之前、无需用户交互、协议状态机还没进入正题。11 个"需认证"（Gated）项目全部存在非预期的认证前可达代码：93 处认证前不必要的暴露面、37 处认证前执行代码或记录状态、61 组静默弱化认证前控制的配置组合。原文强调：这些问题单独看都"不是立刻可利用的"，但它们把不必要的攻击面撑大了一圈。

为支撑这三类检查，Claude 先给 25 个项目做了 17000+ 个配置项的盘点，其中 3842 个与安全控制相关——光是这份"配置地图"，对很多项目来说就是第一次有人认真画出来。

图：Claude 发现的攻击面问题构成（部分）。数据来源：Anthropic《Using Claude to reduce the attack surface of code》（2026-10-20）。

四个让人后背发凉的细节

细节一：一个"21 年之久"的静默失效。某软件里，一对冲突的配置组合存在了 21 年：管理员以为自己要求了"所有客户端必须出示证书"，另一个"只是延迟检查"的选项实际上把检查整个关掉了——于是自以为只接待可信客户端的服务器，对任何人敞开。两个选项一起用时不报任何警告，文档也从没提过证书要求被丢掉了。

细节二：fail-open 的 hostname 规则。Claude 在 4 个互不相关的项目里独立发现了同一个模式：管理员用 hostname/通配符写访问规则，但反向 DNS 查询默认是关的——服务器手里只有客户端 IP。hostname pattern 永远匹配不上 IP，于是 deny 规则永远不触发，访问控制列表 fail open（失效时放行）。文档提了"hostname 规则依赖 DNS 查询"，但没一个说清"写错了会直接放行"。

细节三：TLS 客户端证书"看命名空间下菜"。某项目默认不开启认证、指望管理员手动开。要求 TLS 客户端证书的选项在大部分网络端点上生效，但在几个走了不同命名空间的端点上被静默忽略——无证书的客户端能完成 TLS 握手、打开会话，还不记任何日志。配置项写全称处处生效，写简称（文档示例里最常用的写法）就在那几个端点上失效。

细节四：OpenSSH 的两次"补了又被绕过"。10.5 先把"检查算法是否在允许列表"挪到了解析之前，Claude 接着发现两个绕过：检查看的是客户端"宣称"的算法名，解析器选的却是 key blob 里内嵌的类型字符串——客户端宣称 ssh-ed25519 通过检查，实际塞一把 ML-DSA 密钥照样被解析；证书路径上，CA 公钥的签名验算在查配置之前就跑完了。最终修复把检查塞进了解析器内部：先对允许列表，再反序列化、再验签。10.6 出货。

判断：这是"防守"的第三条路，也是 vibe coder 最该补的一课

过去一年，AI 安全新闻基本是两条线：攻击线（还记得 cycle82 那篇"AI agent 自动攻破上百家企业网站"吗）和挖洞线（上周的 PHP2Shell，AI 帮防守方找漏洞）。Anthropic 这篇开的是第三条线：不找漏洞，直接缩小靶子。

它的哲学很硬核：修掉一个严重漏洞，你对"还剩多少漏洞"一无所知；但把不必要的可达代码删掉，你一次性降低了所有未知漏洞的严重程度——包括那些正在被悄悄利用的。未知漏洞没法数，但攻击面可以量。

对 vibe coder 来说，这篇研究的现实意义比看起来大得多：

第一，"默认配置≠安全配置"。AI 生成项目有个坏习惯：脚手架默认开了一堆东西（管理后台、调试端点、示例路由），上线时没人关。Claude 在顶级开源项目里都能找出 93 处认证前不必要的暴露面，你的 vibe 项目里只会更多。上线前做一次"暴露面盘点"，是性价比最高的安全动作。

第二，配置组合是 AI 时代的放大器。以前配置是人手写的，组合数有限；现在 AI 一次生成几十个环境变量和 feature flag，组合爆炸。162 对"静默接受"的问题告诉我们：凡是"配了但没生效也不报错"的选项，都是定时炸弹。给你的项目加一条铁律：每个安全相关配置项都要有"未生效时告警"的自检。

第三，这个方法你自己就能用。Anthropic 把这套三遍扫描做成了一个可复用的 Claude skill（计划集成进免费的 OSS-Scanner）：第一遍扫默认配置下不该可达的代码，第二遍扫硬门（认证/状态机）之前的代码，第三遍扫静默关闭安全控制的配置组合，每遍都从空上下文重新开始、并用动态追踪确认发现。哪怕不用它的 skill，这个"三遍检查法"也可以直接拿去审自己的项目——让 Claude Code 跑一遍，比你肉眼 review 靠谱。

三遍扫描法：直接拿去用的自查清单

Anthropic 的 skill 有三遍扫描，每遍从空上下文开始。你没有它的 skill 也没关系——下面是翻译成"人话"的检查清单，可以直接贴给 Claude Code，让它审你的项目：

第一遍：默认暴露盘点。"列出这个项目在默认配置下所有对外暴露的入口：HTTP 路由、RPC 接口、管理后台、调试端点、示例页面。对每一个回答：它是默认功能必需的吗？如果不是，标出来。"——重点抓脚手架残留：/debug、/admin、Swagger UI、GraphQL playground，这些在 vibe 项目里十有八九开着。

第二遍：硬门之前的代码。"找出所有在身份认证、权限校验生效之前就会执行的代码：中间件顺序、路由守卫之前的逻辑、协议握手阶段解析的数据。对每一段回答：攻击者不登录能不能触发它？触发它需要多少成本？"——特别注意"先解析、后鉴权"的模式（OpenSSH 栽的就是这个）。

第三遍：配置组合静默失效。"列出所有安全相关的配置项，两两组合检查：有没有哪一对组合在一起时，某个安全控制会被静默关闭而不报错？把'设置了但不生效也不告警'的选项全部标出来。"——这一遍最费模型，但价值最高；让它输出表格：配置 A × 配置 B → 实际效果 → 是否告警。

跑完三遍，你会得到一份"攻击面清单"。修的优先级：先删不必要的暴露（删代码），再修静默失效（加告警/拒绝非法组合），最后才是加固必要的暴露面。顺序别反——Anthropic 整篇研究的核心就是这个顺序。

vibe 项目上线前：30 分钟暴露面盘点实操

把上面的方法论压缩成上线前必做的 30 分钟：

1. 0-10 分钟：路由大扫除。curl 一遍你所有的路由（让 AI 从代码里提取完整列表），逐个问"这个路由上线第一天就需要吗？"不需要的，删掉或藏到 feature flag 后面。重点：管理后台、调试接口、健康检查端点（health check 暴露版本号是常见的信息泄露）。
2. 10-20 分钟：默认配置审查。把生产环境的配置文件从头读一遍，找"默认开着但你没用"的东西：详细错误堆栈（debug mode）、目录列表、CORS 的 *、宽松的 CSP。vibe 项目的默认值基本都是脚手架的默认值——而脚手架的默认值是为"开发方便"设计的，不是为"生产安全"。
3. 20-30 分钟：密钥与暴露面交叉检查。确认上一步暴露的端点里没有需要密钥才能调的第三方接口被直接透出（见本系列《密钥与凭证管理实战》）。以及：错误信息里会不会吐出密钥、路径、版本号——让 AI 故意调几个 404/500 看看返回体。

做完这 30 分钟，你的项目攻击面可能就砍掉了一半。剩下的，才是值得花钱做渗透测试的部分——顺序对了，安全预算才花得值。

对比：四种"防守"手段的取舍

攻击面缩减不是要取代现有的安全手段，而是补上缺的那一块。一张表看清四种防守的定位：

手段	回答的问题	对未知漏洞的效果	vibe 项目适用性
漏洞扫描/修补（SAST/DAST）	"已知漏洞在哪"	无效——只能处理已知问题	必备基础，但别指望它兜底
模糊测试（Fuzzing）	"输入能砸出什么崩溃"	部分有效，能发现未知崩溃	对解析器类代码价值高，接入成本中等
攻击面缩减（本篇）	"不必要的暴露在哪"	有效——降低所有未知漏洞的严重程度	性价比最高，上线前 30 分钟就能做
纵深防御（WAF/沙箱/最小权限）	"被突破后怎么止损"	有效——限制爆炸半径	运行时必备，和缩减攻击面互补

关键洞察：前两种是"找坏人"，后两种是"让坏人难受"。Anthropic 这篇的价值在于证明了第三种可以被 AI 自动化——以前攻击面缩减是安全专家的手工活（读代码、画信任边界），现在 Claude 可以批量做。这意味着小团队也能享受到以前只有大厂才做得起的防守手段。

给 vibe 项目的预算分配建议（按投入产出比排序）：1）上线前 30 分钟暴露面盘点（免费）；2）密钥管理（见本系列指南，接近免费）；3）依赖扫描（GitHub Dependabot，免费）；4）再考虑付费的 SAST/渗透测试。顺序对了，每一分钱都花在刀刃上。

技术细读：OpenSSH 的两次修复为什么值得学

OpenSSH 案例最精彩的部分不是"发现 4500 行问题代码"，而是修复过程本身——它展示了安全修复的正确姿势，值得每个写服务端代码的人学。

第一次修复（10.5）：把检查前移。原来的顺序是"先解析客户端发来的密钥、再查配置允不允许这种算法"。修复把它反过来：先查配置，再解析。思路是对的——"先问能不能，再动手干"。这是安全工程的经典原则：校验前置。

第一次修复被绕过：检查与执行用了不同的"真相源"。Claude 发现，检查看的是客户端"宣称"的算法名（握手消息里的字符串），而解析器选的是 key blob 里内嵌的类型字符串。攻击者宣称"我用的是 ssh-ed25519"（在允许列表里），实际塞一把 ML-DSA 密钥——检查放行了，解析器按内嵌类型走了 ML-DSA 解析路径。这是典型的 TOCTOU（检查时与使用时不一致） 变体：检查的对象和使用的对象不是同一个东西。

证书路径的第二个绕过更隐蔽。用户密钥的签名验算被正确地挡在了"允许连接的公钥列表"后面，但 CA 签名的验算路径没有——攻击者拿任意 CA 算法签个证书，sshd 会先反序列化 CA 公钥、跑完整套签名验算，然后才去查配置。验算本身就可能触发解析器 bug，而验算发生在"配置允许吗"之前。

最终修复（10.6）：把检查塞进解析器内部。不再依赖"调用方记得先检查"，而是让解析器自己在反序列化/验签之前先对允许列表。设计思想是"让不安全的状态不可达"（make illegal states unrepresentable）：与其指望每个调用点都记得检查，不如让底层原语默认就是安全的。

给 vibe coder 的 takeaway：让 AI 生成鉴权/解析代码时，加一条 instruction——"任何解析不受信输入的代码，必须先完成 allowlist 校验；校验和解析必须基于同一个字段，不允许'宣称值'和'实际值'分离"。把这条写进 AGENTS.md，一劳永逸。

什么时候可以不用做： scope 的诚实边界

攻击面缩减虽好，但不是银弹，诚实地说出它的边界：

• 纯前端/展示型项目：没有服务端鉴权、没有敏感操作，攻击面本身就小，30 分钟盘点做完就可以收工，不用上三遍扫描；
• 0 用户的 MVP：验证需求阶段，速度优先。但要在代码里留 TODO，上线前必须补——"先欠着"和"不知道要还"是两回事；
• 它替代不了依赖安全：你的攻击面缩得再小，引用的第三方库有 RCE，该崩还得崩。Dependabot / pnpm audit 和本文是互补关系，不是谁替代谁。

一句话：攻击面缩减是"乘法"，让你的其他安全投入效果翻倍；但它不是"加法"，不能替代任何一层。

最后给 vibe coder 留一个行动项：今晚花 30 分钟，对你最重要的那个项目跑一遍"暴露面盘点"（路由大扫除 → 默认配置审查 → 密钥交叉检查）。你大概率会删掉至少 3 个"不知道为什么开着"的端点——这 30 分钟，可能是你今年性价比最高的安全投入。做完记得把过程记录下来，下次上线新项目直接复用。

划界与透明度

本文是资讯，讲的是 Anthropic 10 月 20 日发表的一项具体研究；本站此前发布的《AI coding agent 安全实践》是指南（讲 agent 本体的提示注入、权限、沙箱），两者是新闻 vs 方法论的关系，开篇即做区分。另外注意 cycle65 发过 OpenAI 的"19 份失格报告"——那是模型行为披露，本篇是代码安全研究，主题不同。

透明度：文中所有数字（25 项目 / 493 问题 / 17000+ 配置项 / 93 / 37 / 61 / 162 / 94 / 4500 行 / 16% / 约 1/5）均来自 Anthropic 官方研究帖自报，未经独立复现；原文明确说明这些发现"单独看都不是立刻可利用的"（None of these issues would have been immediately exploitable on their own），本文未夸大其严重性。OpenSSH 修复已随 10.6 发布，为公开可验证事实。可复用 skill 的 OSS-Scanner 集成状态以 Anthropic 后续公告为准。