LiteLLM のリリースノートを読んでいたら、v1.88.5 で Docker image の署名検証に関する記述がえぐいくらい丁寧に書かれていた。cosign で署名して、しかも「commit hash でピン留めする方法」と「タグで検証する方法」を両方例示している。
そこで自分の手元の CI を見直してみた。LiteLLM の Docker image を本番で使っているプロジェクトがあって、compose の image 指定はタグだけだった。`ghcr.io/berriai/litellm:v1.88.5` みたいな形。タグは mutable なので、万が一 registry が侵害されたとき気づけない。リリースノートに「commit hash は cryptographically immutable だから最も強い検証方法」と明記されていて、確かにそうだよなと。
cosign verify を CI に差し込む話
リリースノートに載っていた推奨コマンドはこれだ。
cosign verify \
--key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \
ghcr.io/berriai/litellm:v1.88.5commit hash `0112e53` でキーをピン留めして検証する。タグ指定の方法もあるけど、そっちは「tag protection rules に依存する」と書かれていて、完全に信頼できるわけではない。自分みたいにセキュリティをちゃんと気にするなら commit hash 一択だと感じた。
ただこれを CI に入れると、image を pull する前に cosign verify を走らせるステップが必要になる。GitHub Actions なら `sigstore/cosign-installer` アクションを使えばいいんだけど、自分のプロジェクトはまだそこまで整備できていなかった。「とりあえず動けばいい」でやってきたツケだ。
Stars 51.5k のプロジェクトだから余計気にする
LiteLLM は GitHub で star 51.5k、fork 9.2k のかなり大きなプロジェクトだ。これだけ使われていると、供給チェーン攻撃のターゲットになるリスクも上がる。実際 npm や PyPI で同様の事例は出ているし、Docker image の改ざんが検知されないまま本番に流れたら最悪だ。
チームのメンバーに「LiteLLM の image 検証ちゃんとしてる?」と聞いたら、「タグでバージョン固定してるから大丈夫でしょ」という反応だった。タグ固定と署名検証は別の話で、タグは書き換えられる可能性がある。説明したら「じゃあ対応します」となったので、今週中に PR を出す流れになっている。
彼女に「仕事で何やってたの?」と聞かれて「Docker image の署名検証」と答えたら「日本語で言って」と言われた。まあそれはそう。
対応方針はざっくり以下にまとめた。
- cosign-installer を Actions に追加
- image pull 前に cosign verify をステップとして挟む
- commit hash でキーをピン留め (タグ指定は使わない)
- verify 失敗時はワークフロー即停止
v1.88.5 のリリースで全 Docker image を commit `0112e53` で導入した同一キーで署名している、という点も重要だ。つまり古いバージョンに戻したときも同じ検証フローで対応できる。この辺の設計は素直に神だと思った。
LiteLLM を使っている人、まず自分の CI が image の署名を検証しているか確認してみてほしい。タグ固定だけで満足しているなら、今すぐ見直す価値がある。