https://x.com/i/article/2121621077906567168

Semgrep CEO 做客斯坦福 CS146S「当代软件开发者」：Agent 先写代码的时代，修不完漏洞，就让攻击变得更贵

斯坦福大学 CS146S「The Modern Software Developer」老师 Mihail Eric 发帖宣布，Semgrep 联合创始人兼 CEO Isaac Evans 上周来这门课做了客座讲座，并贴出了讲义。Mihail 对讲座的概括是：高调的漏洞利用和攻击会先变得更糟，然后才会好转。称 Evans 是他见过的、最认真看待这个问题的人之一。

Mihail 随后贴出的讲义是一份 47 页 PDF，封面写着「斯坦福客座讲座，2026 年 10 月」。讲座题目是「Secure coding in an agent-first world」，副标题讲的是怎样让利用软件漏洞变得更贵。Evans 给自己大约 3000 秒，分四个部分讲完。

https://drive.google.com/file/d/1RLOiH-qfAXqYNanD_7gklkF0FPYCR85i/view

Evans 在讲义里简要介绍了自己：2013 年从 MIT 本科毕业，2015 年获得硕士学位，当时的研究是为漏洞做硬件层面的缓解，对象是 RISC-V；后来在美国国防部和麻省理工林肯实验室，做二进制利用和控制流完整性；创办 Semgrep 之后，他把目标写成一句话：让利用软件漏洞变得更贵。

CS146S「The Modern Software Developer」课程详细解读看这里：

利用漏洞正在变便宜

第一部分的判断很直接：利用软件漏洞的成本正在下降。讲义列出，2025 年 Android 漏洞利用的最高赏金超过 1000 万美元。他同时写道，从 Claude Opus 4.6 开始，大模型已经很擅长找漏洞；从 Mythos Preview 开始，又很擅长写利用代码。他认为这些能力看起来是从编程能力里涌现出来的。开源权重模型大约落后五个月，也能接近这个水平，讲义举的例子是 GLM 5.3。Mythos 在讲义里指向 Semgrep 自己 2026 年 4 月的一篇博文。

他把 2026 年 10 月集中出现的一批公开漏洞称为 Black October，旁边列了若干事件名称。

他接着问：一台没法被攻破的手机，你愿意付多少钱？安全是一项很贵的功能。讲义引用 V8 博客的话：如果这些组件改用内存安全的语言，并去掉即时编译器，引擎性能会明显下降；按工作负载不同，计算密集型任务可能慢 1.5 倍到 10 倍，甚至更多。他在旁边加了一句：也许大模型能改变这一点。

漏洞修不完，就把安全做成工厂

第二部分讲今天怎样写出更安全的代码。Evans 先把防御放进一条常见流水线：设计、编码、构建和持续集成、测试、部署、运行。前面是预防，中间是检测，后面是缓解。他指出，大家都已经知道系统里有大量漏洞，问题是在这种前提下怎样保护自己。

即便扫出来的都是真漏洞，他也认为其中大约 98% 并不重要。依据是：已公开的 CVE 里，已知被实际利用的大约只有 2%。但排优先级并不简单，而且不是线性的。利用代码的质量，从概念验证到真正可被当作武器使用，差异很大；几个低危问题串起来，也可能变成严重漏洞，而大模型很擅长做这种串联。同一个漏洞在一个应用里可能无关紧要，在另一个应用里却可能是最严重的事故。

静态分析被他分成四代。第一代大约是 2000 年到 2010 年代，主要面向安全人员，开发者几乎不会去用，误报高，也难以定制。第二代大约是 2010 到 2020 年代，走进了持续集成，语言覆盖更广，开发体验更好，有时还能给出修复建议。第三代是 2020 到 2025 年，讲义里 Semgrep 把自己放在这里：面向开发者、开源，并称有超过 2000 万开发者用户（Semgrep 自报）；强调用自定义规则去找漏洞的各种变体，在控制误报的前提下尽量提高覆盖面。第四代从 2026 年开始，是大模型加上程序分析，面向 Agent。他的判断是：静态扫描和动态扫描的界限会逐渐消失，成本按用量计算，但「覆盖了多少」会变得更难定义。

所以他不认同「雇一批 Agent 把漏洞全找出来」的思路。不同模型会找出不同的漏洞，等于要全都跑一遍；攻击者可以只盯住一处，防守方却要顾全局；漏洞密度又太高，没有时间和预算修完。讲义在这里引用了 Palo Alto Networks 首席执行官 Nikesh Arora 的一句话：你没法靠把漏洞修完走到安全。只为实际发生的漏洞利用付费，比如渗透测试、漏洞赏金、专门生成利用代码的模型，可以把攻击者的激励改过来，让把漏洞告诉你，比把入口卖掉更划算。但 Evans 认为更好的做法，是付钱让 Agent 去做能降低风险的安全能力。

