Newshot 
关于 Athena 的进展，以及一些不请自来的、对未来走向的预测
周六，Dario Amodei 发表了《我们必须把握前沿的节奏》。我同意他的观点。如果你还没读过，去读一读。我整个夏天都在看这些模型发现了什么，而他描述的能力与其余人准备程度之间的差距，正是我从五月起一直盯着的那道差距。
他的计划中最难的部分，是要求政府进行协调。政府处境困难：监管太少，一家美国公司可能意外造出武器；监管太多，它就会在别处被造出来；而开源无论哪种方式都无法治理。政府能行动的地方在消费端：不是模型能做什么，而是它们发现的东西会怎样。谁会最先拿到漏洞，修复多快能到达运行代码的人手里，那些无法按攻击者时间表行动的操作者是否能获得先机。这就是 Gold Eagle 要做的事。
这很重要，因为风险实际落在哪里。Dario 文章中的危险不是一个实验室里的模型。而是一个被指向电网、供水系统、医院网络的模型，所有这些都运行在积累了数十年、具有同样可利用设计的软件上。前沿是能力来源。消费端是它造成破坏的地方，而那仍然是你能够防守的一端。
所以定速有两端。前沿端是 Dario 和政府的问题，而且很难。消费端是我们的：披露流程、补丁流水线，以及软件本身，所有必须吸收模型产出的东西。定速在前沿端争取时间。这篇文章是一份状态报告，讲我们如何花掉这些时间，分三部分：
- 我们本月开始披露 Athena 的发现，从 50 个开始。
- 我们加入了 Anthropic 的 Project Glasswing，并在寻找我们自己的漏洞，我会展示那是什么样子。
- 我们构建了让这两件事成为可能的基础设施，并且我们会把它开放出来。
简短版本：我比五月时更担心，也更确定该怎么做。
前 50 个
Athena 从六月起一直在接收发现。接收数据是公开的：超过 40,000 个发现，其中 42% 为严重或
文章标题：洪水将至，管道却早已满载
正文： 对于每一个项目，若该项目没有接受旧版本修复的路径，我们会做三件事。
我们发布补丁。纯 .patch 文件，放在一个公开的 Chainguard 仓库里，仓库名字如实说明其用途，并遵循项目原始许可证。这有意不是“最后维护者”之举。我们对此有规划，下面会讲到，但那些规划针对的是已无人维护的项目。这些是活跃项目，且已经在主分支上修复了该漏洞。我们不分叉任何东西，不声称接管维护，不创建新的命名空间，也不邀请任何人基于它构建。它只是一个存放补丁的地方，供那些暂时无法升级的人使用，仅此而已。持久的修复仍然是升级，但这一步反映了当下的现实：已部署的绝大部分并没有升级。
我们发布公告。一个 Chainguard OSV feed，完整枚举受影响版本范围和确切受影响的符号。不是“某些 2.x 版本，大概吧”。Athena 合作伙伴的扫描器正在接入，因此这些信息会出现在你团队已经在看的地方。
我们交付修复。公告上线的那一刻，修复后的版本就会进入 Chainguard Libraries，面向每一位 Chainguard 客户。
我们不打算在每次发布前联系维护者。他们承受的噪音已经超出任何人应承受的量，我们不想再添一笔，尤其是对那些他们多年前就修好的漏洞。如果你是项目维护者，希望今后我们提前通知你，或者你对这件事如何涉及你的项目有任何其他顾虑，请通过 [email protected] 告诉我们，我们会乐意与你合作。
我们正在成为 CNA
静默修复过去大体无害。没人把漏洞写下来，而从修复提交中找到漏洞需要真正的专业知识和真正的时间。那个时代结束了。一个模型可以在一个下午之内，从一个公开的修复提交出发，针对每一个从未获得该修复的版本构造出可用的漏洞利用。无论我们是否发布，发现已经存在。唯一的问题是防御者是否也能拿到一份。
一旦人们知道了某个漏洞，世界就需要一个升级信号，而世界已有的信号就是 CVE。扫描器、KEV 以及每一种合规体系都以它为准。静默修复则什么都没有。因此，为支持 Gold Eagle 计划，并与 CISA 合作，Chainguard 正在申请成为 CVE Numbering Authority，范围限定为通过 Athena 处理的开源漏洞，且上游已修复该缺陷但未分配标识符，或已无维护者可分配标识符，且没有更具体的 CNA 覆盖该项目。
令人不适的部分：这会在你的扫描器中加入新的噪音。上周扫描干净的旧版本将会亮起。这比没有噪音然后被入侵要好。那个渠道里的沉默从来不是安全，只是还没有人去看而已。
我们还竭尽全力让每条公告尽可能窄。每一条都补充了每个发布分支上确切的引入和修复范围，而不是单一版本下限，并带有模块、类和函数级别的细节，说明实际受影响的内容。这正是可达性扫描器过滤掉你代码库中误报所需要的，因此你看到的噪音应该是有意义的噪音。
窄是关键。我们只在上游无可推诿时才分配。如果漏洞存在于最新版本且维护者可联系，则由项目自己的 CNA 分配，而我们是报告者，绝不是分配者。每次分配都要通过同样的关卡：可复现的发现，绝不是原始模型输出；站得住脚的提交范围；实际在用的受影响版本；通知维护者并给予响应窗口；以及若维护者证明我们错了则撤回。成为自己 CNA 的项目会离开我们的范围。这是一个过渡性角色，而非领地性角色。
其余部分去向
写作 {{NAME_ab12cd34}} 形式的值是真实值的占位符。请完全按原样使用它们，在回复和工具调用中都一样：它们会在任何内容运行之前被替换为真实值。不要要求验证它们，也不要用示例替换它们。
其余一切的地图很简单。如果某个漏洞在最新版本中存在，而维护者又能联系上，那就是 A 计划，走 Akrites——那是 Linux Foundation 于 6 月成立、我们也参与创立的共享披露机构。如果漏洞存在于最新版本，而项目无人维护，那就属于 maintainer-of-last-resort 的地界，我们正与其他 Akrites 成员合作，把它建在 Akrites 内部，它本就该在那里。至于 Gold Eagle——6 月行政命令催生的联邦信息交换中心——则是把优先级的发现送到关键基础设施运营者面前的那一层，那些人没法按攻击者的时间表行动。
我们花了夏天很大一部分时间等着这两者，并帮着把它们建起来。Akrites 本月投入运行。关于取舍我会直说：一个横跨数十家组织的共享事件响应团队，起初会比各自为战更慢。这就是选择「维护者只面对一个可信的对口方」而不是「维护者面对三十个陌生人」的代价，而我们还会再做一次同样的选择。披露和向上游回传的数字无论如何都会公布，好不好看都得公布。
一个模型在一个下午就把它们全找了出来
我担心的第二个原因，与其说关乎流程，不如说关乎我亲眼所见。我们加入了 Anthropic 的 Project Glasswing。到现在，很多组织都加入了，15 个以上国家里大约 200 家，所以我们的加入本身不算新闻。重要的是这对 Athena 意味着什么：我们现在有了 Mythos，并且正拿它来对付我们自己开发和交付的软件。
这里是一次运行的大致情形，我选它是因为它是我们手上最不让人安心的结果。
一个被广泛使用的开源项目。一次运行，大约六小时。harness 带回了十几个已验证的漏洞，其中大多数是预认证远程代码执行，无需任何凭据、无需操作者动作即可触达。每一个在计入之前，都要在干净的 VM 里复现三次，依据是我马上要讲的那条规则：模型无权声称一项发现，必须由主机复现。这不是一个被遗弃的包。它是整个生态里被扫描、测试和模糊测试最密集的项目之一，其代码经受住了多年专家审查和不知疲倦的模糊测试。一个模型在一个下午就把它们全找了出来。这些会像其他人的发现一样走 Akrites，关于具体是哪个项目，我在这里不会再多说。
那就说我愿意说的吧。看着这些模型找到了什么，以及一旦它们找到之后，修复要多久才能到达任何人手里——这才是让我担心的。不是模型本身。而是两个时钟之间的赛跑。在一个时钟上，整个行业正试图通过本就落后的披露流程，去消化短期内涌来的一大批发现。在另一个时钟上，攻击者的能力正朝着一个点推进：大规模攻陷关键基础设施会变得廉价。眼下，第二个时钟跑得比第一个快，而我看不到有任何东西能靠自己弥合这道差距。
沙箱与沙箱化
文章标题：洪水将至，而管道早已满溢
正文： 这也是沙盒之所以重要的另一个原因。产出像上面那样的发现，意味着要针对真实代码构建并反复引爆一个可用的漏洞利用，整个过程由一个没有人实时盯着看的 agent 驱动。这样做运行起来很危险，而今年夏天已经出现了一连串人们不安全地运行它的例子。Dario 围绕其撰写文章的那起事件——OpenAI 的 agent 突破了某次网络安全评估，最终进入了 Hugging Face 的生产基础设施——起因是提供給这些 agent 的包缓存中存在一个零日漏洞。包基础设施正是我们所构建的东西，所以那件事离我们很近。Pillar Security 在七月花了一周时间发布了一系列沙盒逃逸案例，涉及 Cursor、Codex、Gemini CLI 和 Antigravity，而把它们联系起来的发现是：agent 几乎从来不是正面攻破沙盒的。它写了一个它被允许写的文件，然后沙盒外某个受信任的东西稍后执行了它。这些都不是沙盒不够多的问题，而是沙盒化不够的问题：边界是存在的，而所有有趣的事情都发生在它周围的缝隙里。拒绝列表的遏制效果并不比容器更好。
Athena 所做的一切，从开发漏洞利用到证明补丁堵住了漏洞，都运行在 microVM 里——与我们多年来用于包构建、镜像构建和 CI 的同一原语。Matt 在七月详细写了这套架构。简版：每个任务获得一个硬件虚拟化的客户机，拥有自己的内核和从零构建的根文件系统，出口流量在 hypervisor 层强制执行，且仅允许列表到包注册表，别无其他，第一个被禁止的连接就会销毁该 VM，并且任何凭据都不会进入客户机。而且由于共享原语会放大任何弱点的爆炸半径，我们让 AI agent 直接针对沙盒本身，并指示它们去攻破它。每个发现都先落为一个失败的测试，然后是修复。
测试框架始于一个人
在这些沙盒内运行的测试框架是我觉得最有趣的部分，而它始于一个人。Ian Beer 花了大约六个月编写一条零点击 iOS 漏洞利用链，如果你把那篇记录当作一次搜索来读，你能看出它的形状：戳一个目标，深入，撞上死胡同，回退，最终连接足够多的点以达成可用的漏洞利用。没有人类能把六个月的这种工作保持在短期记忆里。他把它保存在笔记中，每次工作会话时拉出他需要的那一片。他的笔记本就是环境。
这就是我们所构建的，分片并行地分布在许多 agent 上：一种树搜索，每个 agent 都带着一个限定范围和一份已知信息的精炼轨迹从零开始，连续性存在于持久化的发现中，而不是任何人的上下文窗口里。我最在意的规则是：由宿主投出裁决票，永远不是模型。一个发现只有在宿主能够针对一个干净实例重放它时才算数：检查之前失败，重放运行，检查之后通过。在现实同意之前，什么都不会进入记录，而这一条规则正是误报率能如此之低的主要原因。
如果你在做类似的事情，以下是我们在构建过程中学到的几点：
- 新鲜上下文，有界任务。每个 agent 都带着一个限定范围从干净状态开始。连续性存在于为陌生人写的发现中，而不是转录记录里。
- 每次写入都以证据为门槛。如果没有前置条件、后置条件和宿主可运行的重放，它就不会进入记录。
- 研究负责引导，不负责证明。它决定 agent 接下来看哪里，永远不算作发现。
- 把死胡同也记录为发现。误报会与现实碰撞，并自行枯竭。漏报则是无声的、永久的，而正是这种失败真正让你失去深处的 bug。
洪水将至，而管道早已满载
- 品味胜过集群规模。在这样一次搜索中，模型对每一步该往哪里看的判断是指数的底数，而并行只出现在对数内部。你无法靠更多智能体来弥补更差的品味。这就是我们想要 Mythos 的具体、非营销层面的原因，也是为什么 Glasswing 比你能运行多少智能体更重要。
把各块拼起来，循环就闭合了。发现、遏制、修复、交付。全都建立在一个原语上。
我们为此构建了什么，以及我们将开放什么
这些在现成基础设施上都不可能实现。过去一年，我们在三个新原语上重建了我们的工厂，而每一个原语最初都是我们自己需要的东西，之后才成为可以出售的东西。
沙箱就是你刚刚读到的 microVM：隔离边界，让我们可以运行不可信代码和恶意智能体，而爆炸半径不会触及任何重要事物。harness 就是在其中运行的搜索，就是发现了那些预认证 RCE 的东西。第三个是作为函数的 CI：一年前，我们自己的集群就不再向 CI 系统发送代码了。检查在循环中运行，变更到达时已经被证明，所处理的 CVE 数量是我们此前处理量的十倍以上。
我们构建这三者，是因为不得不这样做；我们整个运营一直运行在它们之上，而在接下来的几个季度里，我们将开始直接开放它们。如果你正在运行不可信 AI 工作负载，或试图在你自己的代码中发现真实漏洞，或被 CI 淹没而它告诉你的比你希望知道的更少，这些就是我们伸手去用的工具。很快你也能伸手去用它们。
那么这里的终局是什么？
以下是一个不请自来的预测。现在每个人都在担心 Mythos 零日漏洞，而在这一切开始之前，几乎没有人跟得上普通 CVE。中位水平的企业在那些多年来已有修复、公告和扫描器覆盖的补丁上落后数月。这就是我们即将注入成千上万新发现的系统。更快的披露和更快的打补丁只帮助那些能据此行动的人，而世界上大多数无法以模型设定的速度行动。如果要从这篇文章里带走一件事，那就带走这个：洪水将至，而管道早已满载。
这就是为什么上述一切都不是终点线。这篇文章里的一切都让我们更快，而这一切都接受了一个注定失败的前提：目标是跟上由前沿模型设定的发现速度。那些模型利用的漏洞类别不是当今软件的缺陷。它们是它的设计。内存损坏、反序列化、注入、混淆代理：每个企业应用之下的技术栈如何构建的后果。你无法靠打补丁摆脱一种架构。
所以终局是新的基础：一个从构造上就是安全的技术栈，主要漏洞类别从一开始就无法被写出来，扮演 Spring Boot 今天扮演的角色，覆盖每一种企业语言，位于框架及其拉取的注册表之下。四十年来，迁移成本保护了每一个在位平台。没有人重写 COBOL，因为没有人负担得起。智能体直接把这项成本压塌了。
我们正在做这件事，等有更多可说的时我会说更多。为什么是我们：我们比几乎任何人都更早看到世界上披露前的发现，所以我们知道哪些缺陷类别重要，而且我们拥有唯一能证明某个基础已移除它们的工具。在交付前把 Mythos 指向它，你就知道了。
洪水将至，而管道早已满载
Dario 说得对，节奏控制能争取时间，而以上所有内容就是我们如何利用这段时间。但一个有节奏控制的前沿，只有在底层软件能挺过我们已有的前沿时才有意义。如果主流的漏洞类别无法被编写出来，建立在其上的关键基础设施就不会被它们攻破，而落入坏人之手的前沿模型能触及的东西也会少得多。节奏控制通过放慢能力来限制风险。基础通过拿走目标来限制风险，而这是我所看到的唯一一种能终结跑步机、而不是在跑步机上跑得更快的版本。
《程序员的信条》说，我们做这些事不是因为它们容易，而是因为我们开始时以为它们会容易。这是第一个我甚至都没这么认为的。我们还是要做。
如果你维护着其中任何内容所触及的项目，或者你正在发现漏洞，请加入 chainguard.dev/athena。如果其中任何内容听起来像是你想构建的东西，我们正在招聘。