我们消除了 NanoClaw 容器镜像中的 1,400 个 CVE

上周我们宣布了 Echo 与 NanoClaw 的合作伙伴关系，旨在扩展开源项目的愿景和安全性。在这篇文章中，我们想拉开帷幕，向您展示 Echo 的代理强化过程是如何工作的。我们如何检测 CVE？在修复任何问题之前，我们需要对图像中的实际内容有一个完整、可信的了解。我们使用几个独立的漏洞扫描器（包括 Trivy、Grype 和 Wiz）扫描和分析上游 NanoClaw 容器。以下是使用 Grype 扫描开源 NanoClaw 图像的原始结果，按严重程度排序： NanoClaw 的默认图像扫描结果 下面是它与 Grype 和 Trivy 上的可比代理运行时间（Hermes 和 OpenClaw）的比较（我们还在这个比较中添加了 NanoClaw Echo 图像 - 我们很快就会深入讨论）： 现在，让我们开始修复和 CVE 减少。第 1 步：从我们可以安全地修改的内容开始 镜像中的每个库都有自己需要解决的问题。因此，我们要做的第一件事就是将调查结果分为“安全碰撞”和“需要真正的工作”。最简单的胜利是我们知道可以在不破坏 NanoClaw 的情况下升级的库。铬就是一个很好的例子。它以向后兼容性而闻名，因此我们可以信任它们的更新并充满信心地进行升级。我们剩下的是无法修复的 CVE 和发生重大跳跃的 CVE。一旦我们剔除与 Chromium 相关的 CVE，我们仍然剩下大约 600 个漏洞需要修复。那么接下来会发生什么呢？第 2 步：需要真正研究的障碍一些升级需要主要版本跳跃，这可能无法开箱即用。在这些情况下，我们必须自己修补它并验证补丁是否确实有效，而不会破坏应用程序。请参阅下面的具体示例：Hono 的节点服务器扫描结果 - 显示 @Hono/node-server - 标记有主要版本跳转到固定版本 从表面上看，这看起来像是一个主要跳转。但当我们深入研究源代码时，我们发现该修复程序可以在与已安装的版本 1.19.14 更接近的版本中使用（即使扫描程序的漏洞数据库尚未意识到）。作为我们对开源社区贡献的一部分，我们将其添加到他们的咨询中（这是我们在 Echo 中每天执行的过程）。我们继续下一步——“无法解决”的问题。第 3 步：修补和向后移植然后你就碰壁了：其余的发现被标记为无法修复，或者发行版维护人员仅在新专业中修复，如上所述，这可能会破坏你的应用程序。对于这些问题，选择的修复策略是向后移植，这意味着从较新版本的软件包中获取补丁并将其应用到应用程序所需的旧版本。在我们的例子中，这意味着我们在最新的上游版本中找到修复程序，并直接开始处理 NanoClaw 的源代码。我们需要平衡三个主要挑战：找到正确的修复 - 了解错误在哪里，跟踪修复提交，并确认修复确实安全和完整 - 并非所有修复源都可以安全使用，因此需要进一步研究。在不破坏任何内容的情况下应用它 - 补丁必须与现有应用程序完全兼容。验证 - 兼容性、功能以及 CVE 是否已真正解决。除了应用程序依赖项之外，一切下面还有操作系统。 NanoClaw 的 Dockerfile 构建在 Debian 12 NanoClaw 的上游 Dockerfile 上 - 构建在 node:22-slim 上，即 Debian 12 Debian 12 基础映像带来了操作系统级漏洞的长尾。这就是 Echo OS 发挥作用的地方。它是 Echo 维护的 Linux 发行版，它与常见的上游发行版兼容 - Ubuntu、Debian、RHEL、Amazon Linux 等。它的每个部分都是从源代码构建的，因此我们的人工智能修补代理可以不断对其进行修补。它提供了数千个修补操作系统包，并消除了超过 110 万个 CVE。 Echo 如何进行向后移植 让我们来看看我们在 NanoClaw 项目中所做的最新向后移植之一。我们将重点关注外籍人士中的 CVE-2025-59375。此过程由 Echo 专有的反向移植代理执行。为什么我们选择 CVE-2025-59375？这是最难的向后移植——一种安全修复，不是边界检查，而是一个穿过库中间的新子系统，从较新的上游版本向下传递到我们发布的旧版本，并且上游维护者明确警告发行商不要尝试部分挑选。 CVE-2025-59375 如何被利用？攻击者发送一个小的、完全格式良好的 XML 文档，解析器会分配大量不成比例的堆。 Upstream 自己的数据：约 250 KiB 的文档导致大约 800 MiB 的分配 - 放大系数约为 3,300。结果是内存耗尽和进程死亡，或者 OOM 杀死并带走邻居。为什么向后移植修复很难？外籍人士已经有保护