五一前后，Anthropic 把 Claude Security 公测版放了出来，搭载 Opus 4.7，目前仅向 Claude Enterprise 客户开放，Team 和 Max 用户还要再等几个月。

我们在拿到完整功能介绍后做了一轮拆解。结论先放在最前面：这套工具相对 OpenAI Codex Security 几乎没有”颠覆性亮点”——但它把”AI 当安全研究员”这件事产品化、运营化的姿态非常扎实。本文从六个维度做一次深度解读，方便你判断要不要采购、要不要关注，以及——如果你在做 AI 安全产品，应该如何对照自己的产品形态。

一、既是纵火犯，也是消防员

大模型这两年的 AI for Security 故事里，一直存在一个尴尬的悖论：

LLM 既是”纵火犯”——它本身可能被滥用来生成漏洞利用、辅助 0day 编写、绕过安全产品；也是”消防员”——它在阅读代码、推理上下文、解释攻击链上的能力，又比传统静态扫描器（SAST）强得多。

Claude Security 本质上是 Anthropic 把”消防员”这一面产品化的尝试。它的思路是：

  1. 让 AI 像安全研究员一样真正去读代码；
  2. 按自己的方式验证问题（而不是只列警告）；
  3. 把漏洞、影响、复现方法、修复建议整理进一个能直接进入工程流程的界面里。

值得一提的是，它没有走外界此前猜测的 AWS Security Agent / OpenAI Codex Security 那种”威胁建模 + 沙盒验证 + 渗透测试”重型路线，而是更接近 Agent team + skill + role prompt 的组合拳——更像一个长周期 Agent，提供从发现问题、验证问题，到生成修复 PR 的安全运营化流程。

听起来不那么炫，但这恰恰是它的差异化。下面我们逐层拆开看。

二、产品定位：长周期 Agent，做的是安全运营化

要理解 Claude Security，得先把它和市场上几个竞品对齐：

类型代表产品核心定位
重型 AI 安全 AgentAWS Security Agent、（外界传闻中的）Codex Security 重型版威胁建模、沙盒攻击复现、渗透测试
AI 增强 SASTGitHub Advanced Security（Copilot 增强版）、Snyk、Semgrep + LLM在传统规则扫描上叠 LLM 解释和误报过滤
AI 安全研究员产品化Claude Security长周期 Agent，覆盖发现 → 验证 → 修复 PR → 流程集成

注意中间那一栏：GitHub Advanced Security、Snyk、Semgrep 这些产品已经在做”传统 SAST + LLM 层”，Claude Security 没有跟它们硬拼”扫得多”或”扫得快”，而是把战场拉到了代码推理深度 + 对抗性验证 + 安全运营闭环上。

这背后是一个非常现实的判断：企业里”安全告警泛滥”的痛点，从来都不是”扫不出来”，而是：

  • 扫出来的太多，分不清哪条该处理；
  • 处理一条问题要切上下文：从扫描器跳到 IDE，再跳到 ticket 系统，再跳到 PR；
  • 修完之后，告警与修复的关系无法长期沉淀，下一次扫描重复出现一样要重判一遍。

Claude Security 的核心改进，几乎全部围绕这个运营层展开：实时推理日志让分析过程可追溯；分类结果保留到 Slack/Jira/CSV 同步，让”已知风险”不重复消耗注意力；一键 Create fix 直接接到 Claude Code on Web 的会话，把上下文一并带过去。

换句话说，它做的不是”更好的扫描器”，是”让一个 AI 安全研究员持续在你的代码库上班”。

三、技术架构剖析：实时推理日志背后的 Sub-Researcher 多智能体

Claude Security 架构总览

上图是我们对 Claude Security 一次扫描内部行为的还原。点击开始扫描后，你看到的不是一个转圈的进度条，而是一份实时推理日志——这份日志非常关键，因为它把 Agent 的思考过程暴露了出来：

  1. 依赖图构建：先把整个仓库的依赖关系跑出来，相当于一份”代码地形图”；
  2. 入口点识别：识别 external-facing 接口、数据入口、特权调用边界——攻击面定位；
  3. 攻击面优先级判断：哪些路径值得继续深入调查，哪些可以略过；
  4. 并行派出多个 Sub-Researcher：每个 sub-researcher 盯住代码库的不同部分做深挖；
  5. 跨 sub-researcher 的发现合并 / 去重 / 链式推理：因为很多漏洞是多函数交互产生的，不能孤立判断。

