LiteLLM v1.94.0-dev.3 のリリースノートには、Docker イメージの署名検証手順が明記されています。多くのリリースノートでは変更点の列挙にとどまりますが、このリリースはサプライチェーンセキュリティ（ソフトウェアの配布経路を改ざんから守る仕組み）の観点で注目に値します。CI/CD パイプラインで外部 Docker イメージを利用するチームは、この検証ステップをどこに組み込むかを考える必要があります。
cosign による署名検証の仕組み
cosign は Sigstore プロジェクト（Linux Foundation が主導するオープンソースのソフトウェア署名基盤）が提供するツールです。Docker イメージに対してデジタル署名を付与・検証する機能を持ちます。従来の GPG 署名と異なり、公開鍵を Rekor（Sigstore の透過性ログサーバー）に記録するため、署名の事実そのものが改ざん困難な形で残ります。
LiteLLM のすべての Docker イメージは、コミットハッシュ 0112e53 で導入された同一の公開鍵で署名されています。検証には 2 つの方法があります。1 つはコミットハッシュを使う方法、もう 1 つはリリースタグを使う方法です。リリースノートでは前者を「推奨」としています。その理由は、コミットハッシュが暗号的に不変（一字でも変われば別のハッシュになる）であるのに対し、タグは Git の仕様上、後から付け替えが可能だからです。
# コミットハッシュを使った検証（推奨）
cosign verify \
--key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \
ghcr.io/berriai/litellm:v1.94.0-dev.3成功すると「cosign claims were validated」「signatures were verified against the specified public key」の 2 行が出力されます。このコマンドが CI ステップで失敗した場合、そのイメージは署名された時点から改ざんされている可能性があります。
CI/CD パイプラインでの位置づけ
署名検証を手元で一度実行するだけでは、継続的な品質保証にはなりません。パイプラインの中で「イメージを pull する前に検証を通過させる」ステップとして組み込むことで、初めて意味を持ちます。
GitHub Actions を例にすると、次のような順序が考えられます。
- ワークフローの冒頭で cosign をインストール（`sigstore/cosign-installer` アクションが利用可能）
- pull 前に cosign verify を実行し、終了コードが 0 でなければパイプラインを中断
- 検証を通過したイメージのみを使って統合テストや E2E テストを実行
- テスト結果とイメージのダイジェスト（内容のハッシュ値）をアーティファクトとして保存
この流れは「シフトレフト（品質チェックをリリース後ではなく開発・統合の早い段階に移す考え方）」の一形態です。署名検証を後工程に先送りすると、テスト済みのイメージと実際に本番へデプロイされるイメージが別物になるリスクが残ります。
dev リリースをテスト戦略にどう組み込むか
今回のリリース名は v1.94.0-dev.3 です。dev サフィックスが付いたプレリリース版（正式リリース前の試験的なバージョン）をどう扱うかは、テスト戦略の観点から整理が必要です。
プレリリース版は機能追加の確認やリグレッション（以前動いていた機能が壊れていないかの検証）には有用ですが、署名の扱いは正式リリースと同等です。LiteLLM の方針では dev 版も同じ公開鍵で署名されており、検証コマンドの形式は変わりません。これは「dev 版だから署名を省略してよい」という運用を排除するうえで好ましい設計です。
テストマトリクス（バージョンや環境の組み合わせを並列で検証する構成）に dev 版を含める場合、使用するイメージのダイジェストをテストレポートに記録しておくと、後からどのイメージでテストしたかを追跡できます。たとえば docker inspect --format='{{index .RepoDigests 0}}' ghcr.io/berriai/litellm:v1.94.0-dev.3 でダイジェストを取得してログに残す、といった対応が有効です。
v1.94.0-dev.3 の変更点を見ると、Anthropic のストリーミング処理のバグ修正（thinking+signature の組み合わせで 500 エラーが発生していた問題）や、complexity_router（リクエストの複雑さに応じてモデルを自動選択する仕組み）のセッションアフィニティ（同一セッションを同じバックエンドに振り続ける設定）がデフォルト有効になる変更が含まれています。後者のようなデフォルト値の変更は、既存のテストケースが想定していた挙動を変える可能性があるため、回帰テストの対象として優先度を上げるべき変更点です。
Dockerイメージの署名検証は、テストが正しいものを検証しているという前提そのものを担保する工程です。その前提が崩れると、品質メトリクスの数字がいくら良くても意味を持たなくなります。