LiteLLM が v1.87.2 をリリースした。
パッとリリースノートを見た感じ、今回のメインは「Docker イメージを cosign で検証する仕組みの整備」と、Fable 5・CrowdStrike AIDR・Mantle Responses SigV4 あたりのバックポートだ。
機能追加というより、サプライチェーン的な安心感を固めにいったリリースという印象。
正直、cosign を真面目に使ったことがなかった。
LiteLLM は社内の LLM プロキシ層として最近自分のプロジェクトに組み込んでいて、Docker イメージをそのまま docker pull してた。
でもこれ、イメージが改ざんされてたら気づかないやつだ。
それを実感してちょっと焦った。
pinned commit hash と tag、どっちで検証する?
リリースノートには 2 パターンの verify コマンドが載っている。
commit hash を使う方法と、release tag を使う方法だ。
ノートには「commit hash は cryptographically immutable なので stronger」とはっきり書いてある。
tag は人間が読みやすいが、tag protection に依存するので若干信頼度が落ちる。
というわけで自分は commit hash の方を採用した。
実際のコマンドはこれ。
cosign verify \
--key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \
ghcr.io/berriai/litellm:v1.87.2ローカルで流したら The cosign claims were validated と The signatures were verified against the specified public key が出て、ちゃんと通った。
これを CI のデプロイ前ステップに挟むだけで、「変なイメージを踏んでた」系の事故はかなり防げる。
CI への組み込み、実際どうしたか
自分のプロジェクトは GitHub Actions でデプロイしている。
ステージング環境に LiteLLM コンテナを上げる前のジョブに cosign verify を差し込んだ。
- 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 }}LITELLM_VERSION は env に v1.87.2 を入れてある。
バージョンを上げるときに env だけ書き換えればいい構成にした。
一点ハマったのが、Actions の runner に cosign が入っていないケースで、setup-cosign action を先に呼ぶ必要があった。
sigstore の cosign-installer を使えば一発なので、実質 2 ステップ追加で済む。
このあたり、最初はドキュメントをちゃんと読まずに cosign: command not found で詰まってた。
30 分くらいロスしたのは恥ずかしい。
今回のリリースには CrowdStrike AIDR のバックポートも含まれている。
うちのプロジェクトでは使っていないが、企業向けのセキュリティ文脈で LiteLLM を使っている人には刺さる変更だと思う。
あと Mantle Responses の SigV4 対応も入っていて、AWS 系のサービスと繋ぐ人には地味に助かる更新だ。
LiteLLM を使い続けるなら cosign は必須だと気づいた
そもそも LiteLLM は OpenAI / Anthropic / Gemini など複数プロバイダーの API を統一インターフェースで叩けるプロキシ層だ。
つまりここが汚染されると、全モデルへのリクエストが筒抜けになる。
API キーが全部通るレイヤーなので、セキュリティ的には最もやばいポイントの一つだ。
それをこれまで verify なしで動かしていたのは、冷静に考えると怖い。
彼女に「仕事どう?」って聞かれて「LLM のプロキシ周りを直してた」と答えたら「何それ」って顔をされたが、まあそれくらい地味な変更だ。
でも自分の中では割と重要な直しで、こういうの後回しにすると絶対忘れる。
スター数が 50k を超えてる OSS だからといって、イメージの検証を省略していい理由にはならない。
むしろ人気があるからこそターゲットになりやすいという話でもある。
次のバージョンに上げるときは、commit hash を新しいものに差し替えるだけ。
このワークフロー、他の Docker ベースの依存にも横展開しようと思っている。