LiteLLM のリリースノートを眺めていたら、v1.84.1 が地味にえぐいことをやっていた。
いつも通り changelog を流し読みしようとしたら、Docker image を cosign で署名してるという記述が目に入って、手が止まった。
cosign は Sigstore プロジェクトのツールで、コンテナイメージに暗号署名を付ける仕組みだ。
v1.84.1 のリリースノートには、`commit 0112e53` で導入した公開鍵を使って全リリースを署名していると書いてあった。
検証コマンドも丁寧に載っていて、commit hash で pinning する方法と release tag で参照する方法の 2 パターンが用意されている。
リリースノートには「commit hash は暗号学的に不変なので、これが一番強い検証方法」と説明されていた。
tag は repository の protection rules に依存するから、より信頼度が高いのは commit hash 側だという話だ。
これを読んで正直「あー、やっと来たか」という感覚があった。
LiteLLM はいま GitHub で star が 47.8k もあって、自分の個人開発でも会社のプロジェクトでも普通に使ってる OSS だ。
それだけ広く使われてるものが supply chain attack の標的になったら被害がえぐいことになるのは想像できる。
cosign 対応はその文脈での最低限の防衛線だと思う。
今の仕事で LiteLLM を使っているプロジェクトでは、Docker image を GitHub Actions で pull して検証環境を立ち上げる構成にしている。
image の検証ステップは正直これまで何もやっていなかった。
digital な怠慢というか、「まあ公式 image だし」という甘えで放置していたやつだ。
ただ今回の件で改めて考えると、CI で image を pull するタイミングに cosign verify を挟むのはそこまで重くない。
ローカルで試したら `cosign verify` コマンド自体は数秒で終わった。
CIの中でも 10 秒かからないと思う。
この程度の変更で supply chain の検証ができるなら入れない理由がない。
とりあえず次の PR のついでに足してみようと思っている。
ただ一点ハマりそうなのが、cosign のバイナリを runner に入れる手順だ。
GitHub-hosted runner にはデフォルトで入っていないので、`sigstore/cosign-installer` action を使うか、apt で入れるか、どちらかになる。
自分のチームではできるだけ依存を増やしたくない方針があるので、installer action を採用するかどうかはもう少し調べる。
そもそも LiteLLM をなぜ使っているかというと、複数の LLM プロバイダーへのリクエストを統一 API で扱えるからだ。
個人開発では OpenAI と Anthropic を切り替えながらコスト比較をしたいときに使っていて、これが地味に神だった。
ただ便利なライブラリほど、悪意ある改ざんが紛れ込んだときのダメージが大きい。
有名どころで言えば、xz Utils の backdoor 事件なんかはその典型で、あのときは OSS への信頼みたいなものが揺らいだ人も多かった。
リリースノートに署名検証の手順が明示的に書かれているのは、LiteLLM チームがその問題を真剣に考えている証拠だと受け取っている。
star 数が増えれば増えるほど、メンテナが対応しなければならないセキュリティの話も増える。
47.8k まで来たプロジェクトがこの対応をちゃんとしているのは普通に信頼ポイントになる。
自分が作る側になったとき、個人の OSS ライブラリでここまでやれるかというと正直わからない。
でも使う側として cosign verify を CI に組み込んでおくことは今すぐできる。
セキュリティは後回しにするたびに負債が積まれていくやつなので、PR のついでに入れてしまうのが一番早い。
いつも通り changelog を流し読みしようとしたら、Docker image を cosign で署名してるという記述が目に入って、手が止まった。
cosign 署名って実務でどこまで気にするべきか
cosign は Sigstore プロジェクトのツールで、コンテナイメージに暗号署名を付ける仕組みだ。
v1.84.1 のリリースノートには、`commit 0112e53` で導入した公開鍵を使って全リリースを署名していると書いてあった。
検証コマンドも丁寧に載っていて、commit hash で pinning する方法と release tag で参照する方法の 2 パターンが用意されている。
cosign verify \
--key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \
ghcr.io/berriai/litellm:v1.84.1リリースノートには「commit hash は暗号学的に不変なので、これが一番強い検証方法」と説明されていた。
tag は repository の protection rules に依存するから、より信頼度が高いのは commit hash 側だという話だ。
これを読んで正直「あー、やっと来たか」という感覚があった。
LiteLLM はいま GitHub で star が 47.8k もあって、自分の個人開発でも会社のプロジェクトでも普通に使ってる OSS だ。
それだけ広く使われてるものが supply chain attack の標的になったら被害がえぐいことになるのは想像できる。
cosign 対応はその文脈での最低限の防衛線だと思う。
自分の CI パイプラインに組み込むかどうかの判断
今の仕事で LiteLLM を使っているプロジェクトでは、Docker image を GitHub Actions で pull して検証環境を立ち上げる構成にしている。
image の検証ステップは正直これまで何もやっていなかった。
digital な怠慢というか、「まあ公式 image だし」という甘えで放置していたやつだ。
ただ今回の件で改めて考えると、CI で image を pull するタイミングに cosign verify を挟むのはそこまで重くない。
ローカルで試したら `cosign verify` コマンド自体は数秒で終わった。
CIの中でも 10 秒かからないと思う。
# GitHub Actions のステップに足すだけ
- name: Verify LiteLLM image signature
run: |
cosign verify \
--key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \
ghcr.io/berriai/litellm:${{ env.LITELLM_VERSION }}この程度の変更で supply chain の検証ができるなら入れない理由がない。
とりあえず次の PR のついでに足してみようと思っている。
ただ一点ハマりそうなのが、cosign のバイナリを runner に入れる手順だ。
GitHub-hosted runner にはデフォルトで入っていないので、`sigstore/cosign-installer` action を使うか、apt で入れるか、どちらかになる。
自分のチームではできるだけ依存を増やしたくない方針があるので、installer action を採用するかどうかはもう少し調べる。
OSS の信頼をどこで担保するか
そもそも LiteLLM をなぜ使っているかというと、複数の LLM プロバイダーへのリクエストを統一 API で扱えるからだ。
個人開発では OpenAI と Anthropic を切り替えながらコスト比較をしたいときに使っていて、これが地味に神だった。
ただ便利なライブラリほど、悪意ある改ざんが紛れ込んだときのダメージが大きい。
有名どころで言えば、xz Utils の backdoor 事件なんかはその典型で、あのときは OSS への信頼みたいなものが揺らいだ人も多かった。
リリースノートに署名検証の手順が明示的に書かれているのは、LiteLLM チームがその問題を真剣に考えている証拠だと受け取っている。
star 数が増えれば増えるほど、メンテナが対応しなければならないセキュリティの話も増える。
47.8k まで来たプロジェクトがこの対応をちゃんとしているのは普通に信頼ポイントになる。
自分が作る側になったとき、個人の OSS ライブラリでここまでやれるかというと正直わからない。
でも使う側として cosign verify を CI に組み込んでおくことは今すぐできる。
セキュリティは後回しにするたびに負債が積まれていくやつなので、PR のついでに入れてしまうのが一番早い。