litellm の v1.88.1 がリリースされた。変更内容は地味で、pyjwt を 2.13.0 にバンプして、ws のオーバーライドを 8.20.1 に上げただけだ。パッチリリースとしては普通のやつ。
ただ、リリースノートを読んでいて「あ、そうか」となったのが cosign の話だった。
litellm の Docker image は cosign で署名されている
リリースページを見ると、全 Docker image が cosign で署名されていると書いてある。コミット 0112e53 で導入された公開鍵を使って、こんな感じで検証できる。
cosign verify \\
--key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \\
ghcr.io/berriai/litellm:v1.88.1ドキュメントには「コミットハッシュで固定するほうが cryptographically immutable なので推奨」とある。タグ指定でも検証はできるが、タグは書き換えられる可能性があるのでコミットハッシュのほうが強い、という話だ。
これ、正直今まで気にしていなかった。自分のチームでも litellm のコンテナを dev 環境で動かしていて、image は latest タグで引っ張っていた。えぐい雑さだと今さら気づいた。
LLMプロキシのサプライチェーンリスクって実は大きい
litellm はざっくり言うと、OpenAI や Anthropic や Gemini の API を統一インターフェースで叩けるプロキシだ。つまり API キーが通る。
自分のケースで言うと、dev 環境とはいえ OpenAI の API キーと Anthropic の API キーをそのまま環境変数に突っ込んでいる。コンテナ image が改ざんされていたら、キーが抜かれるリスクがある。
そう考えると cosign の検証は「やっといたほうがよい」レベルじゃなくて、やってないとまずい話だった。
去年、自分が個人開発で動かしていた npm パッケージが依存関係の汚染でハマったことがある。あのとき「サプライチェーン攻撃ってほんとにあるんだ」と思ったはずなのに、コンテナでは同じ意識が向いていなかった。これは普通に反省ポイントだ。
実際にどこを直すか
今回の話を受けて、直近でやろうとしていることをリストにした。
- CI の Docker pull ステップの前に `cosign verify` を差し込む
- image タグを `latest` から `v1.88.1` のような固定バージョンに変える
- 検証に使う公開鍵はコミットハッシュで固定する (タグ指定ではなく)
- API キーは環境変数直書きから secret manager 経由に切り替える
cosign は brew install cosign で入るし、CI (自分のチームは GitHub Actions) なら sigstore/cosign-installer アクションを使えばすぐ動く。セットアップ自体は重くない。
むしろ「今まで検証していなかった image を本番に近い環境で動かしていた」という事実のほうが重い。litellm の Stars 数はもう 49,800 を超えていて、使っているチームも多い。人気のある OSS ほど攻撃ターゲットになりやすい、という話もある。
v1.88.1 は地味なパッチリリースだけど、リリースノートをちゃんと読んでよかった。cosign の件は次のスプリントで PR として出す。