Claude Security 已进入公开测试版：“扫描即修复”宣称了什么，又没有宣称什么

Anthropic 的安全产品现已在 Claude Enterprise 中进入公开测试阶段，它的一句话卖点是一串动作序列，而非一个形容词：从扫描到修复，全程无缝完成。这句话背后的运作机制在产品页面上写得清清楚楚——Claude 借助 Claude Mythos 扫描你的代码库，验证所发现的问题，并给出可供你审阅和批准的补丁建议。三个动词、一个模型名称，还有一条极易被一眼略过的适用范围限制：这是测试版，而且是专为 Enterprise 客户而写，并非面向任何恰好拥有代码仓库的人。

有趣的问题从来都不是语言模型能否发现漏洞。模型做这件事已经有一段时间了，有时做得足够好，足以让编写代码的人难堪。有趣的问题是，从发现结果出现的那一刻到它被关闭的那一刻之间会发生什么，因为这段间隙正是安全积压问题所在之处：一队看似合理的问题，没人排序，被分配给所有人，靠偶然被关闭。Anthropic 的答案是包含四个阶段的流水线，而每个阶段都提出一个可以单独审视的主张。

“Claude Enterprise 公开测试版”是什么意思？

可用性说明写得异常直白，值得原样引用而非转述：以公开测试版形式面向 Claude Enterprise 提供。其下方有两个按钮——联系销售，以及阅读教程。两者都不是注册表单。实际上，这意味着买家是已经签有 Enterprise 协议、且其安全团队有足够话语权去申请一款新扫描器的企业，而不是想把某个东西指向自己业余项目的个人工程师。

还有第二种更轻量的切入点。用于 Claude Code 的 Claude Security 插件目前处于测试阶段。它是一款不同的软件，部署方式也不同——在 Claude Code 内进行扫描、验证和修补，同时让代码留在你的环境中——而对于那些障碍不在于预算、而在于源代码允许流向何处的规定的团队来说，这才是真正重要的版本。

扫描不会停止

首个有记录的行为是深度首次扫描：Claude 对代码库运行一次，然后在代码发生变化时持续扫描。这是一句简短的话，却带来巨大的运营后果。一次性扫描是一张照片。代码库不是照片；它们是天气。一个在审计当天准确、却被随后三次合并修复了一半的发现，比完全没有发现更糟，因为它会消耗那些不得不重新阅读它的人的注意力。

持续扫描也是产品中最难造假的部分。它要求扫描器理解哪些变更重要，这与在静态树中发现漏洞是两种不同的技能。页面没有描述这种优先级排序如何运作，本文也不会对此妄加猜测。

该主张唯一具体的一个维度

Anthropic 声称，Claude Security 会追踪跨文件和代码库的数据流，以发现模式匹配扫描器可能检测不到的漏洞。这是整个产品描述中最可验证的说法，因为它点明了一种机制，而不是一个结果。

模式匹配，顾名思义，寻找的是已知的坏形态：带有受污染参数的函数调用、被拼接进查询的字符串、已知不安全的 API。它速度快、成本低，也正是传统扫描器同时以两件事闻名的原因——无论同一类漏洞出现在哪里都能捕获，以及用最终被证明不可达的发现把团队淹没。另一种方法是追踪一个值从进入系统到被使用的位置，跨越文件和服务之间的边界。真正的漏洞就藏在那里，而分析也正是在那里变得昂贵，因为工具必须保存超出单个函数所能容纳的更多上下文。

不过，请注意这句话里留了余地的措辞。可能无法检测到。当厂商拿不出可供参照的基准测试时，这才是应该使用的词；也正是出于这个原因，这项说法应当放到你自己的代码库中去验证，而不应被当作产品固有的一项特性照单全收。

对抗性验证，以及一个你可以编辑的威胁模型

第二阶段要解决的，正是每个安全团队都熟悉的误报问题。每一项发现都要先经过对抗性验证，之后才会送到团队面前。在人类看到某个发现之前，会有机制试图推翻它：证明输入实际上无法到达危险汇聚点，或者该路径在上游已有防护，或者相关代码是死代码。

同一句话的后半部分，悄然是页面上最有趣的设计决策。一个你的团队可以编辑的威胁模型，决定了什么值得标记。实际上，这把相关性的定义交到了客户’手中。一个自行决定严重性的扫描器总是略有偏差，因为严重性是依赖上下文的：内部管理工具中的一个未认证端点，与公共互联网上的同一个端点，是不同的问题，而没有供应商能知道它面对的是哪一种。允许编辑威胁模型，就是对这一点的诚实承认。

这也会带来工作量。无人维护的威胁模型会变成一种过滤器，掩盖没人想到的事情，而这与扫描器的用途恰恰相反。能从中获得价值的团队，将是那些把威胁模型当作有负责人的动态文档来对待的团队，就像他们对待运行手册一样。

补丁是输出的单位

每项发现都附带一个建议补丁，供团队审查和批准；修复上线后，Claude 会将该发现标记为已修复。这句话里包含两个主张，值得将它们分开来看。

