LiteLLM の v1.90.3 のリリースノートを眺めていたら、Docker image の署名検証の話が載っていた。cosign を使って全リリースのイメージに署名しているらしく、commit `0112e53` で導入した公開鍵で一貫して署名しているとのこと。
これ、自分のプロダクションの構成を見直すきっかけになった。
cosign で何が変わるか
Docker image のサプライチェーン攻撃はここ数年じわじわ増えている。外部の OSS image をそのまま pull して使うのは、ハッシュで固定してない限りリスクがある。litellm のリリースノートには pinned commit hash での検証を推奨と書いてあって、理由も明快だった。「commit hash は cryptographically immutable だから signing key が本物かどうかの確認として最強」という話。
実際に推奨コマンドはこうなっている。
cosign verify \
--key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d386029d0/cosign.pub \
ghcr.io/berriai/litellm:v1.90.3タグ指定のほうは「読みやすいけどタグ保護ルールに依存する」という位置づけで、一段弱い扱いになっている。この使い分けの説明、わりとちゃんとしていて好感が持てた。
自分のチームは litellm を LLM の API コスト管理のプロキシとして使っていて、Compose でローカル開発、ECS でステージング・本番という構成だ。image タグは `latest` で引いていたのを、先月ようやく `v1.89.x` 系に固定したばかり。でも署名の検証は一切やっていなかった。ハマるポイントじゃないと思っていたけど、プロキシ層に変なものが混入したら全モデルへのリクエストがそこを通るわけで、影響範囲がえぐい。
自分のコードのどこを直すか
見直す箇所は三つある。
- Compose の image タグをダイジェスト固定にする (`image: ghcr.io/berriai/litellm@sha256:...`)
- CI のデプロイジョブに cosign verify を差し込む
- cosign の公開鍵は pinned commit hash で参照するほうに統一する
ダイジェスト固定は renovate に任せるつもりで、`regexManagers` でちゃんと追えるか確認する必要がある。そっちのほうが今日の作業としてはメインになりそうだ。
あと、これを機に彼女に「仕事で何してるの」と聞かれたとき、サプライチェーン攻撃の話を説明しようとしたら「それ面白いの?」で終わった。まあそうだよな。
LiteLLM 自体の運用で気になっていること
v1.90.3 は `stable/1.90.x` へのバックポートをまとめた patch release で、`#31923`・`#31929`・`#31393` の三つが入っている。中身を追うと LLM プロバイダ周りの細かいバグ修正が中心で、今のチームの構成に直撃するやつではなかった。ただ、litellm の Star 数が 52.5k を超えていて Fork が 9.4k というのを改めて見ると、コミュニティの規模感がわかる。PR も 2,300 件以上オープンしているあたり、開発速度が速すぎてトリアージが追いついていない雰囲気はある。
自分がいま一番気にしているのは、litellm プロキシ経由でトークン数とレイテンシをモデル別に集計する仕組みをちゃんと整えることだ。コスト最適化の観点で、どのモデルに何のタスクを投げるかをデータドリブンで決めたい。そのためのダッシュボードを個人開発で作り始めていて、litellm の callback 機能を使って Prometheus に流している。この構成が v1.90.x 系で壊れていないか、今夜ローカルで確認するつもりだ。
署名検証の CI 組み込み、週内には終わらせる。リリースノートをちゃんと読むとこういう改善のきっかけが転がっているので、changelog を流し読みで済ませるのはもったいないな、と気づいた。