他的主张是建一座「安全工厂」：就像软件工厂把需求和规格变成能运行的产品，安全工厂把业务风险变成能降低这些风险的安全能力。讲义举的例子，是在整个组织里给 GitHub Actions 把工作流固定到指定的代码提交，避免后续被悄悄改掉，并指向 Semgrep 自己的一篇实践博文。

先管住 Agent，再检查它写出的代码

第三部分谈 vibe coding 带来的两类风险。

一类是 Agent 本身的行为出了问题：把敏感文件公开发到网上，误删用户目录，搞垮生产环境，甚至做出可能带来法律后果的操作。这类问题要靠沙箱来约束。讲义按实现难度和安全程度列了几层，从进程级沙箱、容器、虚拟机、微虚拟机，到独立的云环境和专用物理机。他注明，如果时间更充裕，出口流量控制和密钥处理也该一起讲。讲义另外引用了 Meta 在 Muse Agent 上的安全架构，作为业界已经公开的做法。

另一类是 Agent 写出的代码有问题，他拆成四块。供应链方面，风险包括技能包或依赖里的恶意代码、已有公开漏洞的依赖、带漏洞的内嵌代码、模型虚构出来的依赖，以及许可证污染。讲义还提到，FreeBSD 里内嵌的代码曾经和 Kerberos 有过同一个漏洞，过了 19 年才被发现。对应的做法包括：选用默认更安全的包管理器，例如给 npm 关掉安装脚本；强制使用指定的包管理器和锁文件；设置冷却期；只用可信依赖；以及采用信誉较好的技能包来源。密钥泄漏可以用开源工具或平台内置的检测来抓。可被利用的漏洞，则靠代码检查工具、开源的 Semgrep 规则，或 Claude、Codex、Cursor 等编程助手自带的安全扫描。讲义注明，后一类扫描会消耗 token。设计层面，要给 Agent 写清楚威胁模型，比如「用户只能删除自己上传的文件」，并要求它在改动认证、授权或数据存储时主动标出来，必要时先找安全团队确认。

他特别提醒：写在 AGENTS.md 里的规则，既不是一定会执行，也没有任何保证。真正能卡住 Agent 的，是沙箱，以及流程里必须通过的、结果确定的检查。

把 AI 带来的效率红利，花在预防和新代码上

第四部分讲投入方向。Evans 认为，漏洞的存活时间大致呈指数分布，问题主要集中在新代码上。代码会随着时间逐渐变安全，对越来越老的代码做重写，回报也会下降。讲义引用了 Alexopoulos 等人在 USENIX Security 2022 上的实证研究，以及 Google 的 Jeffrey Vander Stoep 和 Alex Rebert 关于从源头消除内存安全漏洞的文章。他据此说，Android 代码库过去六年的经验也支持这一点：如果只能选一边，应该先管住新代码，而不是死磕历史遗留问题。今年还有一个特别之处：软件开发的成本结构在变，新代码在全部代码里的占比会比过去高很多，预防的杠杆因此更大。

讲义用一组成本示意，把「安全工厂」画成一条自动修复回路：在编码插件里拦住问题约 0.01 美元，扫描拉取请求约 1 美元，走 Agent 工作流约 10 美元；做渗透测试约 1 万美元，而一次安全事件可能超过 10 万美元。这组数字是示意性的成本阶梯，讲义没有标明是每次扫描、每个拉取请求还是每次事件的单位，不能当成真实账单。

他的结论是，应该把 AI 带来的效率红利花在更安全的设计、语言和框架上。设计阶段，可以做更适合 Agent 的新语言和框架，也让规格能对照实现做形式化验证。编码阶段，训练 Agent 写出更少漏洞的代码，把从事故和渗透测试里学到的检查做成它必须通过的关卡，把依赖改写成更安全的语言，并删掉用不到的代码和依赖。部署和运行阶段，让 Agent 去搭建并验证运行时的防护，甚至昼夜不停地在生产服务器上做夺旗攻防演练。他最后留了一个问题：这些是否足以把攻守平衡从进攻那边扳回来？讲义以 Nat Howard 的一句话收尾，这句话后来被 Dan Geer 引用：安全永远会刚好差到还能让整个系统继续运转的那个程度。