--- id: "xZX3pmaB8Hk" title: "漏洞利用如今快过补丁：AI 时代的开源安全｜Patrick Smyth，Chainguard" channel: "AI Engineer" host: [] guests: ["Patrick Smyth"] date: "2026-10-28" updated: "2026-10-29" duration: "21:47" duration_seconds: 1307 source_type: "youtube" youtube: "https://www.youtube.com/watch?v=xZX3pmaB8Hk" canonical: "https://pod-exp.pages.dev/xZX3pmaB8Hk/" transcript_jsonl: "https://pod-exp.pages.dev/xZX3pmaB8Hk/transcript.jsonl" language: "zh-CN" translation: true translated_from: "en" timestamp_precision: "block" topics: ["AI 安全","开源软件","AI 智能体"] series: ["AI 与软件"] --- # 漏洞利用如今快过补丁：AI 时代的开源安全｜Patrick Smyth，Chainguard > 中文译文，由英文原音字幕翻译整理，不是官方逐字稿；引用原话请核对英文原视频。说话人标签由整理者依上下文标注，带「未确认 / 未标注 / 不确定」等字样的标签不可靠。时间戳一般为块级（所在时间块的起点），不是逐句时间；正文自带 [hh:mm:ss] 的段落除外。 **内容提要：** Patrick Smyth 认为，前沿 AI 已经提升了攻击者的能力，漏洞利用平均可能早于补丁出现，传统的 30 天修复周期因此不再可靠。他回顾了 AI 助力攻击、供应链恶意软件和“永恒的九月”式信任环境变化，并把防护面归为恶意软件、已知漏洞、零日漏洞，以及 CI/CD、开发者设备和智能体技能等侧门。建议包括软件包冷却期、加快漏洞修复、签署制品、强化开发者设备和 CI/CD，并介绍 Chainguard 的容器、源代码构建、Wolfi、Athena 与 Agent Skills 实践。 ## [0:15] 引言 · YouTube **Patrick Smyth：** 前沿 AI 改变了开源领域对风险的容忍度。我本来想给它加个副标题，比如《我是如何学会爱上原子弹的》之类的，但最后还是没用。 我是 Patrick Smyth，在 Chainguard 工作。不考虑软件供应链、也不折腾前沿 AI 的时候，我会待在 Queens。我是那种挺烦人的人，总爱去蒸桑拿。如果你来城里，可以试试几家不错的：有一家在 10th Street，从 19 世纪就开着，食物也很好；FiDi 也有一家。我知道有不少金融行业的朋友对这个话题感兴趣，所以如果你在那附近，可以去 88 Fulton 那家。 ## [0:58] 今年由 AI 助力的攻击 · YouTube **Patrick Smyth：** 好，接下来是这场演讲里比较吓人的部分。今年有几条挺“有趣”的新闻：一名 17 岁的大阪高中生用 ChatGPT 写了些脚本，从日本最大的一家网吧窃取了大约 44.25 万条记录，然后还用其中一张信用卡买了宝可梦卡。这个年纪的人可以既聪明又很傻。 FunkSec 据认为是一个来自阿尔及利亚、技术水平中等的个人组织，在过去几个月里攻击了 85 个目标。还有一个身份不明的个人利用“Cloud CoVE”（名称听写不清）攻击了 17 家机构，目标从医疗和政府部门到大型企业都有。他用云端工具写勒索信、挑选下一个目标、整理文件，当然也用来实施攻击。 这里的一个结论是：我一直觉得，AI 会让每个人的威胁等级都升一级。如果你原本是一个真正的工程师，现在就像拥有了一个团队；如果你原本就有一个团队，现在就达到了高级持续性威胁（APT）的水平。 ## [2:33] 漏洞利用如今先于补丁出现 · YouTube **Patrick Smyth：** 再给大家一个小信息：补丁发布在先，还是漏洞先遭到利用？这里说的 exploit 就是攻击，patch 则是对漏洞的修复。 在“远古时代”的 2018 和 2019 年，平均间隔是 63 天。这个平均值波动很大，但还是能说明一些问题。长期以来有个持续趋势——我想它现在还在继续，只是被别的因素盖过去了。可以把它看作数字化应用的普及：医院之类的机构突然都开始用 Python 代码。这种长期趋势推动了 2021、2022 年，可能还有 2023 年的间隔收窄。 但到了 2023、2024 年以及去年，趋势一下子反转了。是什么造成这一切，我想大家已经知道了，后面会讲。如今这个间隔变成了负 70 天：平均来说，漏洞利用攻击会在补丁发布之前到来。这一数据来自 Mandiant 的 M-Trends 报告。 ## [3:45] 为什么 30 天修复周期已经失效 · YouTube **Patrick Smyth：** Mandiant 有自己的 M-Trends 报告。过去，一个组织会盘点技术栈里的软件，用扫描器检查它们，比如 Grype、Trivy 等。Trivy 今年也不太顺。扫描后会得到若干 CVE，也就是已知漏洞，并按严重程度分为严重、高、中、低，然后交给团队处理一定数量的修复事项。这个流程本身很合理、也很好。 问题是，在一些已经发生的攻击面前，30 天简直像一百万年。你当然需要某种修复周期，因为总得按一定节奏处理漏洞，但这种安排如今效果不太好：攻击者几乎会立刻利用已知漏洞，也会主动挖掘并利用带外发现的漏洞；现在又出现了新的零日漏洞来源——咳，咳，大家也知道我指什么。像 Mythos 这样的新一代前沿模型，让原来的时间表彻底失效了。 这是我们去年遇到的另一片“乐土”。 ## [5:01] 一波又一波的供应链恶意软件 · YouTube **Patrick Smyth：** 过去这一年，我们有不少“乐子”。我不太确定该怎么形容这些事，可以把它们看成恶意软件的几波浪潮，像四骑士一样。我以前做供应链攻击主题的演讲时，会按月做一张梗图日历：每个月来一次大攻击，然后我就说“各位，几乎每个月都有一次大攻击，情况真糟”。现在要是做一张每天都有攻击的日历，也不算夸张。 这里列了四起事件，其中三起都发生在同一个月。还有 Shai-Hulud，它简直是持续不断的乐趣来源。Shai-Hulud 是起源于 JavaScript 生态的一种蠕虫，它让大家看到，大型蠕虫攻击可以做得很成功。于是现在出现了一大批模仿者，有各种 Shai-Hulud、Sandworm 模式之类的名字。Shai-Hulud 是《沙丘》里的蠕虫——蠕虫、蠕虫，真是挺机灵的。有些恶意代码也挺有意思；虽然不该因为攻击者写的注释而觉得太有趣，但他们给东西起的名字确实很逗。 Trivy 也遭到了攻击，这是一个扫描器。其余三起都发生在今年 3 月。其中还有一个听写成“LiteLLM”的项目，是给智能体用的路由器。Axios 的供应链攻击只持续了两个小时，就有 60 万次下载。 这里具体说的是恶意软件。很多供应链攻击会彼此串联，因为每个人都依赖别人的依赖项。你攻陷一个人，就可能进一步攻陷其他人。 ## [6:44] 永恒的九月 · YouTube **Patrick Smyth：** 丹麦国有些不对劲。这个说法来自《哈姆雷特》。我说的是 2000 年那部《哈姆雷特》，是一部挺奇怪的电影，大家可以回去看看。 问题在于智能体，尤其是前沿智能体。我想在场的人都知道，它们一直在加速一切。你把它们当作撒在所有事情上的盐和胡椒：它们加快了编写代码的速度，也加速了方方面面。但攻击者也在大量使用它们，周围的环境已经变化很大。 我不知道大家有没有听说过“永恒的九月”这个概念。也许是我老了，我一直对早期计算很感兴趣。从前大学有自己的网络，大家很讲礼貌，也有社区规范，整体秩序比较稳定。每到九月，新生入学，开始加入那些总在占用大学资源的网络，弄乱网络和各种东西。他们不懂原有规范，会用大写字母发言，也不懂那些合适的表情符号。 后来，“永恒的九月”就像一直持续下去一样，这种事不断发生。这既是文化问题，也是一种自然变化：原本高度互信的环境或社区，会转变成更具对抗性、低信任的环境。 ## [8:11] 软件供应链的核心问题 · YouTube **Patrick Smyth：** 换个角度来看，这就是软件供应链安全最基本的问题。它很简单，但这样想能把问题说明白：用户依赖你的基础设施和软件，借助你的技术栈开展业务，因此你对他们负有责任。 可另一方面，你又要从上游引入东西。你会尝试审核、跟上变化，但这很困难。你引入的任何一个东西，都可能危及你和你的用户。我们都处在这种两难境地里，这正是软件供应链安全的根本问题。 接下来我们会从一连串令人沮丧的坏消息，转向今年实际应该做、也必须做的事情。我先列几项建议，用来说明一个更大的重点。 ## [9:13] 今年该怎么做 · YouTube **Patrick Smyth：** 如果你在考虑软件包，就应该设置冷却期；如果你在考虑 CVE，就要比以往更快地修复；还要给制品签名——后面我会讲 SLSA 和 Sigstore，给你的制品签名。开发者笔记本电脑的运维安全也得重视，包括实体安全密钥。要考虑的事情很多。 我后面会逐项展开，但重点是：是时候认真对待这件事了。现在已经不是 2024 年，也不是 2023 年；外部环境比几年前恶劣得多。要做的事情很多，也需要花钱、会很痛苦，但有些事情应该优先做。 如果你们还在推进容器化或 CI/CD，现在正好把这些项目完成。甚至可以说，你们几乎必须完成：如果这些基础环节还没到位，之后那些越来越重要的现代化工作会很难开展。好在现在可以借助 AI 实现一些跨越式进展，所以不用太沮丧。该启动 skunk works 项目了，该把项目推进起来，也该完成黄金镜像计划等工作，并集中管理容器。 我们是谁？我们是 Chainguard。我们从 2021 年起就在思考这些问题。四位创始人创建过一些大家可能听说过的项目：Kubernetes、Sigstore、SLSA、Google Distroless 等。我们基本上就是想解决软件供应链安全问题，把它彻底消灭掉。我马上会讲一些具体做法。 ## [11:19] 四类攻击面 · YouTube **Patrick Smyth：** 有几个攻击面值得重点讨论。它们会以不同方式相互作用，但有时分开来看会更清楚。 第一类是恶意软件，比如前面提到的 Trivy、Axios 事件，这是一种攻击路径，冷却期能帮助应对。第二类是已知漏洞，也就是比较传统的安全问题。有人会说，CVE 是衡量这一类问题的单位，即“通用漏洞与暴露”。很多 CVE 确实只是噪声，但其中有一定比例非常重要、需要修复。其他噪声会让真正需要处理的问题更难被发现。已知漏洞很重要，因为它们已经进入数据库：攻击者可以把你的软件清单和漏洞数据库对照起来，找出能利用的东西。 第三类是未知漏洞，也就是零日漏洞。随着具有强大能力的前沿模型出现，这一类问题变得更加重要，比如 Mythos、ChatGPT 现在的 Daybreak，还有 Astra，在这方面也很有能力。前沿模型很擅长把许多小漏洞串联起来，拼成可利用的攻击，因此零日漏洞领域非常重要。 第四类是新出现的层面，也可以把它们看成侧向目标、软目标或攻击者进入系统的“侧门”。过去攻击者会来敲正门，发现生产代码很安全、谢绝入内；现在他们知道可以攻击 CI/CD，因为那里没多少人仔细检查，配置可能不当，还运行着很多依赖项。 他们也会攻击开发者工作站：开发者会在那里拉取东西、做准备。你给软件包设置了冷却期，可开发者的笔记本电脑有冷却期吗？没有，那就攻击开发者的电脑。他们还会攻击新出现的智能体层；变化太快，很多人甚至不知道那里发生了什么，攻击者可以投毒模型。 这些新“侧门”都是攻击者很清楚的软目标。过去一年已经说明了这一点，包括针对 macOS 的窃密程序等。这大致就是 Chainguard 看待这些问题的方式，接下来我会讲讲可以怎样应对。 ## [13:57] Chainguard 如何应对这些攻击面 · YouTube **Patrick Smyth：** 零日漏洞方面我稍后再讲 Athena。我们长期提供的一项经典方案，是不含已知漏洞的容器。迁移到这些容器后，基本上就不会有漏洞；我稍后会多讲一点。 针对恶意软件，我们有 Chainguard Libraries，直接从源代码构建。你可以从我们这里获取软件包，而不是从 PyPI、npm 或 Maven Central 获取。这会从结构上让许多攻击变得不可能，基本上就是提供替代的软件包仓库。 对付零日漏洞，我们一直在和大型银行及其他科技公司合作，并正在组建一个大型联盟，打造 Athena 这个联盟式解决方案。我们有一个信息交换中心，接收已知的零日漏洞，再把它们提供给联盟内的成员。 我们还有新的 Chainguard Actions 和 Chainguard Agent Skills，它们是经过加固的 CI/CD Actions 或智能体技能，可以直接放进你的工作流里。 至于刚才说的 CVE 这类传统问题，还有个很大的“冰山问题”：软件必须运行在某些基础设施上，但基础设施大部分并不受你控制。你运行的代码里，可能只有 2% 是你的应用代码——这是我随口给的数字，不过我觉得并不离谱，实际可能接近，也可能只有 1%。这部分是工程师自己写的应用代码，他们当然也可能在里面引入问题；但这不是我们所说的软件供应链安全。其他东西更属于我们的领域。 如果你不能控制操作系统、应用层和语言运行时，而大多数漏洞又恰好在这些层面，那么就会出现“老板让我修一个 Ubuntu 问题”这种情况：好吧，现在我们得想办法修复一堆自己控制不了的系统。Chainguard 对此的思路，是从头打造一个新的 Linux 发行版，叫 Wolfi，专门解决这个问题。 Wolfi 主要采用滚动发行模式。实际上，它没有太多独立于上游维护者代码之外的内容；我们会很快拉取上游更新，镜像每天重建一到四次。这是完全不同的做法：我们不长期停留在稳定版本上。我们也尽量保持精简，这同样有助于应对零日漏洞。 这是我们的 SLA。记住“30、16、90”——实际是 1、7、14：已知正在被利用的漏洞一天内处理，严重漏洞七天内处理，其他漏洞十四天内处理。很多团队过去根本不会处理其中不少 14 天级别的问题；在很多团队里，中危和低危漏洞无论如何都不会进入分诊流程。 ## [17:01] 给所有东西签名：SLSA 与 Sigstore · YouTube **Patrick Smyth：** 还有什么很重要？这不是产品，而是我们认为重要的一件事：SLSA 和 Sigstore。我们认为应该给所有东西签名。每当创建一个制品，就给它签名并传递出去，然后在另一端验证签名。 对于这套技术栈，Sigstore 很有用；SLSA 则是给制品附上来源证明，对它做加密签名，然后在你内部的其他流水线里验证。这是一种非常有效的零信任流水线做法，在当前环境里尤其有用。很多攻击本质上都是流水线攻击：篡改你的标签、下载页面、依赖项，或者介于源代码与用户取得制品之间的任何环节。 Chainguard Libraries 是一种新机制，有时人们不太明白它的意义。简单说，我们拿到干净的源代码。大多数攻击发生在源代码之后、制品分发之前。我们把源代码从维护者的分发页面、CI/CD 等环境中“空运”出来，像用小直升机吊走一样，放进自己的系统里完成构建，再把制品交给你。也就是说，制品是从源代码构建的。我们还会做扫描、修复和分诊等工作；不过，从源代码构建是我们比较独特的机制。 然后有人开玩笑说，Ubuntu 还没更新：“也许我该用 Wolfi 运行。”我们也有 Chainguard Actions，并且正在考虑这个领域的更多做法，目标是解决 CI/CD 已成为现代环境中主要软目标之一的问题。 你可以试用 Chainguard Actions，它可以直接放进 GitHub Actions 里，而且可以免费试用。我们也在考虑其他方式。我不确定现在具体能透露什么；本周有 Assemble London 活动，大家可以关注一下。 ## [19:17] 加固智能体技能 · YouTube **Patrick Smyth：** 我自己最近也花了很多时间做 Chainguard Agent Skills。我们会从上游第三方技能入手，在自己的流水线里对它们进行加固，再交付给你。 整个过程会经过许多确定性检查，也会经过一些非确定性、由智能体参与的步骤。我刚发布了一段有点奇怪的小视频，用类似 Minecraft 的 machinima 风格来解释这条流水线怎么运作；想看的话，可以去 R 的 YouTube 频道找找。 最近我自己做的分析发现，上游仓库里的智能体技能，大约有 5% 正在主动实施恶意行为。今年早些时候我记得这个比例大约是 20%，不过可能已经有些变化。另外，还有约 30% 到 40% 的技能存在严重的安全问题或影响，虽然开发者并非有意作恶，但仍会造成不安全后果。 在你自己的组织里，也可以上传技能进行加固，然后让组织内部的人发现并使用它们。总之，这是一个快速、粗略的概览；二十分钟…… ## [20:23] 收尾 · YouTube **Patrick Smyth：** 二十分钟大概就是新一代的闪电演讲时长，对吧？我试着讲了很多内容。希望我们还能回答一两个问题。 接下来有 Open Source Finance Forum。挺好笑的，我刚才看幻灯片时看到上面写着“Open Source Fiance Forum”（开源未婚妻论坛）。这听起来还挺有趣，我们真该办一场“开源未婚妻论坛”。不过，实际活动是 11 月 5 日举行的 Open Source Finance Forum，Chainguard CEO Dan Lawrence 会参加，还有 Athena 联盟的多位负责人。大家可以扫这里的二维码，希望它能正常工作。 我知道现场有很多金融行业的人，这个二维码会带你到我们的金融行业入门页面。也欢迎来我们的展位看看，在 23 号展位。我们躲在一根大柱子后面，很难找，所以去展览大厅里所有柱子后面找找，应该就能找到我们。 我叫 Patrick Smith。这是我的 LinkedIn，这是 Wolfie。Wolfie 是世界上最小的章鱼，非常小，也很精简。精简有助于应对零日漏洞。它只有指甲盖那么大，网上它的视频不多，这是为数不多的其中一个。我再放一会儿，希望我们还有时间回答几个问题。谢谢大家。