LiteLLM v1.94.2で学ぶDockerイメージ署名検証とLLMゲートウェイの安全性

複数のLLM（大規模言語モデル）APIをひとつのインターフェースで扱う「LiteLLM」を、社内のML基盤やRAG（検索拡張生成）パイプラインの入り口として使っている方に向けた内容です。今回はv1.94.2のリリースで案内された、Dockerイメージの署名検証手順を扱います。

LiteLLMはOpenAI・Anthropic・Gemini・Bedrockなど100種類以上のLLM APIを、OpenAI互換の単一エンドポイントとして提供するプロキシです。モデルの切り替えやコスト管理、レート制限などをアプリケーション側のコード変更なしに行える点が特徴です。RAGパイプラインやエージェント基盤の共通ゲートウェイとして採用するチームも増えています。

v1.94.2自体の変更点は小さく、stable/1.94.xブランチへのバックポート2件（#35835、#35844）を取り込んだメンテナンスリリースです。機能追加や破壊的変更はありません。むしろ注目すべきは、リリースノートに明記された「Dockerイメージの署名検証手順」の案内です。

Dockerイメージ署名とは何を保証する仕組みか

LiteLLMはghcr.io/berriai/litellmとしてGitHub Container Registryにコンテナイメージを公開しています。これをそのままpullして使えますが、そのイメージが本当にBerriAI（開発元）が作ったものか、途中で改ざんされていないかは、通常のpullだけでは検証できません。

ここで使われているのがcosignです。cosignはSigstoreプロジェクトが提供する、コンテナイメージやアーティファクトに暗号署名を付与・検証するツールです。公開鍵暗号方式を使い、開発元が秘密鍵で署名したイメージを、利用者が公開鍵で検証する仕組みになっています。

たとえば宅配便の伝票に送り主の印鑑があるようなイメージです。印鑑（署名）と照合用の印影（公開鍵）が一致すれば、確かにその送り主から届いたものだと確認できます。cosign検証も同じ考え方で、イメージの中身が署名時点から変わっていないことと、署名者が正しい鍵の持ち主であることの両方を確認します。

GPGコミット署名との違いを整理する

リリースページにはもうひとつ、v1.94.2のコミット自体がGitHubの検証済み署名（GPG鍵ID: B5690EEEBB952194）で署名されている旨も記載されています。

これはコミット単位の署名で、cosignのイメージ署名とは対象が異なります。GPGコミット署名は「このコードをこの人が書いた（コミットした）」ことを保証し、cosignのイメージ署名は「このビルド済みDockerイメージが、正規のパイプラインで作られたものである」ことを保証します。

ソースコードの改ざん検知と、配布物（バイナリ相当のコンテナイメージ）の改ざん検知は別のレイヤーの話です。両方揃って初めて、ソースからビルド成果物までの一貫した信頼の連鎖（サプライチェーンセキュリティ）が成立します。

実際に検証する手順

cosignがインストールされていれば、以下のコマンドでイメージを検証できます。公開鍵の取得元にコミットハッシュを固定する方法が、公式に推奨されています。

cosign verify \
  --key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \
  ghcr.io/berriai/litellm:v1.94.2

コミットハッシュは暗号学的に不変（一度作られたら書き換え不可能）なので、これが最も強固な検証方法です。タグ名（v1.94.2）を使う簡易版も用意されていますが、タグはリポジトリ側の保護ルール（protected tags）に依存するため、コミットハッシュ指定より一段階信頼の根拠が弱くなります。

検証が成功すると、以下のような出力が返ります。

The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - The signatures were verified against the specified public key

cosign未導入の場合はHomebrew（brew install cosign）やGoのバイナリ配布から導入できます。導入自体は数分で終わる作業です。

LLM基盤の運用でこの確認が意味を持つ理由

LiteLLMのようなLLMゲートウェイは、APIキーやプロンプトログ、場合によっては社内文書をRAG検索した結果までが通過する中継点になります。ここが改ざんされたイメージに置き換わると、APIキーの漏洩やレスポンスの改ざんといったリスクに直結します。

CI/CDパイプラインでコンテナイメージをpullする際に、タグ名だけを信頼してデプロイしているケースは珍しくありません。特にKubernetesのHelmチャートやdocker-compose.ymlでlitellm:latestのようにタグ運用している場合、意図しないイメージに切り替わるリスクがゼロとは言えません。

cosign検証をCIパイプラインに組み込むことで、pull直後・デプロイ直前に自動検証するステップを追加できます。GitHub ActionsであればSigstoreのcosign-installerアクションを使い、cosign verifyをデプロイジョブの前段に挟む構成が一般的です。

今日確認できること

手元の環境がどのバージョンのLiteLLMを使っているかは、以下のいずれかで確認できます。

起動中のコンテナでdocker inspectのImageフィールドを確認する
/healthや管理UIのバージョン表示エンドポイントを確認する（LiteLLM Proxyの設定によって有無が異なります）
docker-composeやHelm valuesに書かれているイメージタグを直接確認する

併せて見直したいのは以下のポイントです。

イメージタグがlatest固定になっていないか（バージョン固定＋更新プロセスの明文化が望ましい）
CI/CDでのpull後にcosign検証のステップが存在するか
社内で他に使っているOSSコンテナイメージも同様の署名検証手段を提供しているか

バージョン番号の固定だけでなく、pullしたイメージが正規のビルド元から来たものかをcosignで検証する仕組みまで含めて、LLMゲートウェイの信頼境界を設計する視点が必要です。

まとめ

v1.94.2自体はバックポート中心の小規模リリースですが、Dockerイメージ署名検証の案内は、LLM基盤運用における見落としがちな観点を教えてくれます。

LiteLLMのコンテナイメージはcosignで署名されており、コミットハッシュ指定での検証が最も堅牢
GPGコミット署名（ソース保証）とcosignイメージ署名（配布物保証）は別レイヤーの話
CI/CDパイプラインにcosign verifyを組み込むことで、pull時点での改ざん検知を自動化できる

まずは自分の環境のdocker-composeやHelm valuesで、LiteLLMのイメージタグ指定がどうなっているか確認してみてください。バージョン固定と署名検証、両方揃えることで初めてサプライチェーンの信頼が担保されます。