LiteLLM が cosign 署名を始めた話と、自分の環境の見直し

LiteLLM の v1.91.0-dev.1 のリリースノートを眺めてたら、Docker イメージに cosign で署名するようになってたのに気づいた。
commit `0112e53` で導入された signing key を使って、イメージの正当性を検証できる仕組みだ。
dev リリースを追いかけてるとこういう変更はサラッと流れがちなんだけど、今回はちゃんと刺さった。

自分の litellm 運用、署名検証ゼロだった

正直に言うと、今まで litellm の Docker イメージを pull するとき、署名なんてまったく気にしてなかった。
個人開発の検証環境だし、まあいいかという感覚でずっと使ってた。
でも本番 proxy として OpenAI や Anthropic の API キーを通してることを考えると、イメージの改ざんはわりとシャレにならない。
手元の compose ファイルを見て少し冷や汗をかいた。

リリースノートにある検証コマンドはこれだ。

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

commit hash でキーを固定する方法が推奨されていて、タグ指定は便利だけど tag protection ルールに依存するから信頼度が下がるという説明もちゃんとある。
cryptographically immutable という表現が出てきてて、ああそういうことかと腹落ちした。
タグは書き換え可能なので、hash で固定するほうが明らかに強い。

今回の変更で他に気になったこと

署名周りだけじゃなく、今回のリリースには他にも刺さる変更がいくつかあった。
fireworks_ai のチャット completions エンドポイントが full API surface と sync されたのと、plugin architecture v2 が入ったのは地味に大きい。
自分のプロジェクトでは fireworks_ai を試してないけど、コスト感を比べるためにちょいちょい差し込みたいと思っていたところだ。
plugin architecture v2 については `feat: litellm plugin architecture v2 by @krrish-berri-2` という PR #30688 が入っていて、どんな拡張ポイントが増えたのかコードを読む予定を入れた。

あと地味に助かったのが exceptions と streaming まわりのリファクタだ。
`extract exception_type provider dispatch so basedpyright can analyze it` と `extract chunk_creator dispatch so basedpyright can analyze it` という 2 本の PR が入っている。
自分は pyright を strict で動かしてるので、型解析が通りやすくなるのはコードレビューの際にノイズが減る。
これは本当に地味だけど、日々の開発でじわじわ効いてくるやつだ。

CI に署名検証を差し込む

今回の話を彼女に「Docker イメージに署名が付いた」と言ったら「それって何がうれしいの?」と聞かれて、サプライチェーン攻撃の話をしたら「えぐい」と言ってくれた。
彼女は非エンジニアだけど、ニュースで聞いたことある、という感じで反応はよかった。

とりあえず自分がやろうとしてるのは、CI (GitHub Actions) の litellm イメージ pull ステップの後に cosign verify を差し込むことだ。
commit hash 固定でキーを参照するやり方にする。

- name: verify litellm image signature
  run: |
    cosign verify \
      --key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \
      ghcr.io/berriai/litellm:v1.91.0-dev.1

ローカルの検証環境だけじゃなく、CI に組み込まないと意味がない。
dev リリースを追いかけるのが好きな分、新機能を試す速度と安全確認のバランスはもうちょっと意識してもいいなと感じた。

LiteLLM の star 数は今 51.3k を超えていて、fork も 9.1k ある。
ここまで使われているプロキシライブラリが供給チェーンを意識し始めたというのは、LLM 周辺ツールが「とりあえず動く」フェーズを抜けてきた証拠に見える。
次のバージョンアップのとき、自分はちゃんと verify コマンドを叩けるようにしておく。