AIを活用したGitHub Actionsは、たった一つのコメントによって乗っ取られ、APIキー、クラウドトークン、その他のシークレットが漏洩する恐れがあります。あるセキュリティ研究者が、公開トリガー、 「skip prompts」フラグを使用して実行されるAIツール、そして露出したシークレットが組み合わさることで、単純なデータの持ち出し経路が形成される22のオープンソースリポジトリを特定しました。

脆弱性の仕組み

現在、多くのプロジェクトがAIエージェント（Claude Code、GitHub Copilot CLI、および同様のツール）をCIパイプラインに直接組み込んでいます。ワークフローのステップではシェルコマンドが実行されますが、多くの場合、ツールに対してインタラクティブな権限リクエストを無視するよう指示するフラグが付与されています。Issue、コメント、またはプルリクエストのタイトルといった公開された入力によってワークフローが開始されると、攻撃者はAIがコマンドとして処理するテキストを一行投稿するだけでよくなります。

「skip prompts」フラグによってすでに無制限のシェルアクセスを与えられているAIは、ワークフローが公開しているあらゆる環境変数やファイルを読み取ります。もしジョブがAPIキー、クラウドサービスのトークン、あるいはサービスアカウントの完全な認証情報などのシークレットをロードしている場合、AIはそれらの値を攻撃者が制御するサーバーへと転送します。コードの変更も、新しい依存関係の追加も必要ありません。ただ、一見無害に見えるコメントを投稿するだけです。

実例

研究者は、すでに修正済みの3つの脆弱なリポジトリを確認しました。

  • pymc-labs/pymc-marketing – プロンプトインジェクションを通じて、公開されたIssueからAnthropic APIキーにアクセスできる可能性がありました。
  • MadAppGang/dingo – ワークフローがClaude Codeに完全なBashアクセスを許可しており、同じジョブ内で2つのシークレットが露出していました。
  • MadAppGang/claudish – dingoプロジェクトと同じ脆弱なテンプレートを再利用していました。

また、ある調査では、現在も有効なクラウドサービスのアカウントキーが見つかり、研究者はこれを主要なAIプロバイダーのセキュリティチームに直接報告しました。他にも12件の報告がメンテナーに対して保留されており、修正が公開されるまでその名称は伏せられています。

リスクの大きさ

攻撃者がシークレットを抽出した場合、その被害は即座に、かつ甚大なものになる可能性があります。クラウドサービスのアカウントキーがあれば、コンピューティングリソース、ストレージバケット、その他の有料サービスへの無制限のアクセスが可能になります。大規模言語モデル（LLM）プロバイダーのAPIキーが悪用されれば、無制限にクエリを実行され、数千ドルの請求が発生する恐れもあります。このエクスプロイトはCI環境内で実行されるため、侵害はダウンストリームへと広がる可能性があります。侵害されたランナー上でビルドされたあらゆるアーティファクトに悪意のあるコードが含まれる可能性があり、単一のリポジトリがサプライチェーン攻撃のベクトルへと変貌してしまいます。

AI支援型のCIに依存しているチームにとって、このトレードオフは極めて深刻です。コードの自動生成、リンティング、ドキュメント作成の利便性と、公開コメントが隠れたバックドアになるリスクを天秤にかける必要があります。

なぜ脆弱性を見逃しやすいのか

研究者は当初6件の報告を行いましたが、後にそれらは取り下げられました。取り下げの理由は、Actionのソースコードを一行ずつレビューした結果ではなく、GitHub Actionsの権限チェックに関する思い込みによるものでした。ドキュメントや直感は誤解を招くことがあります。AIを活用したステップのセキュリティ体制を確認する唯一の信頼できる方法は、ツールを実行するコードと、それを構成するワークフローのYAMLファイルを直接検査することです。

対策チェックリスト

GitHub Actionsワークフロー内でAI CLIまたは同様のツールを実行している場合は、マージする前に以下の2つの質問に答えてください。

  1. 誰がワークフローをトリガーできますか？ トリガーを信頼できるイベント（例：保護されたブランチへのプッシュ）に制限するか、外部のコントリビューターによって開始される実行には明示的な承認を必要とするようにしてください。追加のゲート（制限）なしに on: issue_comment や on: issues を使用することは避けてください。

  2. 同じジョブにどのようなシークレットがロードされていますか？ 無制限のシェルアクセスを持つAIエージェントを実行するジョブ内で、APIキー、クラウドトークン、またはサービスアカウントの認証情報を決して露出させないでください。シークレットを多用するステップは、AIツールを呼び出さない独立したジョブまたはランナーに分離してください。

追加の要塞化（ハードニング）手順：

  • 権限プロンプトをスキップするフラグを削除し、AIツールがシェルコマンドを実行する前に明示的な確認を求めるように強制します。
  • AIツールが読み取る可能性のある環境変数をサニタイズ、または秘匿（リダクト）するステップを追加します。
  • 任意の終端へのデータの持ち出しを防ぐため、ネットワークの送信（エグレス）制御を備えたセルフホストランナーを使用します。

反論：CIにおけるAIの有用性

推進派は、生産性の向上がリスクを上回ると主張しています。自動化されたコード提案はレビュー時間を短縮し、AI主導のテストはバグを早期に発見します。しかし、同じ利便性が攻撃対象領域（アタックサーフェス）を拡大させることも事実です。重要なのはAIを放棄することではなく、シェルレベルの権限を持つあらゆるツールを潜在的な攻撃ベクトルとして扱うことです。

次に注目すべき点

今回の調査結果は、AI対応のActionsに対するデフォルトの権限設定の厳格化について、すでにGitHubのセキュリティフォーラムで議論を巻き起こしています。今後のプラットフォームのアップデートには、以下が含まれる可能性があります：

  • AIツールを、直接的なシェルアクセスなしでサンドボックス環境内で実行させるフラグ。
  • Issueの本文やコメントにおけるプロンプトインジェクション・パターンの組み込み検知機能。
  • ワークフローが公開トリガーと機密情報（シークレット）を含むジョブを混在させている場合の自動アラート。

現時点では、責任はリポジトリのメンテナーにあります。特定された22のリポジトリは、この問題が孤立したものではないことを示しています。同様のワークフローパターンを持つプロジェクトはすべて脆弱です。CI設定を素早く監査することで、攻撃者に気づかれる前に問題を特定できます。

結論： 公開されているGitHub Issue内のたった一行のテキストが、AIエージェントにCI環境の完全な制御権を与え、そこに保存されているシークレットを盗み出す可能性があります。誰がワークフローを実行できるかを確認し、AIが実行するステップからシークレットを遠ざけ、チェックされていない権限を付与するすべてのフラグを精査してください。情報漏洩によるコストは、規律あるレビューにかかる労力をはるかに上回ります。