这一套结构，其实是 Anthropic 在 Claude Code、Computer Use 上验证过的”长周期 Agent + 子 Agent 分工”的范式。把它换到代码安全场景下，Opus 4.7 在多步骤链式漏洞上的优势会被显著放大。

为什么？因为传统 SAST 工具的工作方式，可以粗略概括成”模式匹配 + 数据流追踪 + 规则集”。它擅长找的是单点问题——一行代码上的不安全调用、一个未过滤的输入。但真实世界里大量中高严重级漏洞，不是单行代码问题，而是跨两到三个函数的交互链：

HTTP handler  →  ORM 查询  →  缓存层  →  序列化输出
       ↑ 用户输入             ↑ 反序列化逻辑

这条链上单独看每一步都”合规”，但合在一起就形成一个反序列化漏洞或权限旁路。这种”链式漏洞”恰好是 grep 类工具最容易漏掉、而 LLM 最有增量价值的地方。

从工程上看，Claude Security 的几个关键设计选择都指向了这件事：

  • 每次扫描固定使用 Opus 4.7（不是更便宜的 Sonnet 或 Haiku），意味着 Anthropic 选择把推理深度放在第一优先级，而不是吞吐；
  • Effort 字段提供 Standard / Extended 两档，让用户决定愿意为更深的推理付多少 token；
  • 实时推理日志暴露 Agent 思考路径，这件事在 SaaS 安全产品里其实少见——大多数厂商更愿意把内部行为黑盒化，因为暴露过程意味着结果可被挑刺；Claude 的选择反而是通过透明度换取专业用户的信任。

值得提醒的是：实时日志是”产品形态选择”，不是”安全研究员的全部”。它解决的是”AI 在做什么”的可见性问题，但它不解决”AI 是不是真的找对了”的问题——这一点我们留到第五章再说。

四、从 Finding 到 PR：发现-验证-修复闭环的工程化

Claude Security 端到端工作流

扫完之后才是 Claude Security 真正发力的地方。它不只给你一份报告，而是一条可以直接接进研发流程的流水线。

4.1 Finding 五字段：把”安全发现”转成”可执行任务”

每条扫描结果（Finding）都有 5 个固定字段：

字段内容
Details漏洞描述与数据流追踪说明
Location文件路径与具体行号
Impact攻击者可能造成的影响
Reproduction steps如何触发这个问题的分步说明
Recommended fix建议的修复方案

外加一组元数据：严重程度、状态、类别、仓库、分支、创建时间、置信度评分。

这五个字段不是随便选的。它们对应的是一份最小可工程化的安全任务模板：研发拿到 Location 就知道改哪儿，看 Impact 就知道严重性，跑 Reproduction steps 就能本地复现，照 Recommended fix 起草补丁。置信度评分是隐藏的关键：它让分流变得可量化——置信度 ≥0.8 + severity high/critical 优先处理，<0.5 适合人工验证或附理由驳回。

4.2 四档分类：让”已知风险”不重复消耗注意力

Finding 操作面板上的分类下拉只有 4 个选项：

  • Resolution：已修复 / 即将修复
  • Not applicable：不影响本代码库
  • Handle elsewhere：由其他仓库 / 团队 / 系统负责
  • Acknowledged：已知风险，选择接受

关键设计在于：分类决策会保留到第三方集成里——同步到 Slack、Jira、CSV 导出。这意味着下次扫到同一条问题，分类结果不会丢，团队不需要重新判一遍。

这个细节看起来很小，但任何运营过 SAST 工具的人都知道：80% 的安全工具失败原因，不是扫得不准，而是告警没有”记忆”——同样的误报每周扫一次每周判一次，三周后没人再看了。

4.3 Create fix：从 Finding 到 PR 的最短路径

点击 Create fix 后，会直接跳转到 Claude Code on Web 会话，并且——上下文已经预加载完毕：涉及文件、周边代码、Impact 说明、Reproduction steps 都会一并带过去。Claude 起草修复方案，直接开一个 PR。第二次进来时，按钮变成 “Open session”，可以接着上次会话继续。

这个跳转其实是 Anthropic 自家产品矩阵的协同：Claude Security（找问题）→ Claude Code on Web（写补丁）→ GitHub PR（落地）。三个产品都用同一套 Agent 抽象，上下文在三者之间无缝传递。这件事别家做不到，因为别家没有自家的”AI 工程师”产品。

4.4 Webhook 把 AI 决策接出去

