CVEトリアージ危機の解決：決定論的パッケージ管理が不可欠な理由

サイバーセキュリティの情勢は変化しています。Claude Mythos のような AI モデルや Google の Big Sleep といったツールの登場により、CVE（Common Vulnerabilities and Exposures）の発見速度が加速しています。私たちは単に新しいバグを見つけるだけでなく、何十年もバージョンを超えて残存していた脆弱性を明らかにしており、AI 主導の攻撃者は前例のない速度でエクスプロイトを拡大しています。

多くの組織にとって、ボトルネックは脆弱性を見つけることだけではなく、トリアージです。新しいパッケージ CVE が公開されると、すぐに「どこが影響を受けているか？」という質問が出ます。従来の環境では、これに答えるためにすべてのアーティファクト、イメージ、ホストをスキャンする必要があります。これにより、デプロイ数が増えるにつれてすぐに管理不能になる線形スケーリングの問題が生じます。

スケーリング問題：O(n) と O(u)

従来のパッケージ管理（apt、dnf、npm などのツールを使用）では、CVE トリアージのプロセスは通常 O(n) であり、n はデプロイ数です。これらのマネージャは非決定論的であり、同じインストールコマンドでも使用するミラーやキャッシュ状態、実行時刻によって結果が変わるため、両方をスキャンしない限り二つの環境が同一であることを証明する信頼できる方法がありません。

これにより、冗長でリソース集約的なワークフローが生じます：

各環境を個別にスキャンする。
それぞれの環境で脆弱なパッケージを特定する。
各インスタンスに対してパッチを手動で検証する。

決定論で O(u) にシフトする

決定論的パッケージ管理、特に Nix と Flox を用いることで、分析単位が変わります。環境を分析するのではなく、クローザー（環境を生成するために使用されたパッケージとビルド入力の完全かつ遡及的な集合）を分析します。

Nix が入力アドレス指定のクローザーを使用しているため、二つの環境が同じ Nix ストアパスに解決されれば、暗号的に同一であることが保証されます。これによりトリアージは重複排除の問題に変わります。500 の環境（n）が 50 のユニークな依存関係セット（u）に集約される場合、高価な分析は 50 回だけ実行されます。

ワークフローはスキャンからクエリへとシフトします：

マップ：各環境をその依存関係セット（クローザー）にマッピングする。
グループ：同じ依存関係セットを持つ環境をグループ化する。
分析：各ユニークな依存関係セットを一度だけ分析する。
再利用：結果をグループ全体で再利用する。

従来のロックファイルだけでは不十分な理由

多くの開発者はロックファイル（例：package-lock.json や Cargo.lock）に依存してバージョンのドリフトを防いでいます。これらは特定のエコシステム内では有用ですが、完全な ランタイム環境を宣言的に記述したものではありません。

ロックファイルは通常、ベースイメージ、ネイティブライブラリ、システム証明書、環境変数を捕捉しません。脆弱性はしばしばこれらの遡及的依存関係に潜んでおり、誰も意図的にインストールしなかったがベースイメージやシステムライブラリによって取り込まれたものです。これがサプライチェーン攻撃が頻繁にこれらの「見えない」層を標的にする理由です。

Nix はすべてを宣言された入力を持つビルドレシピとして扱い、不可変のストアパスに永続化することでこの問題を解決します。これにより、アプリケーションレベルのライブラリだけでなく、スタック全体を網羅したクエリ可能で検証可能な依存関係グラフが生成されます。

迅速な修正への道筋

決定論的システムで脆弱性が特定されると、修正は宝探しではなくデータベース検索になります。

特定：影響を受けるパッケージを含むロックファイルまたはクローザーをクエリする。
マップ：それらの特定のクローザーを参照しているすべての環境を特定する。
更新：環境定義（例：Flox マニフェスト）を編集してパッチ済みバージョンを選択する。
展開：新しい環境参照（GitHub コミットや FloxHub の世代など）をすべての影響を受けた環境にロールアウトする。

ビルドがヘルメティックで再現可能であるため、ローカルで検証された修正は本番でも動作することが保証されます。これにより、緊急のセキュリティパッチでしばしば問題となる「自分のマシンでは動いた」不確実性が取り除かれます。

トレードオフ：ヘルメティシズム vs. 便利さ

決定論的管理がセキュリティ面でそれほど優れているのであれば、なぜ業界標準になっていないのでしょうか？答えは価値観の根本的な違いにあります。従来のパッケージマネージャは便利さと高速なビルド時間を優先します。一方、Nix は ヘルメティシズム（ビルドをホストの環境状態から完全に分離すること）を優先します。

ヘルメティシズムはコストがかかります。より多くのディスク容量が必要で、初回ビルド時間が長くなることがあります。しかし、安価なストレージと大容量帯域幅の時代において、ディスク容量のコストは壊滅的なセキュリティ侵害や冗長な O(n) スキャンに費やされたエンジニアリング時間に比べれば無視できるほど小さいです。

AI フライホイール：両刃の剣

AI コーディングエージェントがスキャンプロセスを自動化するだけで O(n) の問題を解決すると考える誘惑があります。しかし、エージェントに数百のノードを grep させることは、独自のリスクを伴う「十分に近い」セキュリティアプローチです。

さらに懸念すべきは AI の「病的なフライホイール」です。防御側がエージェントを使ってパッチを適用する一方で、攻撃側もエージェントを使ってゼロデイを発見し、スケーラブルなエクスプロイトを構築します。CVE の発見から実際の悪用までの時間窓はゼロに近づいています。このような環境では、グローバルインフラ全体で脆弱なパッケージのインスタンスを即座に特定し、ローテーションできる能力は贅沢ではなく、必須条件となります。