第一点是，扫描的输出是一个变更，而不是一张工单。这就是告诉工程师他们的代码有问题，与告诉他们修正后的代码长什么样之间的区别。它压缩了安全工作中最不令人愉快的部分——把别人的代码理解得足够透彻，以便在不破坏其功能的前提下修复它——而且是为最不懂代码的人压缩的。这也是风险所在：一个看起来正确、并且因为审查者累了而通过审查的补丁，就是一个带着绿色对勾的新 bug。

第二个主张关乎闭环。Claude 会在修复上线后将发现标记为已修复，因此问题会关闭，而不是不断堆积。积压并不是检测的失败，而是记录的失败：同一个漏洞在七次扫描中被报告了七次，队列增长的速度快过任何人清空它的速度。将发现追踪到解决它的那个提交，正是这一机制让持续扫描器变得可承受，而不是令人沮丧。

Anthropic 明确指出，人类始终留在环路中，每个补丁都需要审查和批准。任何部署这一功能的人都应把这当作承重句，而不是底部的免责声明。

两个版本，同一方向

Claude Security 并非孤立问世。Anthropic 于 2026 年 10 月 15 日将 Code Review 作为全面可用产品发布，而 Claude Security 的持续扫描与修复跟踪则于 2026 年 10 月 21 日以公开测试版形式面向 Claude Enterprise 推出。合起来看，两者说明了方向：审查正从变更在最后阶段需要通过的关卡，转变为在变更编写过程中与之并行的流程。这两个日期之间相隔很短，因此应将这些产品视为关于安全工作走向的一个整体叙事来评估，而不是两个互不相关的发布。

未公布的是什么，以及本可一锤定音的那个数字

这里的未知项比宣称项还多，这对公开测试版来说很正常，而不是什么丑闻。扫描覆盖代码库的范围没有公布。扫描时长没有公布。误报率没有公布。检测基准没有公布。没有独立评估。按席位定价没有公布，支持的语言清单也没有公布。

其中，缺失的检测基准才是会改变购买决策的那一项。没有它，“能捕获模式匹配扫描器所遗漏内容”就只是一种方向性主张，无法与已列入预算的扫描器相比较。支持语言列表是第二项：在任何规模的公司中，多语言仓库都是常态；一个在三种语言上表现出色、却在另外五种语言上缺失的扫描器，会描绘出误导性的风险面图景。

这一切并不意味着产品不起作用，而是意味着评估必须由买家来完成，用买家自己的代码来做，仅靠演示是不行的。

到底该如何评估它

如果你的团队打算尝试它，有用的实验并不是一个全新仓库、里面刻意埋了一个弱点。而是一个已经有历史的仓库：去年出过事故的服务、一个带有已知漏洞且花了两周才关闭的库、一个人人都有点发怵的模块。把扫描指向它，并将它发现的内容与你们团队已经写下的发现进行比较。即使供应商尚未发布基准，对已知问题的召回率也是可衡量的，因为真实基准就在你们自己的事故跟踪系统里。

第二，关注威胁模型。如果团队做的第一件事就是关闭大多数类别以缩短队列，那就说明默认模型与你团队实际承担的风险并不匹配，此时应修正模型，而不是过滤器。第三，衡量真正重要的环节：从一个发现项出现到补丁被合并需要多长时间。这个数字属于你，可跨工具比较，也正是产品真正声称要改善的指标。

路由器放在哪里，以及不放在哪里

这个界限值得明确说明。Claude Security 是 Anthropic 的一款应用。我们既不托管它，也不销售它，更无法告诉你它在你的代码仓库中发现了什么、或没发现什么。扫描器运行在 Claude Mythos 上，而我们并不声称托管该模型。

我们做的是运行模型。一个 OpenAI 兼容端点，一个密钥，背后有 200 多个模型；提供商标价原样传递、不添加任何加价；并且当某个提供商不稳定时，可跨提供商自动故障转移。Claude Opus 5.5 就在该目录中，输入 token 每百万 $4.00，输出 token 每百万 $20.00，具有 1M token 上下文，缓存读取每百万 $0.20。这是关于我们目录的事实，而不是关于扫描器的说法。

真正相关的地方，是安全计划中并非扫描器的那部分：把上千条发现汇总成可供人工分诊的内容的内部工具，起草公告的智能体，团队想围绕自身规则构建的审查步骤。这些都是普通的模型调用，而路由器是在不硬编码某家供应商的情况下进行这些调用的合理方式。当某一步需要小模型来处理大量任务，而下一步需要更审慎的模型来做判断时，路由 DSL 就很重要；当调用位于凌晨三点运行且无人值守的流水线中时，自动故障转移就很重要。

Beta 版实际上要求你信任的是什么

撇开包装不谈，这个产品下了三个赌注。其一，能够对代码进行推理的模型，能发现模式匹配发现不了的东西。其二，一次对抗性的二次检查就足以把噪声压下去。其三，只有当补丁发布、队列随之关闭，一个发现才算完成。第三个赌注最不光鲜，却最可能是对的，因为它是关于流程的陈述，而不是关于智能的陈述。

第一个赌注是那个需要检验的。Anthropic 已经公布了机制——跨文件和仓库的数据流追踪——但没有公布任何能说明它效果如何的数字。这不是否定该产品的理由。而是应当让它运行在你已经了解其历史的仓库上，并依据你能核实的发现来评判它，而不是依据那些在演示中看起来很亮眼的发现。