LiteLLM の v1.87.1 リリースノートを読んでいたら、Docker image に cosign で署名するようになった件が目についた。コミット `0112e53` で導入した公開鍵を使って全リリースを署名する仕組みだ。ふだん `docker pull` するだけで深く考えていなかったけど、サプライチェーン攻撃の話を最近よく見かけるし、ちょっと真面目に確認してみようと思った。
リリースノートには 2 通りの verify 方法が書いてある。タグを使う方法と、コミットハッシュを固定する方法だ。ノート自体には「コミットハッシュの方が暗号学的に不変なので推奨」とはっきり書いてある。タグは repository の保護ルールに依存するので、運用次第で書き換えられるリスクがゼロではない。個人開発レベルなら気にしなくてもいいかもしれないけど、本番の proxy として使ってるなら話が変わる。
とりあえず手元に cosign を入れて試してみた。コマンドはこんな感じ。
期待出力は「cosign claims were validated」と「signatures were verified against the specified public key」の 2 行が出れば OK だ。実際に叩いたらちゃんと通った。なんか微妙に感動した。今まで GitHub の verified badge をなんとなく信じて使ってきたけど、CLI から自分で検証できると確かに安心感が違う。
ちなみに v1.87.1 の変更内容そのものは地味で、session token の budget ceiling exemption のバックポートが主な内容だ。1.87.0 から 1.87.1 に上がった実質的な diff はそれくらいで、一回 1.87.2 のバンプが入ってすぐ 1.87.1 に戻す revert まで入ってる。バタバタ感がリリースノートに残っていてリアルだった。
今うちのチームは LiteLLM を proxy として使っていて、複数モデルへのルーティングを任せている。Dockerfile はこんな感じで image を指定している。
`latest` タグを使っているのが今のところ最大の問題だ。cosign の verify を CI に組み込もうとしても、タグが動くので再現性がない。とりあえず `v1.87.1` のように固定タグに変えて、さらに verify ステップを GitHub Actions に追加するのが次のアクションになる。
コスト最適化でモデルをちょいちょい切り替えてきたけど、そのたびに image を雑に更新していた自覚がある。インフラ担当が自分一人じゃないと「誰が最後に image 変えたっけ」という話になるので、署名検証を仕組みとして入れておく方が後々ラクだ。スタートアップあるあるで人が増えると途端に「誰がやったの」問題が起きる。
LiteLLM は Star 49,000 を超えていて、フォークも 8,600 以上ある。これだけ使われているツールだと、compromise された image が出回ったときのダメージがえぐい。自分が被害を受けるだけならまだしも、API key が漏れたら顧客に迷惑がかかる。そういうリスクを「面倒くさい」で後回しにしていたのは反省している。
今週中に試そうと思っている手順はざっくりこうだ。
「とりあえず動けばいい」でずっとやってきた部分なので、今回のリリースノートは良いきっかけをくれた。LLM まわりのコストを削ることばかり考えていて、セキュリティの基礎をサボっていた。cosign の verify コマンド一発で確認できるなら、やらない理由はない。
自分のプロジェクトの image 管理が雑なままになっている人は、一度リリースノートを読み直してみると気づくことがあるかもしれない。
リリースノートには 2 通りの verify 方法が書いてある。タグを使う方法と、コミットハッシュを固定する方法だ。ノート自体には「コミットハッシュの方が暗号学的に不変なので推奨」とはっきり書いてある。タグは repository の保護ルールに依存するので、運用次第で書き換えられるリスクがゼロではない。個人開発レベルなら気にしなくてもいいかもしれないけど、本番の proxy として使ってるなら話が変わる。
実際に verify コマンドを叩いてみた
とりあえず手元に cosign を入れて試してみた。コマンドはこんな感じ。
cosign verify \
--key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \
ghcr.io/berriai/litellm:v1.87.1期待出力は「cosign claims were validated」と「signatures were verified against the specified public key」の 2 行が出れば OK だ。実際に叩いたらちゃんと通った。なんか微妙に感動した。今まで GitHub の verified badge をなんとなく信じて使ってきたけど、CLI から自分で検証できると確かに安心感が違う。
ちなみに v1.87.1 の変更内容そのものは地味で、session token の budget ceiling exemption のバックポートが主な内容だ。1.87.0 から 1.87.1 に上がった実質的な diff はそれくらいで、一回 1.87.2 のバンプが入ってすぐ 1.87.1 に戻す revert まで入ってる。バタバタ感がリリースノートに残っていてリアルだった。
自分のコードで何を直すか
今うちのチームは LiteLLM を proxy として使っていて、複数モデルへのルーティングを任せている。Dockerfile はこんな感じで image を指定している。
services:
litellm:
image: ghcr.io/berriai/litellm:latest`latest` タグを使っているのが今のところ最大の問題だ。cosign の verify を CI に組み込もうとしても、タグが動くので再現性がない。とりあえず `v1.87.1` のように固定タグに変えて、さらに verify ステップを GitHub Actions に追加するのが次のアクションになる。
コスト最適化でモデルをちょいちょい切り替えてきたけど、そのたびに image を雑に更新していた自覚がある。インフラ担当が自分一人じゃないと「誰が最後に image 変えたっけ」という話になるので、署名検証を仕組みとして入れておく方が後々ラクだ。スタートアップあるあるで人が増えると途端に「誰がやったの」問題が起きる。
LiteLLM は Star 49,000 を超えていて、フォークも 8,600 以上ある。これだけ使われているツールだと、compromise された image が出回ったときのダメージがえぐい。自分が被害を受けるだけならまだしも、API key が漏れたら顧客に迷惑がかかる。そういうリスクを「面倒くさい」で後回しにしていたのは反省している。
cosign を CI に組み込む手順の整理
今週中に試そうと思っている手順はざっくりこうだ。
- GitHub Actions に cosign をインストールするステップを追加する
- コミットハッシュ固定の --key URL を使って verify を走らせる
- verify が失敗したら deploy を止める
- image タグを latest から バージョン固定に変更する
「とりあえず動けばいい」でずっとやってきた部分なので、今回のリリースノートは良いきっかけをくれた。LLM まわりのコストを削ることばかり考えていて、セキュリティの基礎をサボっていた。cosign の verify コマンド一発で確認できるなら、やらない理由はない。
自分のプロジェクトの image 管理が雑なままになっている人は、一度リリースノートを読み直してみると気づくことがあるかもしれない。