LiteLLM の v1.88.0-rc.3 のリリースノートを読んでいたら、Docker イメージの署名検証について丁寧に書いてあって、少し手が止まった。
スター数 49.4k、フォーク数 8.6k のリポジトリだから、供給チェーン攻撃のターゲットになるリスクは普通に高い。なのにいままで自分は pull して使うだけで、イメージの真正性を確認したことが一度もなかった。
cosign verify をとりあえず手元で動かしてみた
リリースノートに書いてあった verify コマンドはこれ。コミットハッシュを直接 key の URL に使うやつが「recommended」と明記されていた。
cosign verify \\
--key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \\
ghcr.io/berriai/litellm:v1.88.0-rc.3タグ名を key に使う方法も書いてあるけど、そっちは「convenience」扱いで、タグの保護ルールに依存するという注意書きがある。コミットハッシュは cryptographically immutable だからそっちが強い、という理屈は確かに正しい。タグは後から force push で動かせる可能性があるし。
手元で実行したら「The cosign claims were validated / The signatures were verified against the specified public key」が出た。想定 output そのままだったので一発クリア。ハマりどころは特になかった。
これ自体は 5 分で終わる作業なんだけど、問題は「CI に組み込んでいるか」という話になる。
チームの CI パイプラインに組み込むかどうか悩んでいる
自分のスタートアップのプロダクト、LLM の API コストを抑えるためにルーティング層として LiteLLM を使っている。ステージング環境だけじゃなくて本番でも動かしている。
そう考えると、イメージが本物かどうかを pull のたびに確認しない理由はない。でも CI に組み込もうとすると cosign のインストールと鍵管理が増える。GitHub Actions だと install-cosign アクションがあるから追加のコストはそこまで大きくないはず。
ただ、最近チームでセキュリティ関連の作業が属人化していて、自分が設定したものを他のメンバーが理解できないまま放置されるケースが続いている。先月も dependabot の設定を自分が入れたまま誰も触れないので、実質メンテナンスが自分だけになっている状態だ。
とりあえず verify のワンライナーを README に書いて、「pull したらこれを実行する」という運用をチームに共有するところから始めようと思っている。CI 組み込みはその後に判断する。
LLM 周りのツールはサプライチェーン攻撃のリスクが上がっている
LiteLLM みたいなツールは API キーを直接扱う。OpenAI や Anthropic のキーがそのまま通過するプロキシ層になっている構造上、改ざんされたイメージが紛れ込んだら被害が大きい。コストの不正利用だけじゃなくて、プロンプトやレスポンスの内容を覗き見されるリスクもある。
LiteLLM 側がコミット 0112e53 から同じ鍵で署名を続けているのは、少なくともその点については誠実な姿勢だと感じた。鍵が変わっていたら即アウトで検出できる仕組みになっている。
こういうのを読んで「えぐいな、ちゃんとやってるな」と思いつつ、自分のコードが信頼している外部イメージをどこまで検証しているかを棚卸しする機会になった。LiteLLM 以外にも pull しっぱなしのイメージが複数あるので、次の週末に洗い出してみる。
彼女と土曜に出かける予定が入っているから、日曜に作業するつもりでいる。ボードゲームより先にやることができた。