跨国深谈← 返回←AI 写代码快，黑客攻击更快：安全测试得改成全天候

AI 写代码快，黑客攻击更快：安全测试得改成全天候

关联

人物 Eli Cohen

公司 Snyk · Evo

概念 渗透测试 · 智能体 · SAST · 业务上下文 · 误报 · LLM

Eli Cohen 曾是安全公司 Helios 的联合创始人兼首席执行官，公司被 Snyk 收购后，他在 Snyk 做了两年多的 AI 产品管理，现在是创始现场首席技术官（founding field CTO），帮开发者和安全团队制定 AI 安全策略。

这场演讲里，他抛出了一组让人坐不住的数字，并给出一个核心判断：

安全测试的旧节奏已经死了，必须改成持续的、自动化的进攻性安全。

AI 让代码多了多少，又烂了多少

先看现状。

根据 Snyk 的数据，现在每个开发者产出的代码行数比过去多 218%，超过 85% 的开发者在用编程智能体——用他的话说，现场每个人大概都同时开着 5 个 Claude Code 会话。

问题在于，这些代码远不如过去安全：大模型生成的代码里，62% 存在不安全或有缺陷的问题 。

一边是代码量暴涨，一边是缺陷比例居高不下，结果就是安全问题的积压清单越来越长，修复速度根本追不上新增速度。

更糟的是，攻击者也在用同样的前沿模型。

他们能把多个低危漏洞串起来，组合成高危漏洞，尤其擅长攻击大模型最容易出错的地方——应用的业务逻辑上下文 。

AI 攻击有多快：平均 34 分钟，最快 4 分钟

Eli 给出的几个数字值得记一下：他们了解到的一个攻击组织，识别出 600 多个漏洞，攻破了 55 个以上国家的 600 多台防火墙。

一次 AI 攻击从开始到成功，平均只需要 34 分钟，最快的记录是 4 分钟 。

他的原话很形象：从我开场讲话到现在，世界上大概已经有一次 AI 攻击成功攻破了一个生产系统。另外，43% 的 MCP 服务器存在漏洞。

传统的三种安全测试，各管一段

为什么老办法跟不上？Eli 先科普了三种经典手段。

第一种是静态代码扫描（SAST）：代码提交时自动检查有没有 SQL 注入、跨站脚本这类已知问题。

便宜、快，每次代码变更都能跑，但抓不到运行时的问题——比如用户 A 能不能看到用户 B 的数据（所谓 BOLA，对象级授权失效）这种漏洞，静态扫描永远发现不了。

第二种是动态测试（DAST）：向应用的真实接口发送大量预设的攻击载荷，看会不会出问题。

它能发现授权类漏洞，但搞不定业务逻辑。

第三种就是渗透测试：一个真正理解应用业务逻辑的人类安全研究员，手动尝试攻破系统。

这是行业金标准，但有两个致命伤：贵，而且慢。所以公司通常一年只做一到两次 。

Eli 的质问很直接：剩下那 350 天没人测试你的应用，你打算怎么办？

拿到一份精美的 PDF 报告、发给开发者、等人看懂、再修复、再复测——这套流程「听起来像 90 年代的电影」。

新思路：让大模型学会渗透测试，每次提交都测一遍

Eli 介绍的方案是 Snyk 的 Evo 产品线，做持续进攻性安全。

核心逻辑是：渗透测试最大的价值在于人理解业务上下文，而理解上下文恰恰是大模型最擅长的事 。

节奏也变了：不再一年测两次，而是每次代码变更、每个合并请求都自动跑一遍渗透测试，直接告诉开发者要修什么、怎么修。

背后不是把老扫描器套个大模型外壳，而是从零构建的一组协作智能体：一个负责总调度的大脑；

一个精英情报小组负责侦察，摸清所有接口和架构；

一组专门测试漏洞的智能体，有的针对已知漏洞类别，有的自主搜寻新漏洞；

然后是一个裁判，验证每个发现的漏洞是否真的可利用——目的就是消灭误报，别让开发者白白分心；

最后还有负责给出修复建议的智能体和报告智能体 。

挑供应商时，问这四个问题

Eli 强调这些原则不限于 Snyk，可以拿去检验任何供应商。他给了四个问题：

一、它是持续运行的，还是偶尔跑一次的点状方案？二、它是否真正在推理你的应用上下文？

因为新的漏洞恰恰产生在业务逻辑里。三、它能消化多少额外的上下文数据？数据越丰富，结果越好，成本反而越低 。

四、它是只标记一个疑似漏洞，还是能证明这个漏洞真的可利用？

另外别指望单一方案包打天下：跨站脚本这类问题，动态测试仍然是最优解；业务逻辑漏洞，则要靠渗透测试补上。

本集带走

• 大模型生成的代码 62% 存在安全问题，而代码量比以前多 218%，安全债务在加速堆积。
• AI 攻击平均 34 分钟即可成功，最快 4 分钟，一年两次的人工渗透测试完全跟不上这个节奏。
• 静态扫描、动态测试、渗透测试各有所长，任何单一手段都不够，需要组合使用。
• 用大模型替代人类做渗透测试的关键在于：理解业务上下文、持续运行、每项发现都验证可利用性。
• 评估任何安全方案时问四个问题：是否持续、是否理解应用上下文、能消化多少数据、能否证明漏洞可利用。

根据我们的数据，现在每个开发者的代码行数比以前多了 218%。
According to our data, it’s 218% more lines of code per developer than it used to be before.
—— Eli Cohen · [01:49]

所以 LLM 生成的输出中有 62% 是不安全或损坏的。
So 62% of the output generated by LLMs is not secure or it’s broken.
—— Eli Cohen · [02:25]

所以我们实际上正在以一个我们根本无法修复或缓解的速度制造更多的问题。
So we are actually creating many more issues at a pace that we simply couldn’t remediate or mitigate.
—— Eli Cohen · [02:57]

所以他们能够把低危漏洞串联起来，从那些低危漏洞组合出严重漏洞。
So they are able to chain low vulnerabilities together and to form critical vulnerabilities from those low severity vulnerabilities.
—— Eli Cohen · [03:09]

突破 600 道防火墙，遍及超过 55 个国家。
to bridge 600 firewalls in more than 55 countries.
—— Eli Cohen · [03:59]

这意味着，从我开始讲话的那一刻起，外面很可能就有一个 AI 攻击成功突破了一个生产系统。
It means that since the moment I began talking, there is probably an AI tech out there that was able to successfully bridge a production system.
—— Eli Cohen · [04:25]

而且所有 MCP 服务器中有 43% 实际上存在漏洞。
And 43% of all the MCP servers actually has vulnerabilities.
—— Eli Cohen · [04:35]

所以我认为你们最需要记住的一点是——而且你们已经知道了，尤其是在座的开发人员——上下文就是一切。
So I think the most important thing you need to remember is, and you already know that, especially the developers in the room, context is everything.
—— Eli Cohen · [14:47]

你的 LLM 的表现取决于你喂给它们的上下文的好坏。
Your LLM are as good as the context that you feed them with.
—— Eli Cohen · [14:56]