不用再按扫描键了：Claude Security 改成持续盯着代码、跟进修复到底

从“按一下扫描”到“一直盯着代码”

Anthropic 在 2026 年 10 月 21 日更新了 Claude Security：这款面向 Claude Enterprise 客户的公开测试版安全工具，从原来需要人手动发起的一次性扫描，变成了持续监控。做法是先做一次深度的基线扫描，之后随着代码提交不断重新扫描变化的部分；已经发现的问题会被一路跟踪，直到修复落地才标记为已解决；如果同一个问题后来又冒出来，它会自动重新打开。用 Anthropic 自己的话说，工具不再等着有人按扫描按钮，而是跟着代码走。这个变化听起来不大，但它改的是安全工具和开发节奏之间的关系：以前是“抽个时间查一次”，现在是“代码一动它就知道”。

为什么这个时点值得注意？因为它正好卡在两个趋势的交汇处。一边是智能体写代码的速度越来越快，提交频率和变更规模都在涨，一次性扫描的报告还没看完就已经过期了；另一边是安全扫描本身也在从“找漏洞”转向“管漏洞的全生命周期”——发现只是第一步，确认修复、防止复发、把结论同步到团队已有的工具里，才是真正花时间的地方。Claude Security 这次更新覆盖的正是后半程：持续扫描、修复跟踪、威胁模型、API 和 MCP 连接器、Webhook、基于角色的访问控制。单看任何一项都不算颠覆性，合在一起看，它是在把安全扫描从一个“检查动作”升级成一个“常驻服务”。

这次更新到底改了什么

先说扫描机制。团队创建一个项目，通过 Claude 的 GitHub 应用（包括 GitHub Enterprise Server）或者用访问令牌接 GitLab 等其他 Git 服务商，选好分支和范围，Claude 先跑一次深度基线扫描，之后根据每次变更的风险和复杂度定期扫描变化的部分。这里没有固定的扫描时间表：官方文档的说法是按风险和复杂度来决定扫什么、扫多深，而不是按日历定时触发。项目可以容纳多个仓库，这一点对微服务团队很关键，因为很多真正危险的问题不在单个服务内部，而在服务之间——比如后端默认信任了本应由客户端先校验的输入，单仓库扫描很难看到这种跨服务的信任假设。

再说修复跟踪。这是本次更新里对日常工作影响最大的一环。以前的流程是：扫描出一张清单，团队去修，修完之后清单的状态要靠人去核对，经常出现“其实已经修了但清单还挂着”或者“以为修了其实又复发了”的脱节。现在 Claude Security 会拿已发现的问题去对照变更后的代码：修复落地了就自动标记为已解决，不管修复是在 Claude Code 里做的还是在别的流程里做的；之后如果扫描又发现了同一个问题， finding 会自动重新打开。这个机制的价值不在于省了几次点击，而在于让“已解决”这个状态有了可信的来源：它不再是某个人在表格里打的勾，而是工具对照代码变化后给出的结论。

第三是团队知识怎么进入扫描。每个项目现在有一个知识库，团队可以在里面写部署方式、安全策略、以及那些从代码里看不出来的控制措施；Claude 还会根据代码生成一份可供团队审阅和编辑的威胁模型，后续扫描就用这份威胁模型来判断什么值得报、什么可以跳过。这个设计承认了一个现实：很多误报不是因为扫描器不懂代码，而是因为它不知道你的环境已经有什么防护。比如某类风险在你的部署层已经被网关挡住了，扫描器如果不知道这一点，就会一直报一个你永远不会去修的问题。让团队把“我们已经处理了什么”写进去，是减少无效告警最直接的办法——当然前提是团队真的去写、并且定期更新这份知识，否则它很快就会变成另一份过期文档。

发现怎么流到团队已有的工具里

安全工具最容易失败的地方，往往不是检出率，而是“报出来之后没人处理”。这次更新在这方面给了三条出路：API、MCP 连接器和 Webhook。API 可以列出和读取项目与发现、解决或重新打开发现、管理项目和仓库；个人访问令牌只能看到和改动该用户本身有权限的东西，这一点对权限管理很重要。MCP 连接器把 Claude Security 接进 Claude 和 Claude Code，工程师可以在同一个会话里拉出一条发现、问清楚它、动手修、再标记解决，不用来回切换工具。Webhook 则可以在有新发现时通知团队已有的系统。配合新增的基于角色的访问控制——谁可以看项目、谁可以分流发现、谁可以创建项目可以分开管——大团队可以把扫描开放给更多真正拥有代码的团队，而不用把项目创建权限也一起发出去。

