LiteLLMのリリースノートを追うのが最近の習慣になっている。個人開発でもスタートアップの社内プロジェクトでも、LLMのAPIゲートウェイとしてLiteLLMをDocker Composeで動かしているので、マイナーバージョンのchangelogも一応チェックするようにしている。
v1.84.8のリリースノートを開いたとき、内容のほぼ全部がセキュリティ関連の記述だった。backportのPRが9本並んでいて、なかでも目を引いたのがcosignを使ったDockerイメージの署名検証だ。sigstoreの仕組みは名前だけ知っていたけど、実際にリリースフローに組み込まれているのを見たのは初めてだった。
リリースノートに2通りの検証コマンドが載っていた。ひとつはpinned commit hash、もうひとつはrelease tagを使う方法だ。
commit hashはcryptographically immutableなので、キーが差し替えられていないことを保証できる。tagはリポジトリのtag protection rulesに依存するので、理論上は保護設定を変えると別のキーが参照される可能性がある。ノートにもそう明記されていた。ここは実務的にも差が出る話なので、CIに組み込むならhashのほうを使いたい。
シンプルな話に見えるけど、自分の個人開発の環境でこれをちゃんとやれているかというと、正直やれていなかった。ghcr.ioからpullしてdocker composeでそのまま起動、みたいな雑なフローだった。そこでちょっと反省した。
スタートアップの社内ツールでLiteLLMをプロキシとして使っているプロジェクトがある。OpenAIとAnthropicのキーを一元管理して、社内の複数サービスからルーティングしている構成だ。このプロジェクトのデプロイフローにcosignの検証ステップを挟むことにした。
彼女に「今日何してたの?」って聞かれて「DockerイメージのSBOM周りを調べてた」と答えたら「何語?」って顔をされた。まあそれはそうだ。
話を戻すと、検証コマンド自体はすごく短いので、GitHub Actionsのstepに1行足すだけで済む。ただ、cosignをCIのrunnerにどう用意するかが地味にハマりポイントだった。GitHub Actions公式のcosignアクションがsigstore/cosign-installer@v3として公開されているので、それを使えばあっさり解決した。
これだけで検証ステップが入る。出力にsignatureのvalidationが通った旨が出てきたとき、地味にテンションが上がった。
LiteLLMはスター数が50k超えていて、コントリビューターも大勢いる。そのぶんサプライチェーン攻撃のターゲットになるリスクも上がる。APIキーを一元管理するゲートウェイが改ざんされたイメージで動いていたら、キーが全部抜かれる。考えたくないシナリオだけど、ゼロではない。
LLM周りのコストを最適化するために費用対効果を細かく計算して、プロバイダーを切り替えるタイミングを研究している。でもその前提として、ゲートウェイ自体の信頼性を担保していなければ話にならない。今回のリリースでその意識がちゃんと固まった感じがする。
自分のプロジェクトにcosign検証を入れたのはよかったとして、次は個人開発のリポジトリのDocker Composeも同じフローに揃えたい。放置気味だった環境の整理を、このリリースを起点にやっていく。
v1.84.8のリリースノートを開いたとき、内容のほぼ全部がセキュリティ関連の記述だった。backportのPRが9本並んでいて、なかでも目を引いたのがcosignを使ったDockerイメージの署名検証だ。sigstoreの仕組みは名前だけ知っていたけど、実際にリリースフローに組み込まれているのを見たのは初めてだった。
commit hashとtagで署名検証の強度が違う
リリースノートに2通りの検証コマンドが載っていた。ひとつはpinned commit hash、もうひとつはrelease tagを使う方法だ。
# commit hash (推奨)
cosign verify \
--key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \
ghcr.io/berriai/litellm:v1.84.8
# tag (便利だけど強度は落ちる)
cosign verify \
--key https://raw.githubusercontent.com/BerriAI/litellm/v1.84.8/cosign.pub \
ghcr.io/berriai/litellm:v1.84.8commit hashはcryptographically immutableなので、キーが差し替えられていないことを保証できる。tagはリポジトリのtag protection rulesに依存するので、理論上は保護設定を変えると別のキーが参照される可能性がある。ノートにもそう明記されていた。ここは実務的にも差が出る話なので、CIに組み込むならhashのほうを使いたい。
シンプルな話に見えるけど、自分の個人開発の環境でこれをちゃんとやれているかというと、正直やれていなかった。ghcr.ioからpullしてdocker composeでそのまま起動、みたいな雑なフローだった。そこでちょっと反省した。
自分のCompose環境に組み込んでみた
スタートアップの社内ツールでLiteLLMをプロキシとして使っているプロジェクトがある。OpenAIとAnthropicのキーを一元管理して、社内の複数サービスからルーティングしている構成だ。このプロジェクトのデプロイフローにcosignの検証ステップを挟むことにした。
彼女に「今日何してたの?」って聞かれて「DockerイメージのSBOM周りを調べてた」と答えたら「何語?」って顔をされた。まあそれはそうだ。
話を戻すと、検証コマンド自体はすごく短いので、GitHub Actionsのstepに1行足すだけで済む。ただ、cosignをCIのrunnerにどう用意するかが地味にハマりポイントだった。GitHub Actions公式のcosignアクションがsigstore/cosign-installer@v3として公開されているので、それを使えばあっさり解決した。
- uses: sigstore/cosign-installer@v3
- name: Verify LiteLLM image
run: |
cosign verify \
--key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \
ghcr.io/berriai/litellm:v1.84.8これだけで検証ステップが入る。出力にsignatureのvalidationが通った旨が出てきたとき、地味にテンションが上がった。
LLMゲートウェイを「信頼して使う」ことの意味
LiteLLMはスター数が50k超えていて、コントリビューターも大勢いる。そのぶんサプライチェーン攻撃のターゲットになるリスクも上がる。APIキーを一元管理するゲートウェイが改ざんされたイメージで動いていたら、キーが全部抜かれる。考えたくないシナリオだけど、ゼロではない。
LLM周りのコストを最適化するために費用対効果を細かく計算して、プロバイダーを切り替えるタイミングを研究している。でもその前提として、ゲートウェイ自体の信頼性を担保していなければ話にならない。今回のリリースでその意識がちゃんと固まった感じがする。
自分のプロジェクトにcosign検証を入れたのはよかったとして、次は個人開発のリポジトリのDocker Composeも同じフローに揃えたい。放置気味だった環境の整理を、このリリースを起点にやっていく。