TL;DR：不必恐慌，新的 Claude Code Security 产品清楚地验证了行业的发展方向。这是一个强有力的信号，展示了应用安全的重要性。如果你想要更高层次的概览，可以查看我同事的文章。这篇文章会稍微深入一些。
Anthropic 宣布了 Claude Code Security，这是内置在 Claude Code 中的一项新功能，使用 AI 扫描代码库中的安全漏洞并建议补丁。如果你最近关注安全行业，你可能已经看到了各种评论。网络安全股票正在暴跌。评论家们称这是安全供应商末日的开始。一条特别火的推文暗示 Anthropic 刚刚吃掉了整个 AppSec 行业的午餐。
而且，你看，我理解这种兴奋。演示确实令人印象深刻。Opus 4.6 在开源代码库中发现了超过 500 个以前未知的零日漏洞，包括一些经过专家审查后仍未被发现 数十年 的 bug。仅在 CGIF 库中，Claude 就通过推理 LZW 压缩算法发现了一个堆缓冲区溢出，这是传统覆盖引导模糊测试即使在 100% 代码覆盖率下也无法捕获的问题。这是一项重要的能力。
但问题是：这些热门评论只见树木不见森林。真正的故事比"AI 取代安全工具"要微妙和有趣得多。
反应忽略了什么，架构验证了什么
主流叙事似乎是："Anthropic 构建了一个可以发现漏洞的 AI，因此传统安全工具已经过时了。" 这有点像说："我们构建了一个非常好的烟雾探测器，所以消防部门已经过时了。"
发现漏洞很重要。但这不是困难的部分。
让我再说一遍，让后面的人也能听到：发现漏洞从来都不是困难的部分。
困难的部分，让 AppSec 团队彻夜难眠的部分，产生多年积压和"我们下个 sprint 再处理"对话的部分，是在规模上 修复 它们。跨越数百个代码仓库。不破坏任何东西。同时开发人员以惊人的速度发布新功能。在他们没有写过的代码中，使用他们没有选择的库，使用他们可能不是专家的语言。
如果你曾在安全团队工作过，你完全明白我的意思。工作流程大致如下：
- 安全工具发现漏洞
- 安全团队对发现进行分类和优先级排序
- 安全团队创建工单并分配给...开发人员
- 开发人员在三个 sprint 后才查看工单
- 开发人员试图理解漏洞及其上下文
- 开发人员尝试修复，可能会在此过程中引入新问题
- 安全团队重新扫描，周而复始
这就是让 AppSec 专业人员精疲力竭并让开发人员沮丧的循环。无论是否由 AI 驱动，再多的更好 扫描 都无法修复这个基本循环。你仍然在创建最终落在开发人员桌面上的工作。
Claude Code Security 看起来是一项非常酷的技术。但它是一个扫描和检测工具——它发现问题并建议补丁。这无疑是有价值的，但每个高级工程师和 AppSec 专业人员应该问的问题是：扫描 之后 会发生什么？
没人谈论的讽刺
以下是热门评论中明显缺席的部分：发现漏洞的同一 AI 模型也在制造它们。
这方面的数据令人警醒。BaxBench 是来自 ETH Zurich、UC Berkeley 和 INSAIT 的基准测试，用于评估 LLM 在安全关键的后端编码任务上的表现，发现即使是最好的模型生成的解决方案中，62% 要么不正确，要么包含安全漏洞。Anthropic 自己的 Claude Opus 4.5，作为表现最好的模型，在没有特定安全提示的情况下，只有 56% 的时间生成安全和正确的代码。
CodeRabbit 的分析描绘了类似的图景：与人类编写的代码相比，AI 生成的代码引入 XSS 漏洞的可能性高 2.74 倍，引入不安全对象引用的可能性高 1.91 倍，总体出现安全发现的可能性高 1.57 倍。
所以让我们消化一下。我们有可以在开源代码中找到 500 个零日漏洞的 AI 模型。我们也有在近一半生成的代码中引入漏洞的 AI 模型。同一技术既是问题也是（部分）解决方案。这不是矛盾；这只是我们所处位置的现实。这意味着任何严肃的安全策略都需要考虑这个等式的 两端。
你不能仅仅通过扫描来解决你的工具同时制造的问题。你需要一个在创建点防止漏洞、检测漏网的漏洞、自动修复它们、并在企业规模上治理整个流程的系统。那不是扫描器。那是一个平台。
架构实际上应该是什么样子
让我们谈谈安全工具如何实际融入现代开发工作流程，因为架构问题才是真正洞见所在。
在当今典型的企业环境中，你的安全基础设施看起来像这样：
瓶颈 始终 是从第 6 步开始的。那就是速度消亡的地方。那就是平均修复时间（MTTR）从几小时膨胀到几周到几个月的地方。而且随着 AI 辅助编码推动每位作者的 PR 增加 20%（根据 Cortex 2026 年工程基准），积压增长速度比以往任何时候都快。更多代码意味着更多 bug。相同（或更少）的安全工程师面对更多 bug 意味着队列越来越长。
但这就是 Anthropic 的公告做对的地方，即使市场反应错过了它：AI 属于修复循环，不仅仅是检测循环。突破不是"AI 可以发现漏洞"，好的扫描器多年来一直在做这件事。突破是"AI 可以足够好地理解代码来 修复 漏洞。" 这正是我们在 Snyk 一直在构建的理念。
最好的安全同时使用 AI 和确定性分析
在我介绍我们构建了什么之前，我想直接解决一个问题：这不是"确定性 vs AI"的争论。这种框架完全错过了重点。
AI（扩展）推理在某些事情上 非常出色。使用 Opus 4.6 的零日发现证明了这一点。通过在概念层面理解 LZW 压缩来发现堆缓冲区溢出？这需要传统扫描器无法实现的那种整体代码理解。复杂的业务逻辑缺陷、损坏的访问控制、跨多个文件的身份验证绕过。这些是 AI 推理真正闪耀的领域。
但 AI 推理也有记录详尽的局限性。它可能产生幻觉，自信地在实际上完全安全的参数化查询中标记"严重的 SQL 注入"，因为模型误读了数据流。它可能错过明显的问题，因为注意力在大型代码库中漂移，或者在分析过程中耗尽了上下文窗口。在安全上下文中，两种失败模式都是昂贵的：误报会侵蚀开发人员的信任，直到他们开始忽略发现，而漏报会将真正的漏洞留在生产环境中。
确定性分析、数据流分析、污点追踪、符号执行和针对精心策划的漏洞数据库的模式匹配具有相反的特征。它不会发现新的零日漏洞。但当它告诉你 UserController.java 的第 47 行存在 SQL 注入时，该发现由从源到汇的具体数据流跟踪支持。它是可重现的、可解释的和可验证的。置信度很高，因为分析是机械的而不是概率性的。
而且大多数人没有意识到的是：在 Snyk，这两种方法不是分开的轨道。我们的安全研究团队积极使用生成式 AI 来发现新的漏洞模式，当他们发现真实的东西时，他们将那个发现提炼成一个确定性检测规则，然后在整个平台推出。所以 AI 的新颖、创造性发现能力被转化为快速、可靠、运行成本低廉的检测，每个 Snyk 客户自动受益。你获得了 AI 研究的智能，而不需要支付计算成本或接受每次扫描的幻觉风险。这是两全其美：AI 一次完成艰难的发现工作，确定性分析从那时起可靠地捕获相同的模式，在我们保护的每个代码库中大规模进行。
正确的答案不是选择一种方法。正确的答案是分层使用它们。 在 AI 推理擅长的领域使用它——新颖漏洞发现、复杂逻辑 bug 和跨文件分析。在确定性分析擅长的领域使用它——已知漏洞模式、供应链风险和需要可审计跟踪的合规关键发现。然后再次使用 AI 进行修复步骤，因为从理解良好、高置信度的发现生成修复正是 LLM 擅长的任务。
真正把这一切联系在一起的是：分层不仅对 检测 重要。它对 修复 也至关重要。当 Claude Code Security 生成补丁时，该补丁是 AI 生成的代码。我们已经确定了 AI 生成代码会发生什么——BaxBench 将不安全率定为 62%，Veracode 定为 45%。所以你有一个 AI 发现漏洞，然后生成一个本身有二分之一几率引入 新 漏洞的修复。如果没有在合并提议的修复之前重新扫描它的确定性验证步骤，你就是在用自己的修复管道玩打地鼠游戏。分层方法——AI 推理 + 确定性验证 + AI 驱动的修复 + 确定性重新验证——不仅仅是一个漂亮的架构图。这是数学上唯一可行的方式。
这种架构在企业规模上有效。这正是我们一直在构建的。
这正是 Snyk 所做的（两全其美）
如果你一直在关注我们在 Snyk Studio 方面的工作，你会注意到一些事情：Claude Code Security 背后的架构愿景与我们一直在发布的产品非常相似。不同之处在于我们一直专注于整个流程，而不仅仅是扫描部分，而且我们是在一个覆盖比仅代码级分析更多表面积的平台之上构建的。
Snyk Studio：无中断的安全
Snyk Studio 将安全智能直接嵌入到开发人员已经在使用的 AI 编码工具中，如 Claude Code、Cursor、Gemini CLI、Cline 等。它实现了两个关键用例：
创建时的安全 – 当开发人员使用 AI 编码助手编写代码时，Snyk Studio 的护栏指令会在 开发人员甚至还没接受建议之前 自动拦截不安全的代码。AI 助手对新代码运行 snyk_code_scan，如果发现任何安全问题，它会直接在流程中修复它们。没有工单。没有上下文切换。没有三个 sprint 的延迟。鉴于 BaxBench 数据告诉我们的关于 AI 生成代码安全性的信息，这不是可选的；它是必不可少的。
规模化修复 – 对于现有漏洞的积压，Snyk Studio 提供修复指令，如 /snyk-fix。这将整个扫描-分类-修复-验证周期压缩成一个命令：
这里的检测层是 Snyk 的确定性分析引擎——AI 修复层可以据此行动而无需怀疑的高置信度发现。修复由 LLM 生成。你可以同时获得两者的优势。
超越代码：完整的平台
Claude Code Security 的比较真正突显了扫描源代码只是更大拼图的一块，试图在单一信号扫描器上运行企业安全程序，无论多么智能，就像只用温度计诊断病人一样。
考虑当你在同一平台上有来自多种扫描类型的发现时会发生什么。你的 SAST 引擎标记控制器方法中的潜在 SQL 注入。你的 DAST 引擎独立确认同一端点在运行时是可利用的。你的 SCA 引擎识别你正在使用的 ORM 库有一个已知的 CVE，在某些边缘情况下会绕过其参数化。单独来看，每个发现都告诉你一些信息。在一起，在同一平台上关联，它们告诉你 确切 发生了什么、为什么以及优先修复什么。
这就是当我们谈论 AI 安全织物时的意思：它不是单一工具或单一扫描类型；它是一个自适应系统，将整个软件供应链中的每个安全信号编织在一起。Snyk 自动关联 SAST 和 DAST 发现，将 Snyk Code 识别的代码级问题与 Snyk API & Web 发现的运行时漏洞连接起来，精确定位负责可利用缺陷的确切代码行。这不是通过拼接点工具获得的。这是通过让 SAST、SCA、容器扫描、基础设施即代码分析、DAST 和 API 安全都输入到同一织物、同一优先级和修复引擎获得的架构优势。
然后是安全团队实际运行其程序的企业层：跨数千个代码仓库聚合风险的集中仪表板、策略即代码治理、CI/CD 管道集成，以及让你的 CISO 能够回答"我们的风险敞口是多少？"、让你的工程 VP 能够回答"我们在 MTTR 上是否朝着正确的方向发展？"的报告，而不需要拼接六个不同供应商的仪表板。代码扫描器，即使是出色的扫描器，也无法回答这些问题。安全织物可以。
Evo：保护 AI 栈本身
还有一个 Claude Code Security 完全没有触及的安全维度：保护你的 AI 基础设施。
Snyk 的 Evo 是我们专门为 AI 原生开发环境设计的代理安全编排系统。它包括 AI 威胁建模，自动从你的代码构建实时威胁模型并标记提示注入等风险。它包括 AI 红队测试，对你的模型和代理运行持续的对抗性测试，模拟自适应攻击者并产生可验证的漏洞利用证据。它包括 AI-SPM（软件态势管理），所以你确切知道你的组织中运行着哪些 AI 模型、数据集、框架和工具，包括安全团队甚至不知道的"影子 AI"。它还包括代理扫描，对所有工具链的可见性，如开发环境中的 MCP Servers 和 Skills，以及实时护栏。
2026 年 1 月，我们的研究团队在 ClawHub 上发现了数百个恶意 skills，这是首次针对 AI 代理生态系统的主要供应链攻击。这是无论多么复杂的代码级扫描器都无法解决的威胁类型。这是一个完全不同的攻击面，它需要专门构建的工具。
这是验证，不是颠覆
这是我诚实的看法：今天的公告对安全行业意味着验证。
Anthropic，世界上资金最充足、技术最先进的 AI 公司之一，审视了他们可以用前沿模型构建的领域，决定构建一个安全扫描和修复工具。这不是巧合。这是行业发展方向——朝着直接嵌入开发人员工具的 AI 原生、代理安全工作流程——是正确方向的信号。
这与 Snyk Studio 和更广泛的 Snyk 平台背后的理念相同。最终目标不是为漏洞分类构建更好的仪表板。最终目标不是生成更漂亮的报告或更细粒度的严重性评分。最终目标是 尽可能自动修复尽可能多的漏洞，尽可能接近创建点，而不中断开发人员的流程。
不是每个 bug 都可以自动修复；有些需要架构更改，有些需要对业务逻辑权衡进行人工判断，但你的团队每天遇到的绝大多数常见漏洞模式？这些永远不应该需要 Jira 工单和三个 sprint 的等待。
这就是整个愿景。
Anthropic 在这个领域投资的事实告诉我，我们一直在构建正确的东西。这些工具是互补的：Claude Code Security 用于深度的、新颖的零日发现，Snyk 的平台用于企业大规模运行安全程序所需的全面、确定性加 AI、从预防到修复的流程。
问题从来不是"AI 应该参与安全吗？"问题始终是"你如何以可靠、全面和企业就绪的方式构建这个？"答案涉及 AI 推理 和 确定性分析，分层在一起，嵌入开发人员工具，由覆盖整个软件供应链（包括 AI 供应链本身）的平台支持。
这对你意味着什么
如果你是高级工程师或 AppSec 专业人员，这是我的实际建议：
网络安全股票抛售被夸大了。 市场正在对头条新闻做出反应，而不是架构。发现漏洞是安全程序的必要但不充分部分。真正的价值在于修复循环，这需要与你现有工具的深度集成、你可以信任的分层检测以及在企业规模上运行的能力。
尝试 Claude Code Security。 说真的。如果你正在维护开源代码或从事新颖零日发现很重要的项目，研究预览值得探索。Opus 4.6 在 GhostScript 和 CGIF 上做的事情确实具有创新性。
但在平台上构建你的安全程序，而不是点工具。 对于你的日常 AppSec 操作，你需要完整的堆栈来解决数百种已知漏洞模式、供应链风险、容器错误配置、IaC 漂移和 AI 模型治理。你需要确定性检测 和 AI 推理。你需要创建时的预防 和 大规模自动修复。你需要安全监控、仪表板和企业治理。越来越多地，你需要保护 AI 工具本身。
这就是 Snyk 所做的。它利用你的开发人员已经在使用的相同 AI 编码助手（包括 Claude Code），将它们变成可以在创建时预防漏洞并大规模修复现有漏洞的安全感知代理。它在覆盖代码、依赖项、容器、基础设施、API 和 AI 栈的平台之上做到这一点。
自己试试
评估这一理念最简单的方法是尝试它。Snyk Studio 是免费的，设置只需几分钟。这是我会开始的地方：
如果你已经在使用 Claude Code（鉴于 Anthropic 刚刚发布的内容，很有可能），Claude Code 集成指南 将指导你将 Snyk Studio 连接到你现有的工作流程。你将在大约五分钟内在终端中运行确定性扫描和 /snyk-fix 修复命令。
如果你想了解指令系统的工作原理，包括创建时安全护栏和修复指令，指令文档 是深入了解的地方。这些是可定制的，所以你可以为你的团队的特定技术栈和风险承受能力进行调整。
如果你想要平台的整体图景，Snyk Studio 产品页面 是一个好的起点，Evo 用于 AI 安全维度。
AppSec 的未来不是构建更好的扫描器。它是自动关闭检测和修复之间的循环，在规模上，不拖慢开发人员，跨越 整个 攻击面，包括 AI 栈。Anthropic 现在在这个确切方向上大量投资的事实告诉我，行业已经找到了真正的杠杆在哪里。有了 Snyk，你可以从今天开始利用这种杠杆。
电子书
从 Shift Left 到 Secure at Inception：AI 时代 AppSec 的演进
探索为什么安全必须从代码创建开始。了解 Snyk Studio 如何提供智能、自动化和护栏来治理 AI 编码，确保保护是创新的固有部分。