最后一公里是 Webhook：扫描完成事件、Finding 创建事件，可以推到 Slack、Jira 或企业 ITSM。这一步把 AI 的判断重新塞回人的工作流——不在 Claude Security 界面里盯着也能收到通知。

整个链路 6 步闭环：

定时任务 → Agentic 扫描 → Finding 触发 webhook
        ↓                         ↓
        Claude Code 起草补丁 ←  下游路由（Slack / Jira）
                ↓
            PR 提审 → 下一轮扫描

五、能力边界：哪些事 Claude Security 做得到，哪些做不到

Claude Security vs 主流方案对比矩阵

这是整篇文章最需要”克制营销”的一节。Claude Security 不是 银弹，它的边界很清晰——而且 Anthropic 自己的发布说明里也承认了大部分。

5.1 链式漏洞是 AI 扫描的”真正增量”

这一点是 Claude Security 相对 grep 类工具的硬优势。多步骤链式漏洞——两到三个函数之间的交互产生的问题——传统 SAST 要么需要专门写规则，要么覆盖不到。LLM 阅读代码 + 跨文件追踪的能力，让这类问题从”基本扫不到”变成”扫描器能稳定指出来”。这是 AI 挖漏洞最合理的价值所在。

5.2 业务逻辑漏洞依然难

Claude Security 启动时并不天然拥有业务上下文。它能看出来 SQL 注入、能看出来反序列化、能看出来权限边界，但它看不出来”这条接口本来就应该限制 VIP 用户每天最多调 10 次”。

除非分析师把规范文档、业务流程、不变量（invariants）也一并提供给仓库，否则业务逻辑层的漏洞——包括但不限于权限旁路、状态机不一致、风控绕过——依然是 AI 的盲区。

5.3 大模型审查结果具备随机性

Anthropic 自己承认了这一点：每次扫描的结果并不是固定不变的。同一个仓库连续跑两次，可能这次报出来 12 条问题，下次报出来 10 条。这件事的工程含义是：

  • 不能把扫描结果当 ground truth，必须有人工复审；
  • 应该用周期性扫描（夜间 / 每周）+ 多次结果合并的方式，而不是单次结果定结论；
  • 关键发布节点前的扫描，要把 Effort 调到 Extended，并接受运行时间更长。

5.4 语言覆盖不均匀

初始语言支持很广，但优先级有差异：Python、JavaScript / TypeScript、Java、Go、Rust、C、C++ 是第一梯队；Ruby、PHP、Kotlin、Swift、Scala、Lua 等次之；更小众的语言（Elixir、Clojure、Haskell、Erlang、OCaml 等）结果可能没那么稳定。如果你的核心仓库不在第一梯队，建议先小范围试用再决定。

5.5 仅支持企业版 GitHub

目前只支持 Enterprise GitHub，不支持其他代码源（GitLab、Bitbucket、自建 Gitea）；也不支持开源仓库扫描。这意味着：

  • 如果你的代码托管在 GitLab/自建系统，目前用不了；
  • 想拿 Claude Security 给开源项目做安全审计——还得再等。

六、价格、隐私与代码主权

6.1 价格逻辑

发布说明没有列单独报价。Enterprise 是企业基础费（role-based）+ token 用量计费。业内估算：处理中等规模项目，约 $400 / 月。

这个数字怎么看？

  • 美国全职 security engineer 平均年薪约 $150K，折合每月 ~$12.5K——单看人力成本对比，$400/月让 Claude Security 有非常明显的性价比；
  • 但真实成本曲线非线性。按天扫描 的成本会随扫描频率线性上升；代码库超过 100 万行 会因为依赖图构建 + 多 sub-researcher 的 token 消耗显著增加；
  • Effort = Extended 比 Standard 大概要多花 1.5-3× token 预算。

给采购方的简单算法：先按”每周一次 Standard 扫描”做基线预算，再按业务关键节点叠加 Extended 扫描的预留预算，避开”每天扫一次大单仓”的失控姿态。

6.2 隐私与代码主权

按 Enterprise 服务条款运行：代码不会用于训练未来模型，按租户隔离。这条对大多数企业够用。

但对医疗、金融、公共管理等受监管行业，如果内部约束更严格（比如要求源代码不出特定区域、不出特定网络），更稳妥的做法是：在把源代码送入模型前，加一层假名化或脱敏过滤。具体来说——把变量名、API key、数据库表名、客户端 ID 这些敏感标识做哈希替换或占位符化，再让 Claude Security 扫描，最后把发现项里的占位符还原。这样既保留了代码逻辑可读性，又不让真实标识符离开企业边界。

