先週、自分のスタートアップで使っているLiteLLMのDockerイメージを更新しようとして、リリースノートをのぞいた。v1.82.3.dev.6のページを見てまず目に入ったのが「Verify Docker Image Signature」というセクションだった。
正直、最初は流し読みしかけた。でも少し止まって読んでみると、これちゃんとやっておかないとまずいやつだと気づいた。
LiteLLMのDocker公式イメージは、cosignというツールで署名されている。sigstore.devが提供しているやつで、要はイメージが改ざんされていないことを公開鍵で確認する仕組みだ。リリースノートに書いてあったコマンドはこれ。
公開鍵はGitHubのリポジトリ上の `cosign.pub` を直接参照している。実行すると「The cosign claims were validated」と「The signatures were verified against the specified public key」というメッセージが出れば正常だ。
自分がこれまでDockerイメージをpullして使うとき、SHA256のダイジェストは気にしても署名の検証まではやっていなかった。特にLLM系のミドルウェアって、APIキーやログが通る経路にがっつり絡んでくる。それなのにイメージの真正性を確認していないのはちょっと雑だったと思う。
「じゃあ毎回手で叩くの？」というと、それは現実的じゃない。GitHub Actionsのワークフローで、イメージをpullする前のステップにcosign verifyを差し込むのが自然な流れだと思う。cosignのインストール自体は `sigstore/cosign-installer` アクションで一行で済む。
自分のチームのケースで言うと、開発環境はローカルでサクッと立ち上げることが多いので、そこまで厳密にやらなくてもいいかもしれない。ただステージングや本番のデプロイフローには入れておきたいと感じた。特にサプライチェーン攻撃の話が最近やたら出てくるので、「ちゃんとやってます」と言える状態にしておくのは大事だ。
もう一つ、今回のリリースノートのコミットが `e3d7412` で、コミッター本人の検証済み署名が付いていた点も地味に確認した。vigilant modeで署名されているコミットは、そのSSH鍵が本人のものであることがGitHub側で担保されている。こういう細かいところを見ておくと、ライブラリの管理体制への信頼感が変わってくる。
正直に言うと、LiteLLMを選んだ理由はAPIコストの一元管理とプロバイダ切り替えのしやすさだった。セキュリティ面はそこまで意識していなかった。でも今回のリリースノートを見て、Dockerイメージの署名やコミットの検証までちゃんとやっているプロジェクトだということがわかった。スター数42.4kのOSSとはいえ、こういう運用の丁寧さはライブラリ選定の基準として普通に加えていいと思う。
自分は来週、ステージング環境のデプロイスクリプトにcosign verifyのステップを追加してみるつもりだ。まずそこから始めて、動作確認が取れたら本番のCIにも横展開していく。
正直、最初は流し読みしかけた。でも少し止まって読んでみると、これちゃんとやっておかないとまずいやつだと気づいた。
cosignでイメージの署名を検証するって何なのか
LiteLLMのDocker公式イメージは、cosignというツールで署名されている。sigstore.devが提供しているやつで、要はイメージが改ざんされていないことを公開鍵で確認する仕組みだ。リリースノートに書いてあったコマンドはこれ。
cosign verify \
--key https://raw.githubusercontent.com/BerriAI/litellm/v1.82.3.dev.6/cosign.pub \
ghcr.io/berriai/litellm:v1.82.3.dev.6公開鍵はGitHubのリポジトリ上の `cosign.pub` を直接参照している。実行すると「The cosign claims were validated」と「The signatures were verified against the specified public key」というメッセージが出れば正常だ。
自分がこれまでDockerイメージをpullして使うとき、SHA256のダイジェストは気にしても署名の検証まではやっていなかった。特にLLM系のミドルウェアって、APIキーやログが通る経路にがっつり絡んでくる。それなのにイメージの真正性を確認していないのはちょっと雑だったと思う。
本番環境のCI/CDに組み込む場合の現実的な話
「じゃあ毎回手で叩くの？」というと、それは現実的じゃない。GitHub Actionsのワークフローで、イメージをpullする前のステップにcosign verifyを差し込むのが自然な流れだと思う。cosignのインストール自体は `sigstore/cosign-installer` アクションで一行で済む。
自分のチームのケースで言うと、開発環境はローカルでサクッと立ち上げることが多いので、そこまで厳密にやらなくてもいいかもしれない。ただステージングや本番のデプロイフローには入れておきたいと感じた。特にサプライチェーン攻撃の話が最近やたら出てくるので、「ちゃんとやってます」と言える状態にしておくのは大事だ。
もう一つ、今回のリリースノートのコミットが `e3d7412` で、コミッター本人の検証済み署名が付いていた点も地味に確認した。vigilant modeで署名されているコミットは、そのSSH鍵が本人のものであることがGitHub側で担保されている。こういう細かいところを見ておくと、ライブラリの管理体制への信頼感が変わってくる。
LLMまわりのライブラリ選定基準が少し変わった
正直に言うと、LiteLLMを選んだ理由はAPIコストの一元管理とプロバイダ切り替えのしやすさだった。セキュリティ面はそこまで意識していなかった。でも今回のリリースノートを見て、Dockerイメージの署名やコミットの検証までちゃんとやっているプロジェクトだということがわかった。スター数42.4kのOSSとはいえ、こういう運用の丁寧さはライブラリ選定の基準として普通に加えていいと思う。
自分は来週、ステージング環境のデプロイスクリプトにcosign verifyのステップを追加してみるつもりだ。まずそこから始めて、動作確認が取れたら本番のCIにも横展開していく。