对独立开发者和小团队来说，这套集成能力的直接意义可能有限，因为你们本来就没有复杂的安全流程。但有一个点值得借鉴：修复跟踪和知识库的思路，即使不用 Claude Security 也可以自己落地。比如给每个安全问题建一个有明确关闭标准的状态（不是“已处理”这种模糊词，而是“某次提交里哪几行改了、复测结果是什么”），以及维护一份“我们环境已有的防护”清单，让后来接手的人不用重新猜。工具可以换，状态管理和知识沉淀的方法是通用的。

价格、门槛和官方口径里的边界

先把官方给出的条件原样摆出来，避免误读。第一，适用对象是 Claude Enterprise 客户，目前仍是公开测试版，不是面向所有 Claude 用户的正式版。第二，费用方面，符合条件的组织每月可获得 25000 美元的使用额度，连续两个月，优惠适用于截至 2026 年 12 月 31 日的使用，之后按直接 token 成本计费，不收平台费——但完整条款以帮助中心为准，额度用不完是否结转、从哪个日期起算，都要以帮助中心文本为准，不能只看发布文章的一句话。第三，扫描由 Claude 全系列模型驱动，包括 Claude Mythos，而且不再要求单独加入网络验证计划（Cyber Verification Program）。第四，自 2026 年 4 月进入公开测试以来，Anthropic 称已有数千家组织用它发现了超过一百万个漏洞——这是厂商自报的发现数量，不是修复数量，也不是独立审计的结果。

还有几条边界是第三方报道和帮助中心文档里明确提醒的，发布文章本身没有展开，但对决策同样重要。第一，扫描结果具有随机性：官方文档承认，由于 Claude Security 用的是会根据每次运行调整分析的智能体，两次扫描同一份代码可能返回不同的结果。这意味着它不能被当成传统静态分析那种“同一输入必出同一输出”的确定性工具，团队在用它做门禁时要留出复核和人工判断的空间。第二，它不支持零数据保留（Zero Data Retention）配置，对数据驻留有硬性要求的组织需要先确认这一点。第三，旧项目不会自动获得新能力：已有项目需要手动迁移才能用上持续扫描和新的额度，迁移不带走 Webhook、扫描历史和定时扫描，GitHub Enterprise 项目甚至无法迁移。这些都是上线前必须核对的实施细节，不能等到迁移当天才发现。

它和 GitHub 那边的同类动作有什么不同

把 Claude Security 的这次更新放在 10 月的安全工具动向里看，会更清楚它的位置。GitHub 在 10 月 15 日把面向代码扫描告警的智能体自动修复（agentic autofix）推到了正式版：把告警交给 Copilot，智能体探索代码、提出修复、重新跑 CodeQL 验证、开一个草稿 PR 等人审。Anthropic 的路线则不同：Claude Security 本次更新的重点不是“自动修”，而是“持续盯”和“跟踪到底”——发现可以从 Claude Code 里动手修，但修复的确认和复发的 reopen 是由扫描侧来完成的。一个偏向“修的动作”，一个偏向“管的状态”。对团队来说，这两者不是二选一，而是可以互补的：自动修复解决的是“修得快不快”，持续跟踪解决的是“修完之后还算不算数”。

更深一层的区别在于扫描的哲学。传统静态分析是确定性的规则匹配：同一份代码、同一套规则，结果可复现；Claude Security 这类智能体扫描是自适应的：它会根据代码和上下文调整分析路径，检出能力可能更广，但结果的可复现性就弱了。这不是谁好谁坏的问题，而是适用场景不同：需要作为合并门禁、要求每次结果一致的检查，更适合确定性工具；需要发现跨服务、跨上下文的、规则难以覆盖的问题，智能体扫描更有优势。一个成熟团队的做法往往是两者并用：确定性工具守底线、做门禁，智能体扫描做补充、负责发现那些规则写不出来的问题。把其中任何一种当成唯一答案，都会在某类问题上吃亏。

给不同团队的落地建议

