NanoClawのコンテナイメージで1,400件のCVEを排除しました

バック特集 NanoClawのコンテナイメージで1,400件のCVEを排除する方法 Eylam Milner 2026年8月4日 | 15分 特集 エージェント型セキュリティ CVE修正 会社ニュース 先週、Echoはオープンソースプロジェクトのビジョンとセキュリティを拡張するために設計されたNanoClawとのパートナーシップを発表しました。この記事では、Echoのエージェント型ハードニングプロセスがどのように機能するかを詳しく説明します。 CVEをどのように検出するか？ 何かを修正する前に、イメージに実際に含まれているものの完全で信頼できる全体像を把握する必要があります。Trivy、Grype、Wizを含むいくつかの独立した脆弱性スキャナーを使用して、上流のNanoClawコンテナをスキャンおよび分析します。以下は、GrypeでスキャンしたオープンソースNanoClawイメージの生の出力で、重大度別にソートしたものです。NanoClawのデフォルトイメージスキャン結果 そして、これがGrypeとTrivyの両方で、同等のエージェント実行時（HermesとOpenClaw）と比較した場合のスタックアップです（NanoClaw Echoイメージもこの比較に追加しました。これは後で詳しく説明します）。 さて、修正とCVE削減に移りましょう。ステップ1：安全に更新できるものから始める イメージ内のすべてのライブラリは、それぞれ独自の解決すべき問題です。そのため、最初に行うことは、検出された問題を「安全に更新できる」と「実際の作業が必要」に分離することです。簡単な勝利は、NanoClawを壊すことなくアップグレードできることがわかっているライブラリです。Chromiumはその良い例です。後方互換性でよく知られているため、アップデートを信頼して自信を持って更新できます。残ったのは、修正できないCVEと、メジャーバージョンアップが必要なものです。Chromium関連のCVEをすべて削除しても、修正が必要な脆弱性が約600件残ります。次に何が起こるのでしょうか？ステップ2：実際の調査が必要な更新 一部の更新ではメジャーバージョンアップが必要となり、おそらくそのままでは機能しません。これらの場合、自分でパッチを適用し、パッチがアプリケーションを壊さずに実際に機能することを確認する必要があります。以下に具体的な例を示します。Honoのnode-server スキャン結果 - @Hono/node-server が、修正されたリリースへのメジャーバージョンアップでフラグ付けされていることを示しています。 紙の上では、これは大きなジャンプのように見えました。しかし、ソースコードを調べたところ、インストールされているバージョン（バージョン1.19.14）よりもはるかに近いバージョンで修正が利用可能であることがわかりました（スキャナーの脆弱性データベースがまだ認識していなかったとしても）。オープンソースコミュニティへの貢献の一環として、それをアドバイザリに追加しました（これはEchoで日常的に行っているプロセスです）。次に進むのは、「修正しない」という項目です。ステップ3：パッチ適用とバックポート 次に壁にぶつかります。それは、「修正しない」とマークされている残りの検出結果、またはディストリビューションのメンテナーが新しいメジャーバージョンでのみ修正し、前述のようにアプリケーションを壊す可能性が高いものです。これらの場合、選択される修正戦略はバックポートです。これは、パッケージの新しいバージョンからパッチを取得し、アプリケーションが必要とする古いバージョンに適用することを意味します。この場合、最新の上流バージョンで修正を見つけ、NanoClawのソースコードに直接取り組み始めます。バランスを取る必要がある3つの主な課題があります。適切な修正を見つける - バグがどこにあるかを理解し、修正コミットを追跡し、修正が本当に安全で完全であることを確認する - すべての修正ソースが安全に使用できるわけではないため、さらなる調査が必要です。何も壊さずに適用する - パッチは既存のアプリケーションとクリーンに互換性がある必要があります。検証する - 互換性、機能性、およびCVEが本当に解決されたこと。アプリケーションの依存関係に加えて、すべてを支えるオペレーティングシステムがあります。NanoClawのDockerfileはDebian 12上に構築されています。NanoClawの上流Dockerfile - node:22-slim、つまりDebian 12上に構築されています。Debian 12ベースイメージは、OSレベルの脆弱性の長いリストをもたらします。ここでEcho OSが登場します。これはEchoが維持しているLinuxディストリビューションであり、Ubuntu、Debian、RHEL、Amazon Linuxなどと互換性があります。そのすべての部分はソースから構築されているため、AIパッチングエージェントによって継続的にパッチを適用できます。何千ものパッチ適用済みOSパッケージを提供し、それら全体で110万件以上のCVEを排除しています。Echoはどのようにバックポートを実行するか NanoClawプロジェクトの一部として行った最新のバックポートの1つを取り上げてみましょう。CVE-2025-59375のexpatに焦点を当てます。このプロセスは、Echo独自のバックポーターエージェントによって実行されます。CVE-2025-59375を選んだ理由 それは最も難しい種類のバックポートです。境界チェックではなく、ライブラリの中央にスレッド化された新しいサブシステムであり、新しい上流リリースから古いバージョンに運ばれ、上流のメンテナーが部分的なチェリーピックを試みないように明示的に警告したものです。CVE-2025-59375はどのように悪用される可能性がありますか？攻撃者は、小さく完全に整形式のXMLドキュメントを送信し、パーサーは不釣り合いに大きなヒープを割り当てます。上流自身の数値：約250 KiBのドキュメントが約800 MiBの割り当てを引き起こしました。増幅率は約3,300倍です。結果はメモリ枯渇とプロセス死、または近隣を巻き込むOOMキルです。バックポート修正が難しいのはなぜですか？expatはすでに増幅攻撃に対する保護（「billion-laughs」防御）を持っていました。これは、出力が8 MiBを超えると100倍の制限を強制します。しかし、そのアカウンティングは、解析された出力バイト、直接およびエンティティ展開を測定します。実際のヒープを調べることはありませんでした。そのため、エンティティ予算を快適に超えることができますが、パーサーの内部構造（ハッシュテーブル、文字列プール、DTDスキャフォールディング）は肥大化します。修正は実際の割り当てアカウンティングを導入する必要があり、それは侵襲的です。•すべての内部割り当ては、`expat_malloc` / `expat_free` / `expat_realloc` を通過するようになり、各ブロックの前に`size_t`ヘッダーが追加されるため、freeとreallocは減算する量を把握できます。これは、呼び出し元に返されるポインタを変更します。生の割り当てと追跡されたfreeをどこかで混在させると、ヒープが破損します。•メモリ関数テーブルを運んでいた構造体は、カウンターがルートパーサーに常駐するため、代わりにパーサーハンドルを運ぶようになります。これは、`dtdCreate`、`dtdReset`、`dtdDestroy`、`dtdCopy`、`hashTableInit`、`poolInit`、`copyString` のシグネチャ全体に連鎖します。•`parserCreate` には親パーサー引数が追加され、外部エンティティの子パーサーがルートパーサーの予算を請求できるようにします。厳密な初期化順序が必要です。一部のフィールドは、追跡された割り当てが発生する前に設定する必要があります。•アプリケーション側の`XML_MemMalloc`/`XML_MemRealloc`、`XML_GetBuffer`からのメイン入力バッファ、および要素宣言ハンドラーに渡されるコンテンツモデル（アプリケーションはこれを通常の`free()`で解放します）の3つのカテゴリの割り当ては、意図的に追跡をバイパスする必要があります。いずれかを間違えると、メモリが破損するか、正当なドキュメントの拒否が開始されます。何をして、最終的に何がうまくいったのか？上流の修正は、私たちが提供しているものよりも新しいexpatに対して書かれていたため、これはより高いバージョンから低いバージョンへのバックポートであり、あらゆる方向で大きいです。上流の変更は17ファイルにまたがっています。私たちの変更は、パーサーコア、パブリックヘッダー、CLIツール、ドキュメント、テストスイートにまたがる9ファイルに触れることになります。参照パッチは私たちのツリーには適用されず、適合する部分だけを着陸させると、上流が警告する状態、つまり一部の割り当ては追跡され、一部は追跡されないという状態になり、パッチを適用しないよりも悪い状態になります。うまくいったのは、適用としてではなくリベースとして扱うことでした。私たちのエージェントは、全体をエンドツーエンドで実行します。適用、ビルド、完全な上流テストスイートの実行、各障害を特定のクラスに診断、そのクラス用に構築されたフィクサーに渡す、そしてビルドと完全なテストスイートがパスするまで繰り返します。クラスは、行番号が一致しなくなったハング、変更された周囲のコンテキスト、移動または分割されたファイル、このバージョンに対してコンパイルされなくなったコード、クリーンなコンパイル後に失敗するテストなどです。それぞれに専用のフィクサーがあります。このパッチに特に関連して解決する必要があった3つのこと：1. r