LiteLLM の v1.91.0 リリースノートを読んでいて、まず目に入ったのが Docker イメージの署名検証の話だった。
これまで自分のプロジェクトでは LiteLLM を proxy として立てて、OpenAI と Anthropic の呼び分けをしていた。コスト最適化のために安いモデルに fallback させる構成が気に入っていて、個人開発でも会社のサイドプロジェクトでもわりと使い回している。
で、今回の v1.91.0 で何が変わったかというと、ちゃんと cosign でイメージ署名が入った。commit `0112e53` で導入されたキーで全リリースを署名している、と書いてある。
なぜ今 cosign なのか
DockerHub や ghcr.io から pull したイメージが改ざんされていないか確認する手段として、cosign は Sigstore エコシステムの中でここ 1〜2 年で一気に定着してきた。GitHub Actions の provenance attestation と組み合わせる構成もよく見るようになった。
リリースノートに載っている verify コマンドはこんな感じだ。
cosign verify \\
--key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \\
ghcr.io/berriai/litellm:v1.91.0commit ハッシュでキーを固定するのが推奨とあって、その理由が「cryptographically immutable だから」と書かれている。タグは可変だし tag protection に依存することになる。ハッシュで固定する方が署名の証明として強い、という話で、これはわかりやすい説明だと思った。
自分がいまローカルで動かしている構成は Docker Compose で LiteLLM proxy を立てていて、イメージを毎回 pull してそのまま使っていた。verify なんて一度もやっていなかった。えぐい。
自分のコードのどこを直すか
実務でも個人でも、CI に組み込んでいない署名検証はほぼ意味がない。deploy スクリプトに verify ステップを追加するのが最低限の対応だ。
今の compose ファイルのイメージ指定は `ghcr.io/berriai/litellm:main` というざっくりした指定になっていて、これもよくなかった。バージョンを固定して、pull する前に verify を走らせる構成に直す。
services:
litellm:
image: ghcr.io/berriai/litellm:v1.91.0このあと CI 側で
cosign verify \\
--key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \\
ghcr.io/berriai/litellm:v1.91.0を実行してから docker compose up する形にする。verify が通らなければ CI を落とせばいい。
今回のリリースには他にも変更が入っていて、Bedrock の Cohere 向けに embedding_types を JSON array で送るよう修正されている。以前 string で渡していてハマった記憶があるので、これは地味に嬉しい fix だ。Prometheus の user_email と user_alias をユーザー budget メトリクスに追加する feat も入っていた。チームで LiteLLM proxy を共有運用するなら、誰がどれだけ使っているかを Grafana で可視化したい場面がある。そこで使えそうなので次に試す候補に入れた。
セキュリティを後付けしない習慣
正直、個人開発のプロジェクトでイメージ署名まで気にするのは「やりすぎでは」と思っていた時期がある。でも最近、サプライチェーン攻撃の話を X のタイムラインで流れてくる頻度が増えていて、「動いてるからOK」は本番運用では通らないと感じ始めていた。
LiteLLM は Star が 52.6k まで伸びていて、使っているプロジェクトも増えている。ユーザーが増えれば攻撃対象にもなる。こういうタイミングでちゃんと署名検証の仕組みを公式に整備してきたのは、プロジェクトとして成熟してきた証拠だと思う。
リポジトリの fork も 9.5k を超えていて、PR の数も 2.3k 近くある。アクティブに動いているプロジェクトなのは間違いない。追いかけ続ける価値はある。
自分のプロジェクトでも、今週末に compose ファイルと CI の修正を入れる。それだけで verify を完全に素通りしていた状態からは抜け出せる。まずそこからだ。