如果你已经是 Claude Enterprise 客户，并且已经在用 Claude Security，最务实的上线顺序是：先挑一个中等规模、跨两个服务的项目做试点，而不是一上来就把所有仓库都接进来。试点的前两周重点做三件事：把知识库的第一版写出来（部署方式、已有的防护、哪些告警可以直接忽略以及为什么），把威胁模型人工审一遍再让它参与后续判断，统计误报率和“已解决又复发”的比例。两周后如果误报率在团队可接受范围内、复发跟踪确实帮你们抓到了本会漏掉的回归，再扩大到更多项目。试点期间不要把它的结果直接接进合并门禁，先当成并行参考，等你们对它的随机性有了体感再谈门禁。

如果你还没有 Claude Security，但团队已经在为“扫描报告过期太快”头疼，可以先不急着买，先做一次流程体检：你们现在从发现到修复平均要几天？修复后是谁来确认关闭？有多少已关闭的问题后来又复发了、你们是什么时候才知道的？如果这三个问题都答不上来，那瓶颈可能不在扫描工具，而在修复跟踪的流程本身。先把“每个问题有明确的关闭标准和负责人”这件事立起来，再去评估工具，能省很多冤枉钱。反过来，如果流程已经清楚、瓶颈确实是扫描跟不上提交速度，那持续扫描这类产品才值得认真评估。

如果你是独立开发者或者小团队，这篇新闻的直接行动点其实很少——你们大概率不在 Claude Enterprise 的适用范围内。但可以带走两个可立即用的做法：第一，给自己的项目维护一份“已知风险与已有防护”清单，哪怕只是一个 Markdown 文件，写清楚哪些告警你已经评估过、为什么可以忽略，半年后的你会感谢现在的你；第二，对修复过的漏洞做一次“复发检查”：下次改动相关代码时，主动跑一次针对性的验证，而不是默认它一直是修好的状态。这两个习惯不花钱，但能挡住很多“以为修好了”的事故。

不能从这次更新里得出的结论

最后划三条线。第一，不能把“一百万个发现”读成“一百万个漏洞被修好了”：发现和修复是两回事，Anthropic 公布的是发现数，修复率和复发率都没有公布。第二，不能把“持续扫描”理解成“实时扫描”：官方的说法是根据风险和复杂度定期扫描变化的部分，不是每一次提交都立即全量重扫，基线扫描本身也可能需要几分钟到几小时，取决于仓库规模。第三，不能把智能体扫描的灵活性误读成确定性保证：两次扫描同一份代码可能结果不同，这意味着它适合做发现和跟踪，不适合单独作为“一票否决”的合并门禁。把这三条线守住，这次更新的价值就很清楚：它让安全状态离代码的真实状态更近了一步，但“更近”不等于“完全一致”，最后的判断仍然要留给人。

随机性这件事，团队具体该怎么应对

扫描结果可能随运行而变化，这个特点如果处理不好，会在团队里造成两种极端反应：一种是“反正每次结果都不一样，那就都不信”，另一种是“这次没报就是没问题”。两种都是错的。比较健康的做法是把智能体扫描的结论分成三档来用。第一档是“多次扫描都稳定出现、且有明确攻击路径”的问题，直接进修复队列，优先级最高。第二档是“只出现过一次、但影响面大”的问题，先人工复核一次，确认是真问题再排期，不要因为它只出现一次就忽略，也不要因为它出现过就立刻停下手头工作。第三档是“反复出现但团队已评估为环境已有防护”的问题，写进知识库并注明评估人和日期，下次再出现时直接按知识库处理，不重复争论。

另外要建立一个很简单的复发登记习惯：每次修复安全问题时，同时记下验证方法——是重新跑了扫描、写了回归测试，还是人工复核了修复提交。修复跟踪工具能自动标记“已解决”，但它标记的依据是代码变化，不是你的验证结论；两者结合起来，状态才完整。对小团队来说，这个习惯甚至比买工具更重要，因为小团队没有专职安全人员，安全状态的记忆很容易随着人员流动而丢失。一份写清楚“这个问题为什么算修好了”的记录，半年后比任何仪表盘都值钱。还有一点值得写进团队手册：当扫描结果前后不一致时，不要只保留最后一次的结果，把几次结果的差异本身也记下来，差异出现的位置往往就是代码里最脆弱、最值得人工再看一眼的地方。