GitHub Actionsを悪用したLiteLLM侵害――「11日」の潜伏が供給連鎖へ波及した意味

今日の深掘りポイント

• 攻撃者はGitHub Actionsを起点に6種類のシークレットを狙い、外部エンドポイントへ機械的に流出させた可能性が高いです。
• 侵入から悪性パッケージ配布までの「11日」は、ビルド・公開パイプラインの下調べと横展開に十分な時間です。CIの可視性が乏しい組織ほど気づけません。
• 供給連鎖攻撃のトリガは「公開鍵・トークンの流出」と「CIの権限過多」の組み合わせで再現性が高いです。依存固定と署名・来歴検証をセットで導入すべきです。
• GitHub組織の「ワークフロー作成・更新」を最小権限化し、GITHUB_TOKENと外部ベンダークレデンシャルを“環境別・用途別”に強制分離する設計が肝です。
• 緊急度と実務的な対処可能性は高い一方、楽観視できる要素は乏しいです。監査と秘匿情報のローテーションは「本日中に着手」レベルの優先度です。

はじめに

LiteLLMのGitHubリポジトリが侵害され、攻撃者はGitHub Actionsを用いたワークフローでシークレットを収集・送信し、その約11日後に悪性パッケージの配布という供給連鎖攻撃へ展開したと報じられています。開発者が「日常的に頼る自動化」が攻撃の踏み台となる時代に、CI/CDとシークレット管理の小さな綻びは、想像以上の破壊力を持ちます。今回の事案は、表層的な「2FAの有無」や「鍵の置き場所」だけでは対処しきれない、設計レベルの問題を突きつけています。

本稿では、公開情報をもとに事実関係を整理しつつ、CI/CDと供給連鎖の交点で起きたことの意味を掘り下げ、CISO・SOC・TIの各視点から「今日できること」に落とし込みます。

深掘り詳細

事実関係の整理（わかっていること）

• 侵入時期と手口
  ・LiteLLMのGitHub組織は、10月21日の供給連鎖攻撃の約11日前に侵害され、攻撃者はGitHub Actionsで悪意のあるワークフローを実行したと報じられています。
  ・初期アクセスは「公開されたマスターキー」を足がかりに行われ、その後GitHub CLIのOAuthトークン取得へと展開したとされています。
  ・ワークフローは6種類のシークレットを狙い、GitHub環境に関する情報を収集し、外部のエンドポイントに送出したと伝えられています。
  ・この過程を経て悪性パッケージが配布され、LiteLLM側は内部システムやベンダー認証情報の無効化と対策強化に踏み切ったとされています。
  参考: GBHackersの報道 に基づく整理です。

• 影響の射程
  ・GitHubリポジトリのワークフロー改変は、CI/CDの自動実行という「信頼の連鎖」を逆手に取るため、検知が遅れると依存パッケージの消費者側まで波及しやすいです。
  ・報道はLiteLLM側の対処（無効化・強化）に触れていますが、依存する第三者のビルド・デプロイにも副次的な影響が出ている可能性があります。

編集部の視点（なぜ起き、どこに効くか）

• CIは「鍵束の集積所」になりやすいです
  シークレットを“ビルドの便宜”でリポジトリや組織スコープに広く置くと、攻撃者はワークフロー1本で横断的に吸い上げられます。環境別・用途別の分離、承認付きの段階的開示、OIDC等による短命な資格の発行ができていないと、流出の爆発半径が一気に拡がります。

• 「11日」の意味
  侵入から供給連鎖攻撃までの11日は、CIの挙動観察、権限・シークレットの棚卸し、テスト配布のドライランに十分です。CIの監査ログとワークフロー改変の差分監視が弱い環境では、この“準備期間”に気づけません。すなわち、CIの可視性不足は攻撃者にとって時間資産になります。

• 再現性の高いパターン
  公開・漏えい済みの鍵（あるいは弱い管理）＋Actionsの権限過多＋依存パッケージの検証不備という三点セットは、多くの組織で再現しうる脅威モデルです。新奇性は中程度でも、実務への即効性が高いのはこのためです。技術的難易度が低く、攻撃コストが安定している点が脅威です。

脅威シナリオと影響

以下は公開情報と一般的な攻撃知見に基づく仮説です。個別の挙動や技術IDは環境差があるため、MITRE ATT&CKは名前ベースで整理します。

• シナリオA：有効な認証情報を足場にCIを乗っ取り、供給連鎖へ波及

  1. 初期アクセス：公開・漏えいしたキーの悪用、あるいは有効アカウントの不正使用（Valid Accounts）。
  2. 実行：改変したGitHub Actionsワークフローでスクリプトを実行（Command and Scripting Interpreter）。
  3. 認証情報アクセス：リポジトリ/組織/環境スコープのシークレットを収集（Unsecured Credentials）。
  4. 発見：CI環境や公開設定、権限境界を探索（Discovery）。
  5. 流出：外部Webエンドポイントへ送信（Exfiltration over Web Service）。
  6. 信頼の迂回：ビルド・署名・公開パイプラインの信頼をすり抜ける（Subvert Trust Controls）。
  7. 影響：悪性パッケージ配布による下流の開発・本番環境への汚染（Supply Chain Compromise）。

