Claude Security持续扫描升级：自动修复跟踪与API集成

Claude Security 正在从一次性的安全扫描转向持续守护。最新更新让它在代码仓库有新提交时自动重新扫描，并在修复上线后自动标记问题为已解决，同时开放了 API、MCP 连接器和 Webhook，方便团队把安全能力嵌入现有工作流。

从手动扫描到持续守护

过去的安全扫描往往需要手动触发，或者在固定的时间点运行，容易与开发节奏脱节。Claude Security 的持续扫描模式改变了这一点：只要仓库有新的 commit 落地，扫描就会自动跟进。这意味着开发者在合并代码后，不必再记得去跑一次扫描，安全检测成为了代码流动的自然延伸。

更关键的是修复状态的跟踪。当修复代码被合并并部署后，系统会自动将对应的安全发现标记为“已修复”，而不是让团队在仪表盘里手动清理陈旧告警。这种闭环设计减少了安全团队与开发团队之间的来回确认成本，也让安全看板更贴近真实风险状态。

API、MCP 连接器与 Webhook 的协同

此次更新中最具集成价值的部分，是同时提供了 API、MCP 连接器和 Webhook 三种接入方式。API 允许团队以编程方式触发扫描、查询结果或同步状态，适合嵌入 CI/CD 流水线或自建安全平台。

MCP 连接器则把 Claude Security 接入了 Model Context Protocol 生态，让 AI 助手或自动化代理可以直接调用安全扫描能力。对于已经在使用 MCP 工具链的团队，这意味着安全检测可以成为智能体工作流中的一个原生步骤，而不是孤立的外部服务。

Webhook 负责事件推送。当扫描完成或发现状态变化时，系统会向指定端点发送通知，团队可以据此触发告警、创建工单或更新内部系统。三种方式各有分工：API 用于主动查询与控制，MCP 用于 AI 工作流集成，Webhook 用于被动事件响应。

Model Context Protocol（MCP） 是由 Anthropic 提出的一种开放协议，用于在 AI 应用与外部工具、数据源之间建立标准化的上下文交换接口。可以把它理解为 AI 世界里的「USB-C 接口」：模型侧只需实现一次协议，就能以统一方式调用文件系统、数据库、代码仓库、安全扫描器等各种能力。MCP 采用客户端-服务器架构，AI 助手（客户端）通过 MCP 服务器暴露的工具列表获知可执行的操作，并在需要时发起调用。与传统的函数调用或插件机制相比，MCP 的优势在于跨厂商、跨工具的互操作性，使同一个安全扫描能力可以被多个智能体复用，而不必为每个 AI 平台单独适配。

Webhook 是一种基于 HTTP 回调的事件驱动集成机制。与 API 的「拉取」模式相反，Webhook 采用「推送」模式：服务方在特定事件发生时，主动向订阅者预先注册的 URL 发送 POST 请求，携带事件负载。它的核心价值在于实时性和低轮询开销——团队无需定时查询扫描状态，而是在扫描完成或发现状态变更的瞬间收到通知。工程实践中，Webhook 端点需要校验签名以防伪造、实现幂等处理以应对重复投递，并具备快速响应能力，通常先返回 2xx 再异步处理业务逻辑，避免超时导致重试。

配置、限制与成本考量

原文提到该功能涉及 setup、limits 和 cost 三个层面的信息。配置方面，团队需要将仓库与 Claude Security 连接，并设定扫描触发条件与通知渠道。限制方面，持续扫描的頻率和范围可能受到仓库规模、提交频率或套餐级别的约束，高频提交的大型仓库需要留意扫描队列的排队情况。

成本是持续扫描模式无法回避的问题。每次提交触发扫描意味着扫描次数与开发活跃度直接挂钩，活跃仓库的扫描量可能显著高于定期扫描模式。团队在启用前应评估自身的提交节奏，并结合套餐的计费方式做预算规划。原文没有给出具体价格数字，但明确将成本列为需要关注的维度。

安全扫描的成本结构通常由扫描触发次数、代码库规模（代码行数或文件数）以及扫描深度共同决定。在持续扫描模式下，扫描次数与 commit 频率正相关，因此活跃仓库的成本曲线会比定期扫描陡峭得多。常见的成本控制手段包括：对同一分支的连续提交做去抖动或合并触发、只对受影响的变更文件做增量扫描、在非关键分支上降低扫描频率或深度。团队在评估时应先统计典型周期内的提交次数与代码变更量，据此估算月度扫描量，再与套餐的计费阶梯对齐，避免因开发高峰期产生意外账单。

对安全左移实践的意义

持续扫描加上自动修复跟踪，实际上是把安全左移又推进了一步。传统左移强调在开发早期发现漏洞，但发现之后的修复确认往往仍是手工环节。Claude Security 把“发现—修复—验证”串成自动流转的链路，让安全状态跟随代码状态实时更新。

对于采用 MCP 的团队，这次更新还暗示了一种新的可能：安全扫描可以作为 AI 代理的常规能力被调用，代理在修改代码后自行触发扫描并读取结果。这种模式是否能稳定落地，取决于扫描延迟、结果准确性和成本控制的实际表现，但方向已经清晰。

安全左移（Shift Left Security） 指将安全检测活动从发布前的测试或运维阶段，提前到需求、设计、编码等开发流程的早期环节，从而以更低成本发现和修复缺陷。业界普遍引用的经验是，缺陷发现得越晚，修复成本呈数量级上升。安全左移的典型实践包括：在 IDE 中集成静态分析、在代码提交或合并请求阶段运行 SAST/SCA 扫描、在 CI 流水线中设置安全门禁，以及将安全需求纳入设计评审。持续扫描与自动修复跟踪进一步把左移从「发现」延伸到「验证关闭」，使安全状态与代码状态保持同步，减少人工核对带来的滞后。

落地建议

打算启用的团队可以先从一个活跃度中等的仓库试点，观察扫描触发频率与告警质量，再逐步扩大范围。Webhook 建议优先接入现有的即时通讯或工单系统，避免通知淹没在邮件里。如果团队已有 CI 流水线，API 方式比 Webhook 更适合做门禁控制。MCP 连接器则适合已经构建了 AI 辅助开发流程的团队，作为智能化安全闭环的一环。