Echo × NanoClaw: An under-the-hood look at our collaboration

Echo × NanoClaw: An under-the-hood look at our collaboration

Last week we announced Echo's partnership with NanoClaw, designed to extend the vision and security of the open source project. In this post, we want to pull back the curtain and show you exactly how Echo's agentic hardening process works - transparently, because it's only really open source if the source is actually open.

How do we detect CVEs?

Before we can fix anything, we need a complete, trustworthy picture of what's actually in the image. We scan and analyze the upstream NanoClaw container using several independent vulnerability scanners, including Trivy, Grype, and Wiz. Here's the raw result of scanning the open source NanoClaw image with Grype, sorted by severity:

And here's how that stacks up against comparable agent runtimes (Hermes and OpenClaw) across both Grype and Trivy (we also added the NanoClaw Echo image to this comparison - which we will dive into soon):

Now, let’s move to the fixing and CVE reduction.

Step 1: Start with what we can safely bump

Every library in the image is its own problem to solve. So the first thing we do is separate the findings into "safe to bump" and "needs real work." The easy wins are the libraries we know we can upgrade without breaking NanoClaw. Chromium is a great example. It's well known for backward compatibility, so we can trust their updates and bump with confidence. What we are left with are the CVEs that can’t be fixed, and the ones with major jumps. Once we strip out the Chromium-related CVEs, we're still left with roughly 600 vulnerabilities that need fixing. So what happens next?

Step 2: The bumps that require real research

Some upgrades require a major version jump, which will likely not work out of the box. In these cases, we have to patch it ourselves and verify the patch actually holds without breaking the app. See below, a concrete example: Hono's node-server

On paper, this looked like a major jump. But when we dug into the source code, we found the fix was available within a much closer version to what was installed, version 1.19.14 (even if the scanners’ vulnerability databases weren't aware of yet). As part of our contribution to the open source community, we added it to their advisory (it’s a process we do on a daily basis in Echo). We move on to the next step - the “won’t fix” ones. 

Step 3: Patching and Backporting

Then you hit the wall: the rest of the findings that are marked as won't fix or that the distro maintainers only fix in new majors, which as mentioned above are likely to break your app. For these, the fix strategy of choice is to backport, which means taking a patch from a newer version of the package and applying it to the older version that the app requires. In our case, that means we find the fix in the latest upstream version, and start working on NanoClaw’s source code directly. There are three main challenges we need to balance between:

• Finding the right fix - understanding where the bug is, tracing the fixing commit, and confirming the fix is genuinely safe and complete - not all fix sources are safe to use, so further research is needed.
• Applying it without breaking anything - the patch has to be compatible with the existing app cleanly.
• Validating - compatibility, functionality and that the CVE was truly resolved.

On top of the application dependencies, there's the operating system underneath everything. NanoClaw's Dockerfile builds on Debian 12

Debian 12 base images bring a long tail of OS-level vulnerabilities with them. This is where Echo OS comes into play. It's the Linux distro that Echo maintains, and it's compatible with the common upstream distros - Ubuntu, Debian, RHEL, Amazon Linux, and more. Every part of it is built from source so it can be continuously patched by our AI patching agents. It offers thousands of patched OS packages and has eliminated more than 1.1 million CVEs across them.

How Echo conducts backporting

Let’s grab one of the latest backports we did as part of the NanoClaw project. We’ll focus on CVE-2025-59375 in expat. This process is conducted by Echo’s proprietary backporter agent. On the left side you can see the reference fix, and on the right, Echo’s backporting agent suggested a fix. 

This CVE had three steps, the one below is the renaming of the XML_DTD feature guard to XML_GE in 2.6.0.

Most of the work is done by our triaging agent, with our engineers left to do the final review and approval.

Step 4: Mirroring and syncing

Once our factory verifies the results and confirms that all available upstream fixes have been applied, the image is built and pushed into the Echo store, and then synced back to NanoClaw. That’s an important note: Echo only implements official fixes. We don’t create custom patches to ensure application compatibility and safety, minimal drift from upstream, and a trustworthy process for devs using Echo OS. 

The mirroring

The Echo store can be mirrored to different registries, and in our case to a dedicated registry for NanoClaw. When a new image is published, it's automatically synced to the NanoClaw ECR within minutes. From that point on, every image is continuously monitored for newly fixed CVEs and re-pulled straight from the Echo store to the NanoClaw registry. 

The end result

So how clean does it actually get? Here's NanoClaw on Echo versus the alternatives:

We eliminated roughly 99% of the CVEs. The handful that remain are going to keep being monitored by our factory and resolved as soon as its possible.

That's the whole loop: detect with multiple scanners, bump what's safe, research the tricky ones, backport the "won't fix" findings ourselves, and keep it clean through automated mirroring.

FAQ

What is CVE backporting, and why does Echo use it?

Backporting means taking a security patch from a newer version of a package and applying it to an older version. Echo uses it when a direct upgrade would require a major version jump that risks breaking the app. This lets Echo fix vulnerabilities marked "won't fix" while staying compatible with NanoClaw's existing source code and dependencies.

Which vulnerability scanners does Echo use to detect CVEs?

Echo scans the upstream NanoClaw container with several independent scanners, including Trivy, Grype, and Wiz. Using multiple scanners produces a more complete and trustworthy picture of what's actually in the image. Echo also benchmarks results against comparable agent runtimes like Hermes and OpenClaw to show how the hardened image compares across different scanning tools.

How many CVEs does Echo actually eliminate?

Echo eliminates roughly 99% of CVEs versus the hundreds or thousands found in comparable runtimes. The handful that remain are vulnerabilities with no available upstream fix, patch, or bump. Echo stays fully upstream-compatible by design and waits for the maintainer community to release fixes.

How does the mirroring and syncing process work?

Once Echo's factory verifies all upstream fixes, the image is packaged and pushed to the Echo store, then mirrored to a dedicated NanoClaw registry. From there, every image is continuously monitored for newly fixed CVEs and re-published straight from the Echo store to keep it clean over time.