• シナリオB：CI経由でベンダー・クラウドへの側方移動
  CIが保持するクラウドやSaaSベンダーの長寿命トークンが吸い上げられると、リポジトリの外へ横展開が可能になります。監視がソース管理に偏っている組織では、クラウド側での不審なAPIコールや権限昇格の検知が遅延します。

• 想定インパクト
  ・短期：依存パッケージの改竄配布、開発端末での情報窃取、ビルド成果物の改変です。
  ・中期：内部のベンダー連携・署名鍵のローテーション負荷、サプライヤーとの信頼回復コストです。
  ・長期：CI/CDの設計見直し、署名・来歴検証（provenance）と受入れ審査の常態化です。

参考（MITRE ATT&CKのリーダー用）：Valid Accounts、Unsecured Credentials、Exfiltration over Web Service、Subvert Trust Controls、Command and Scripting Interpreter、Supply Chain Compromise などで整理可能です。マッピングは環境ごとに精査が必要です。

セキュリティ担当者のアクション

緊急度が高く、かつ現場で即実行できる順で整理します。

• 直ちにやる（本日中）

  • CIの外向き通信ログとビルドログを走査し、直近2〜3週間で不審なcURL/HTTP送信、環境変数のダンプ、gh CLIの異常利用がないかを確認します。
  • リポジトリのWorkflows配下の改変履歴と、組織/環境スコープのシークレット参照履歴を監査します。未知の外部エンドポイント宛の送信があれば即遮断します。
  • CIに保存された長寿命クレデンシャル（クラウド、SaaS、レジストリ、署名鍵）を棚卸し、段階的にローテーションします。
  • LiteLLM関連パッケージの取得経路・バージョン・ハッシュを棚卸しし、疑義があれば社内ミラーや隔離環境で再検証します（依存の固定とハッシュ照合を徹底します）。

• 7日以内にやる（設計の是正）

  • GitHub Actionsの“最小権限”を強制します。デフォルトのGITHUB_TOKEN権限を明示的に縮小し、必要なジョブだけに限定します。
  • ワークフローの作成・更新権限を制限し、コードオーナー・保護ルール・必須レビューでゲートします。フォーク由来の実行には強制承認を課します。
  • シークレットを“環境単位かつ用途単位”に分離し、デプロイ段階での承認付き開示を必須化します。CIには長寿命トークンを置かず、OIDC等による短命・スコープ限定の資格発行へ移行します。
  • 外部通信の宛先制御（egress制御）を導入し、ワークフローが未知のドメインへPOSTできないようプロキシ/ファイアウォールで遮断します。
  • 依存の受け入れに署名・来歴検証を組み込みます。署名検証、アテステーション（provenance）、社内ミラーでの検疫期間、そしてロックファイル/ハッシュ必須を標準化します。

• 30日以内にやる（運用の常態化）

  • CI/CD専用の監査ダッシュボードを整備し、ワークフロー改変、シークレット使用、外向き通信、リリース操作を常時相関可視化します。
  • 供給連鎖インシデントのテーブルトップ演習を実施し、公開停止判断、顧客通知、鍵再発行、レジストリ協調の手順を確立します。
  • ベンダー・OSSメンテナとの脆弱性連絡チャネルを整備し、信頼回復のための透明性（タイムライン、インジケータ、対策）を準備します。

• 検知のヒント（SOC/TI向け）

  • CI環境での“機密環境変数の大量アクセス”や“外部POSTのスパイク”をルール化します。
  • ワークフロー内でのgh CLI、curl、Invoke-WebRequest等の不審な併用をシグネチャ化します。
  • パッケージ公開のメタデータ（発行者、タイムスタンプ、アテステーション）に異常がないか、普段の“匂い”と比較する異常検知を組み込みます。

最後に、今回の指標から読み取れるメッセージは明確です。緊急度と実務的な対処可能性は高く、影響の大きさも無視できません。新しさより“繰り返しやすさ”が脅威であり、供給連鎖を守るには、署名・来歴・依存固定・CI最小権限という定石を「面倒でも運用で回す」覚悟が要るということです。私たちの生産性を支える自動化の土台に、改めて強いガードレールを据える時期に来ています。

参考情報

• GBHackers: Hackers Breached the LiteLLM GitHub Repository; Executed Credential Stealing Workflow to Distribute Malicious Packages
  https://gbhackers.com/hackers-breached-litellm-github-repository/

• MITRE ATT&CK（テクニック参照のため）
  Valid Accounts, Unsecured Credentials, Exfiltration over Web Service, Subvert Trust Controls, Command and Scripting Interpreter, Supply Chain Compromise
  https://attack.mitre.org/