LiteLLM v1.90.0を読んでDockerイメージ検証をちゃんとやろうと思った話

LiteLLM の v1.90.0 のリリースノートを眺めていたら、冒頭に cosign による Docker イメージ署名の検証手順が丁寧に書いてあった。
スター数が 51.7k もあってフォークも 9.2k 超えているプロジェクトなのに、自分のローカル環境ではイメージの検証なんて一切やっていなかった。
ちょっと恥ずかしくなった。

コミットハッシュで検証するほうが強いらしい

リリースノートに書いてある検証コマンドはこんな感じだ。

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

タグ名ではなくコミットハッシュで鍵を引っ張ってくるのが推奨とされている。
理由はシンプルで、コミットハッシュは cryptographically immutable、つまり書き換え不可能だからだ。
タグは管理者が上書きできるので、それに依存する検証は厳密さが落ちる。
この説明を読んで「あ、そういうことか」ってなった。

ちなみにリリース自体は `0112e53` というコミットで導入された signing key を全リリースで使い続けているらしい。
同じ鍵を使い回すポリシーについては賛否あると思うが、少なくともどのリリースから署名が始まったか追跡できるのは透明性として悪くない。

今回の変更点で自分のコードに刺さった部分

イメージ署名以外の変更も気になった。
個人開発で LiteLLM を proxy として使って複数モデルを束ねているんだけど、rate limit 周りのエラーハンドリングがちょっとダルかった。
`v1.90.0` では rate limit エラーに `category`、`rate_limit_type`、`model` といったフィールドが標準化されたとある。

これ、地味にえぐいアップデートだ。
今まで `RateLimitError` を受け取っても「どのモデルで詰まったのか」をエラーオブジェクトから直接取れなくて、ログを掘り返してた。
フィールドが標準化されれば、例外ハンドラの中で `e.model` みたいな形で分岐できる。
retry ロジックを書き直せる気がしてきた。

あとは `responses-bridge` で system のみのチャットリクエストを system input item にマッピングする修正も入っている。
自分のプロジェクトではまだ responses API を使っていないけど、そっちに移行するタイミングで踏む可能性があったバグだと思う。
PR 番号が `#29817` だったので、詳細は後で差分を読む予定だ。

cosign を使っていない自分が普通だと思わないほうがいい

ちょっと話を戻すと、LiteLLM みたいな OSS を production 環境で使うときに Docker イメージの検証をスキップしている人は多いと思う。
自分もその一人だった。
理由は「有名なプロジェクトだから大丈夫でしょ」という雑な信頼だ。

でも実際のサプライチェーン攻撃は「有名だから安全」という思い込みを突いてくる。
SolarWinds の件や、最近の xz utils のバックドア事件は記憶に新しい。
cosign の検証をワンコマンド追加するだけなら、やらない理由がない。

彼女に「それ何やってるの」って聞かれて説明したら「よくわからないけど慎重なんだね」と言われた。
慎重というより、今まで雑すぎただけだと思う。

実際に CI に組み込む場合のステップはこんなイメージだ。

- name: Verify LiteLLM Docker image
  run: |
    cosign verify \
      --key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \
      ghcr.io/berriai/litellm:v1.90.0

GitHub Actions に突っ込むだけ。
出力に「The cosign claims were validated」と「The signatures were verified against the specified public key」が出れば OK だ。

あと Bedrock の `strict` と `additionalProperties` を Converse の `toolSpec` に forward する変更も入っていた。
自分はまだ Bedrock を本格的に触っていないが、tool calling 周りを Bedrock 経由でやろうとしているチームメンバーがいるので、共有しておこうと思う。

リリースノートを流し読みしていたら思ったより拾えるものが多かった。
次のスプリントで rate limit エラーのハンドラと CI の検証ステップを直す、そこからやる。