LiteLLM 1.84.0-dev.2を読んでDockerイメージの信頼性を考えた

LiteLLMのリリースノートを眺めていて、ふと手が止まった。
「Verify Docker Image Signature」という見出しが目に入ったからだ。
正直、今まで自分のプロジェクトでDockerイメージの署名なんてほぼ気にしてなかった。

cosignとcommit hashで何が変わるか

今回の1.84.0-dev.2のリリースには、LiteLLMの全Dockerイメージがcosignで署名されているという説明が書いてある。
しかもその署名は、commit `0112e53` で導入されたキーと同じものが使われているとのこと。
つまり「リリースをまたいで署名キーが一貫している」という構造になっている。

検証方法は2パターン紹介されていて、推奨はcommit hashを使う方法だ。

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

commit hashは暗号学的に不変だから、タグより信頼性が高いという理屈だ。
タグは後から書き換えられる可能性があるけど、ハッシュは変えられない。
言われてみれば当たり前なんだけど、普段タグで`docker pull`しっぱなしだったので少し反省した。

「自分のコードに関係ないと思ってた」の落とし穴

自分が今関わっているプロジェクトでは、LiteLLMをプロキシとして立てて、OpenAIやAnthropicのAPIをまとめて叩く構成にしている。
コスト管理がメインの目的で、イメージ自体の検証なんて発想がなかった。
でも冷静に考えると、LLMのAPIキーが通るプロキシの信頼性を確保していないのは、財布の鍵を確認せずに使い続けているようなものだ。

dev版を本番に使うつもりはないけど、stagingや検証環境でlatestタグを何となく引っ張ってきていた習慣は見直すべきだと思った。
特に社内向けのサービスで使うなら、署名検証をCIに組み込んでおく価値はある。

リリース内容としては他にも変更がある。
gpt-image-2サポートの追加（#26644）と、AIHubMixというOpenAI互換プロバイダの追加（#24294）が個人的には気になった。
gpt-image-2を触ってみたかったので、このあたりは手元で動かして確認したい。

dev版のリリースだから本番投入はまだ先の話だけど、こうしてchangelogを追いかけるのは自分の技術選定の判断材料になる。
「このライブラリ、セキュリティ面ちゃんと考えてるな」という印象を持てるのは大事だ。

今週末、まずstagingのdocker-compose.ymlを見直して、cosignの検証コマンドをMakefileに追加するところから始めてみるつもりだ。