LiteLLM v1.89.3 のDocker署名を手元で検証してみた

LiteLLM が v1.89.3 をリリースした。チェンジログを見ると、今回の目玉は機能追加じゃなく backport 3〜4本とバグ修正がメインだ。スター数が 51k を超えてきて、自分も個人開発の LLM ルーターとして使ってるから、毎リリースひと通り目を通すようにしている。

で、今回ちょっと気になったのが冒頭に書いてある Docker image の署名検証の話だ。正直、今まで ghcr.io からイメージを pull するとき cosign で verify するなんて習慣がなかった。やばいな、と素直に思った。

cosign verify、ちゃんとやったことなかった

リリースノートには 2 種類の verify 方法が書いてある。推奨されてるのは commit hash を使う方法だ。

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

commit hash 0112e53 は暗号学的に不変だから、鍵のすり替えが検出できる。一方で tag を使う方法は「リポジトリのタグ保護ルールが守られている前提」なので、若干信頼チェーンが長い。ドキュメントには「convenience」と書いてあって、運用コストと保証レベルのトレードオフを正直に書いてくれてるのが好印象だった。

とりあえず手元の Mac で cosign を入れて試してみた。Homebrew で brew install cosign 一発で入るし、verify コマンドを叩いたら The cosign claims were validated と出てきて一安心。でも正直、「いつからこの署名運用やってたっけ?」と気になって調べたら、commit 0112e53 が鍵の起点らしい。ちゃんとリリースノートに固定されてる。えぐい細かさだと思う。

個人開発の Docker 運用、見直すきっかけになった

自分が個人で動かしてる LLM ゲートウェイは、Raspberry Pi 上の Docker Compose で litellm のコンテナを使ってる。OpenAI と Gemini の API を束ねて、コスト最適化のためにモデルを自動で切り替える構成だ。月の API 費用を抑えたくて作ったやつ。

その CI、GitHub Actions で毎週イメージを自動更新してるんだけど、pull してきたイメージを verify するステップが一切なかった。supply chain attack とか頭ではわかってるつもりなのに、自分のパイプラインに組み込んでなかった。恥ずかしいな、と思いながらすぐ Actions の yaml を直した。

- name: Verify LiteLLM image signature
  run: |
    cosign verify \
      --key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \
      ghcr.io/berriai/litellm:${{ env.LITELLM_VERSION }}

これを deploy ステップの前に挟むだけだ。3 分でできた。

社内の話をすると、チームでも litellm を使ってる。うちのスタートアップは社員 20 人弱で、LLM の呼び出しを一元管理するために litellm proxy を本番に立ててる。インフラ担当のメンバーに「verify ステップ入れよう」と Slack で送ったら、「え、そんな機能あったんですか」って返ってきた。自分も今日まで知らなかったから、人のことは言えない。

LLM 周辺の OSS、セキュリティ運用がようやく追いついてきた

正直、LLM 周辺の OSS は機能追加の速度がえげつなくて、セキュリティ面の整備が後回しになってる印象があった。litellm も star 数の伸びが半端ないし、リリースサイクルが速すぎてレビューが追いつかない感覚があった。

でも今回のリリースノートを見て、少し変わってきたなと感じた。cosign を使った署名と、その検証手順を毎リリースのノートにきちんと書いてる。pinned commit hash 推奨という説明も含めて、SLSA みたいなサプライチェーン基準を意識してる雰囲気がある。

自分がハマりやすいのは「動いてるからいいや」で止まってしまうパターンだ。今回も cosign verify のことは「知ってる」つもりで完全に素通りしてた。リリースノートを流し読みじゃなくちゃんと読んでよかった。

次は本番の litellm proxy に対しても、デプロイパイプラインに verify を組み込むのを提案してみる。インフラ担当を巻き込んで、今週中に PR 出す予定だ。