使い捨てブランチへの push で CI のシークレットを抜く手口に備える（LiteLLM 侵害の教訓）

LiteLLM の侵害では、攻撃者が数分で消す一時ブランチにワークフローを push し、on: push で組織と Environment のシークレットを外部へ送っていた。Environment の保護ルール、ワークフロー変更の制限、デプロイ記録と監査ログの監視、漏れたキーの即時失効で防ぐ。

2026-10-21、BerriAI/litellm のリリースパイプラインが悪用され、悪意ある litellm==1.107.0（PyPI の wheel とコンテナイメージ）が公開された。C2 は www[.]litellm[.]dev。
Socket の調査で、その 11 日前（10/10）からシークレット窃取ワークフローが動いていたことが分かった。
1. 正規の直近コミットを起点に ci-tmp-xxxxxx という一時ブランチを作る。
2. .github/workflows/cache.yml を追加するコミット（件名は ci: bump cache config）を push。
3. on: [push] で即座に実行され、secrets.* を /tmp/c.env に書いて base64 化し、webhook.site へ curl で送信。|| true で必ず成功扱いにする。
4. 数分でブランチを削除。main には何も残らない。
2 回目はジョブを 6 つに増やし、5 つの Environment を指定して Environment スコープのシークレット（DB 接続文字列、Redis パスワード、Playwright のセッション状態など）まで取っていた。計 20 種類。
起点は、5 月に公開リポジトリへ誤コミットされたまま失効されていなかったマスターキー。そこから組織オーナーのトークン、さらに他メンテナーの認証情報へ広がり、10/10 に盗まれた GH_TOKEN が悪意あるリリースの承認に使われた。

GitHub の Environment 設定で Deployment branches and tags を main やリリースタグに限定する。任意ブランチからの on: push で Environment を指定しても、シークレットが渡らなくなる。
本番・リリース系の Environment には Required reviewers を付ける。承認者のトークンが盗まれた場合に備え、承認者は複数にする。

ルールセットで、誰でも任意の名前のブランチを作れる状態をやめる（ブランチ作成の制限、.github/workflows/** の変更に CODEOWNERS レビューを必須にする）。
組織・リポジトリのシークレットは必要なワークフローだけに渡し、長期の PAT や GitHub App の秘密鍵を CI に置かない（OIDC などの短期トークンに置き換える）。

ブランチやファイルを消しても、Environment のデプロイ記録（ref 名・コミット件名付きで残る）と Actions performance metrics、組織の監査ログには残る。
次をアラート対象にする：main 以外の ref からの Environment デプロイ、作成から数分で消えたブランチ、新規ワークフローファイルの初回実行、実行時間が数秒でチェックアウトのないジョブ。
コミットの author は自己申告なので信用しない。誰が操作したかは監査ログ（送信元 IP、User-Agent、直前に作られたトークンや SSH 鍵）で見る。

@SocketSecurity · 2026-10-24
Socket「New Evidence Shows LiteLLM Secret-Stealing Workflows Ran 11 Days Before Supply Chain Attack」: socket.dev
@lmt_swallow · 2026-10-21
@flatt_security · 2026-10-21