LiteLLM が v1.89.3 をリリースした。チェンジログを見ると、今回の目玉は機能追加じゃなく backport 3〜4本とバグ修正がメインだ。スター数が 51k を超えてきて、自分も個人開発の LLM ルーターとして使ってるから、毎リリースひと通り目を通すようにしている。
で、今回ちょっと気になったのが冒頭に書いてある Docker image の署名検証の話だ。正直、今まで ghcr.io からイメージを pull するとき cosign で verify するなんて習慣がなかった。やばいな、と素直に思った。
リリースノートには 2 種類の verify 方法が書いてある。推奨されてるのは commit hash を使う方法だ。
commit hash `0112e53` は暗号学的に不変だから、鍵のすり替えが検出できる。一方で tag を使う方法は「リポジトリのタグ保護ルールが守られている前提」なので、若干信頼チェーンが長い。ドキュメントには「convenience」と書いてあって、運用コストと保証レベルのトレードオフを正直に書いてくれてるのが好印象だった。
とりあえず手元の Mac で cosign を入れて試してみた。Homebrew で `brew install cosign` 一発で入るし、verify コマンドを叩いたら `The cosign claims were validated` と出てきて一安心。でも正直、「いつからこの署名運用やってたっけ?」と気になって調べたら、commit `0112e53` が鍵の起点らしい。ちゃんとリリースノートに固定されてる。えぐい細かさだと思う。
自分が個人で動かしてる LLM ゲートウェイは、Raspberry Pi 上の Docker Compose で litellm のコンテナを使ってる。OpenAI と Gemini の API を束ねて、コスト最適化のためにモデルを自動で切り替える構成だ。月の API 費用を抑えたくて作ったやつ。
その CI、GitHub Actions で毎週イメージを自動更新してるんだけど、pull してきたイメージを verify するステップが一切なかった。supply chain attack とか頭ではわかってるつもりなのに、自分のパイプラインに組み込んでなかった。恥ずかしいな、と思いながらすぐ Actions の yaml を直した。
これを deploy ステップの前に挟むだけだ。3 分でできた。
社内の話をすると、チームでも litellm を使ってる。うちのスタートアップは社員 20 人弱で、LLM の呼び出しを一元管理するために litellm proxy を本番に立ててる。インフラ担当のメンバーに「verify ステップ入れよう」と Slack で送ったら、「え、そんな機能あったんですか」って返ってきた。自分も今日まで知らなかったから、人のことは言えない。
正直、LLM 周辺の OSS は機能追加の速度がえげつなくて、セキュリティ面の整備が後回しになってる印象があった。litellm も star 数の伸びが半端ないし、リリースサイクルが速すぎてレビューが追いつかない感覚があった。
でも今回のリリースノートを見て、少し変わってきたなと感じた。cosign を使った署名と、その検証手順を毎リリースのノートにきちんと書いてる。pinned commit hash 推奨という説明も含めて、SLSA みたいなサプライチェーン基準を意識してる雰囲気がある。
自分がハマりやすいのは「動いてるからいいや」で止まってしまうパターンだ。今回も cosign verify のことは「知ってる」つもりで完全に素通りしてた。リリースノートを流し読みじゃなくちゃんと読んでよかった。
次は本番の litellm proxy に対しても、デプロイパイプラインに verify を組み込むのを提案してみる。インフラ担当を巻き込んで、今週中に PR 出す予定だ。
で、今回ちょっと気になったのが冒頭に書いてある 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.3commit 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 出す予定だ。