複数のLLM（大規模言語モデル）APIを一枚のゲートウェイで束ねるOSS「LiteLLM」が、v1.105.0-rc.1というリリース候補版を公開しました。
このバージョンは機能追加だけでなく、Dockerイメージの署名検証手順を公式にドキュメント化した点が注目に値します。社内のLLM基盤をチームで運用しているエンジニアリングマネージャーやSREにとって、サプライチェーン攻撃対策とリリース運用のバランスをどう取るかという判断材料になる内容です。
この記事では、今回の変更が何を意味するのか段階的に整理したうえで、チームの開発プロセスとしてどう向き合うべきかを解説します。
何が変わったのか
LiteLLMは、OpenAI・Anthropic・Google Geminiなど100以上のLLMプロバイダーを、統一されたAPI仕様（OpenAI形式）経由で呼び出せるプロキシ兼SDKです。
社内で複数モデルを切り替えて使う構成では、各プロバイダーのSDKを個別に書く代わりに、LiteLLMのプロキシサーバーを1つ立てて呼び出し先を一元管理するケースが増えています。
今回のv1.105.0-rc.1では、配布されるDockerイメージ（ghcr.io/berriai/litellm）に対して、cosign（Sigstoreプロジェクトが提供する署名・検証ツール）による署名検証手順が明記されました。
具体的には、公開鍵を取得する2つの方法が示されています。1つはコミットハッシュを固定して検証する方法、もう1つはリリースタグを使う方法です。
cosign verify \
--key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \
ghcr.io/berriai/litellm:v1.105.0-rc.1このコマンドは、指定した公開鍵でDockerイメージの署名が正しいかを確認するものです。検証に成功すると「The cosign claims were validated」というメッセージが出力されます。
なぜコミットハッシュ固定が推奨されるのか
ここで段階を踏んで理解しておきたいのが、「コミットハッシュ固定」と「タグ指定」の違いです。
Gitのタグは、リポジトリの管理者が設定を変更すれば指し示すコミットを後から差し替えられます。一方コミットハッシュは、その内容のハッシュ値そのものなので、改変されると別のハッシュになり同一性が壊れます。
つまりタグは「ブランチ保護ルールを信頼する」前提の運用であるのに対し、コミットハッシュ固定は「暗号学的に不変である」ことを根拠にしている点が異なります。公式の案内でも、コミットハッシュでの検証が「recommended（推奨）」、タグでの検証は「convenience（利便性重視）」と明確に書き分けられています。
セキュリティ対策を重視するチームであれば前者を、CI/CDパイプラインの可読性や運用のしやすさを優先するなら後者を選ぶ、という判断軸になります。
背景にあるサプライチェーン攻撃への警戒
こうした署名検証の仕組みが広まった背景には、2020年代に相次いだソフトウェアサプライチェーン攻撃があります。
正規の配布経路からマルウェアが混入する事件が報告されるようになり、ビルド成果物（この場合はDockerイメージ）が「本当に想定した開発者・CIパイプラインから生成されたものか」を検証する文化が広がりました。
Kubernetes環境ではすでにイメージ署名検証をadmission controller（Podの起動を許可するかどうかを判定する仕組み）に組み込む事例があり、cosignはそのデファクトスタンダードの一つです。LiteLLMのような「社内のAIゲートウェイ」として使われるOSSが署名検証を明記したことは、AI基盤そのものがサプライチェーン攻撃の対象になりうるという前提が広がっていることの表れとも言えます。
開発プロセスとして何を確認すべきか
ここからは、チームの運用担当として今日から確認できることを整理します。
バージョン確認: まず現在使っているLiteLLMのイメージタグを確認してください。docker inspectや、デプロイに使っているIaC（Infrastructure as Codeの略、コードでインフラ構成を管理する手法）の設定ファイルでタグが固定されているか確認します。latestタグのような可変参照を使っていると、知らないうちに未検証のイメージへ切り替わるリスクがあります。
検証ステップのCI組み込み: デプロイパイプラインにcosign verifyのステップを追加できるか検討してください。GitHub Actionsであれば、イメージのpull直後・deploy直前のステップとして1行追加するだけで済みます。
rc（release candidate）版の扱い: 今回のv1.105.0-rc.1は正式リリースではなく候補版です。スクラムで言う「スプリントレビュー前の検証用ビルド」に近い位置づけで、本番環境に投入する前にステージング環境での動作確認を挟む判断が妥当です。
- 現行のDockerタグが固定値かどうかをまず確認する
- CIに署名検証ステップを追加する工数を見積もる
- rc版は本番投入の対象外とし、ステージングでの検証対象に留める
- 署名検証の運用ルールをチームのrunbook（障害対応・運用手順書）に追記する
見積もりと技術的負債のバランス
署名検証の導入は、機能追加ではなくリスク低減のための作業です。スクラムのバックログに積む際、プロダクトオーナーには「ユーザー影響が見えない技術的な保守タスク」として説明が必要になります。
ここで技術的負債との兼ね合いが出てきます。署名検証を後回しにしても機能は動き続けるため、優先度が下がりがちです。しかし脆弱性が実際に顕在化してからの対応コストは、事前の検証コストより大きくなる傾向があります。
スプリント計画の中では、1〜2ポイント程度の小さなタスクとして「CIパイプラインへの署名検証追加」を独立チケット化し、インフラ担当のキャパシティがある週に差し込む形が現実的です。大きな機能開発のスプリントに混ぜ込むと優先度で押し出されやすいため、別建てにしておく判断が有効です。
まとめ
LiteLLM v1.105.0-rc.1で明文化されたDocker署名検証は、技術的には数行のコマンドで完結します。
ただし運用に組み込むかどうかはチームの判断です。まずは現在のデプロイ設定でイメージタグが固定されているか確認し、次にCIへの検証ステップ追加をバックログ化してみてください。
rc版である点も踏まえ、本番反映は正式リリースを待つか、ステージングでの検証を経てからの判断が無難です。小さな保守タスクとして見積もりに乗せておくことで、技術的負債を増やさずに済みます。