上周，我们宣布Echo与NanoClaw的合作，旨在扩展开源项目的愿景和安全性。在这篇文章中，我们想揭示一下Echo的代理强化过程是如何工作的。我们如何检测CVE？在我们修复任何问题之前，我们需要对镜像中实际包含的内容有一个完整且可信的概览。我们使用多个独立的漏洞扫描仪扫描并分析上游的NanoClaw容器，包括Trivy、Grype和Wiz。以下是使用Grype对开源NanoClaw镜像进行扫描的原始结果，按严重性排序：NanoClaw的默认镜像扫描结果。下面是它与可比的代理运行时（Hermes和OpenClaw）在Grype和Trivy中的比较（我们还将NanoClaw Echo镜像添加到此比较中 - 我们将在稍后深入探讨）：现在，让我们进入修复和CVE减少的步骤。步骤1：从我们可以安全升级的内容开始镜像中的每个库都是需要解决的问题。所以我们首先做的是将发现的内容分为“可以安全升级”和“需要真正工作的”。简单的收益是我们知道可以在不破坏NanoClaw的情况下升级的库。Chromium就是一个很好的例子。它以向后兼容性而闻名，因此我们可以信任它们的更新并有信心地进行升级。剩下的就是无法修复的CVE和一些有重大跳跃的CVE。一旦我们剔除与Chromium相关的CVE，仍然有大约600个漏洞需要修复。那么接下来会发生什么？步骤2：需要真正研究的升级一些升级需要进行主要版本跳跃，这可能无法开箱即用。在这些情况下，我们必须自己修补，并验证补丁在不破坏应用的情况下确实有效。请参见下面的具体示例：Hono的node-server扫描结果 - 显示@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等。它的每个部分都是从源代码构建的，因此可以由我们的AI补丁代理持续修补。它提供了成千上万的修补操作系统包，并已消除了其中超过110万个CVE。Echo如何进行回溯让我们抓取我们在NanoClaw项目中进行的最新回溯之一。我们将重点关注expat中的CVE-2025-59375。此过程是由Echo的专有回溯代理进行的。我们为什么选择CVE-2025-59375？这是最难的回溯类型 - 一个不是边界检查的安全修复，而是一个新子系统贯穿库的中间，从更新的上游版本传递到底层我们发行的较旧版本，并且上游维护者明确警告分发者不要尝试部分挑拣。CVE-2025-59375是如何被利用的？攻击者发送一个小而完全格式正确的XML文档，解析器分配了不成比例的堆内存。上游自己数据显示：大约250 KiB的文档引发了大约800 MiB的分配 - 放大因子约为3,300。结果是内存耗尽和进程崩溃，或将邻居一起杀死的OOM杀手。为什么进行回溯修复很困难？expat已经有了保护措施。