七、行业格局：Anthropic 的『分销战术』

Anthropic 这次没有只做”直销”，而是同时宣布了一圈合作伙伴——这份名单非常说明问题：

安全平台合作（产品集成）：

  • CrowdStrike
  • Microsoft Security
  • Palo Alto Networks
  • SentinelOne
  • Trend.ai（Trend Micro 的 AI 部门）
  • Wiz

咨询服务合作（落地交付）：

  • Accenture
  • BCG
  • Deloitte
  • Infosys
  • PwC

这两份名单几乎覆盖了整个企业安全生态的入口。背后的战略逻辑非常清楚：

  1. Anthropic 拿到分销渠道：很多企业采购安全产品时，买的是系统集成商方案而不是直接找模型供应商。CrowdStrike + Claude Security 的组合，比 Claude Security 直销更容易进入大型客户的安全采购清单；
  2. 合作伙伴拿到 AI 推理能力：CrowdStrike、Wiz 这些公司不需要自己训练前沿模型，就能把”AI 推理 + 漏洞分析”嵌进自己平台。这对它们的产品 ROI 是直接增益；
  3. 真实漏洞数据反哺生态：合作伙伴扫到的真实漏洞数据，最终会反过来滋养整个 Claude 模型 + Anthropic 安全产品的迭代——尽管不直接训练，但发现的攻击模式、误报模式都会成为 Anthropic 调整产品的输入。

从竞争格局看，AI 驱动的应用安全市场已经分成几个明显的阵营：

阵营代表产品差异化
平台原生 AI 安全GitHub Advanced Security（Copilot 增强）与 GitHub 工作流深度耦合
传统 SAST + LLMSnyk、Semgrep在已有规则集上叠 LLM 解释
AI Agent 直产品Claude Security / OpenAI Codex Security推理深度 + 端到端运营闭环
重型威胁建模AWS Security Agent（传闻中）沙盒验证 + 渗透测试

Claude Security 的最直接竞争对手，依然是 OpenAI Codex Security 和 Microsoft 生态。差异点不在”扫得多准”，而在”哪家的 Agent 推理 + 工具协同 + 工作流接入更顺”。

八、写在最后：AI for Security 的真实坐标

回到开头那个问题——Claude Security 是不是颠覆，安全公司该不该慌？

不是颠覆，是产品化。 它没有展示新的安全研究范式，没有暴露超越业界共识的能力。它把过去两年大家都在 demo 的”AI 阅读代码 + AI 找漏洞”做成了一个真正能进企业采购清单的产品形态。

但产品化本身就有价值。它意味着：

  • 门槛被打下来了：以前你需要养一个安全研究员才能拿到的能力，现在可以按月按 token 买；
  • 运营成为差异化：未来 AI 安全产品的胜负，不在模型本身，而在如何把 AI 的判断接进研发流程——Claude Security 这次给所有人画了一条新基线；
  • 细分赛道还有空间：业务逻辑漏洞、开源仓库扫描、监管行业脱敏方案、GitLab/自建源支持，这些都是 Claude Security 暂时进不去的地方，也是创业团队的机会窗。

如果你是企业安全负责人，落地 Claude Security 的 6 条建议：

  1. 先小范围试点：选一个目录或一个微服务先校准结果，再扩到全仓；
  2. 优先按周扫描：日扫成本会失控，周扫是成本与覆盖率的平衡点；
  3. 置信度阈值分流：≥0.8 + high/critical 优先处理，<0.5 人工验证；
  4. 不要直接应用自动补丁：跑现有回归测试 + 人工复审 diff 后再批准；
  5. 接 Webhook 到下游：避免告警停留在 Claude Security 界面里；
  6. 给 AI 喂业务上下文：把规范文档、不变量、关键流程图也放进仓库，能显著提升业务逻辑漏洞的命中率。

如果你是 AI 安全产品的从业者——Claude Security 没有颠覆你的产品，但它把”AI 安全研究员”的产品形态写在了纸上。下一步该做的是看你能不能在它进不去的细分领域里建立差异化。

本文参考资料：Anthropic Claude Security 公测发布说明、安多多 Claude Security 完整功能介绍（公众号原文）、Anthropic Claude Code 与 Computer Use 文档、行业分析报告。

评论