GitHub Copilotが見逃した脆弱性とAIコーディングの責任論

GitHub CopilotがOKを出したPRに、実は脆弱性が残ったままだった。

それを見つけて実際に侵入したのは、人間のハッカーではなく別のAIエージェントだったんです。

Snowflakeで起きたこの一件、AIコーディングエージェントは誰が責任を取るのかという論争に発展しています。

「うちのCopilotも、同じように見逃しているかもしれない」、そう考えると他人事では済まされない話です。

Snowflakeの内部Jiraに侵入したのはAIレッドチームエージェントだった

セキュリティ企業Wizが開発した自律型AIレッドチームツール、Wiz Red Agentが、Snowflakeの公開リポジトリ「snowflake-connector-net」の脆弱性を人間の介入なしに発見し、そのまま悪用しました。

侵入の結果、Wiz Red AgentはSnowflakeの内部Jiraインスタンス「snowflakecomputing.atlassian.net」に「qa@snowflake.net」として実際にログインすることに成功しています。

この時点で、もう十分に異様な話です。

攻撃の起点から侵入の完了まで、人間のペネトレーションテスターは一切手を動かしていません。

AIエージェントが自律的に脆弱性を見つけ、攻撃コードを組み立て、認証情報を奪い、実システムに入り込んだわけです。

「AIが脆弱性を見つける」という話はもう珍しくありませんが、「AIエージェントが人間の手を借りずに侵入を完遂させた」という実例はまだ多くありません。

セキュリティ分野でAIエージェントの実力を示す象徴的な事例になりました。

この侵入口の中身を見ると、また別の意味で驚くはずです。

Red Agent Exploits Snowflake Vuln Missed by Github Copilot | Wiz Blog

Wiz Red Agent finds its way into Snowflake's internal Jira through a flaw in a GitHub Copilot–Assisted PR.

www.wiz.io

侵入の入り口はGitHub Actionsのコマンドインジェクション脆弱性だった

GitHub Actionsのワークフローファイル「jira_issue.yml」は、GitHubのIssueが作成されたときにJiraへ自動連携する処理を担っていました。

ここに、Issueのタイトル(${{ github.event.issue.title }})を検証せず、そのままシェル実行ブロックに埋め込んでいた箇所があったんです。

典型的なパターンで書くと、こんな形になります。

- name: Create Jira issue
  run: |
    echo "Issue title: ${{ github.event.issue.title }}"

Issueのタイトルは誰でも自由に書き込めます。

つまり、タイトル欄に仕込んだ文字列が、そのままシェルコマンドとして実行されてしまう。

たとえるなら、誰でも書ける受付表に「金庫を開けて」と書けば、その通り実行してしまう受付係がいるようなものです。

Wiz Red Agentはこの穴を突いて、細工したIssueタイトル経由でコマンドインジェクションを実行し、Jira APIトークンをBase64エンコードしてOut-of-Bandコールバックで外部に持ち出しました。

あとはそのトークンをそのまま使って、内部Jiraにログインしています。

手口自体に目新しさはないんですが、それをAIエージェントが自動で発見して実行まで持っていったところが今回のポイントです。

自分のワークフローにも似た書き方がないか、気になった方もいるでしょう。

ここまでの経緯を時系列で整理すると、以下のようになります。

Snowflakeは監査ログも確認していて、脆弱性が存在した約5日間の露出期間中にWiz以外のアクセスはなかったこと、テスト中にアクセスしたデータはすべて安全に削除したことを確認したと説明しています。

ここで一件落着と思いきや、実は最初の報道自体にも、ひと波乱あったんです。

GitHub Copilot Autofixを巡りWizとGitHubの言い分が食い違った

Wizは当初、ブログで「AIが書いた修正コードが、別のAIエージェントに発見・悪用される脆弱性を生んだ」という趣旨で発信しました。

該当PRに「Copilot Autofix powered by AI」が共著者としてクレジットされていたことが根拠です。

「AIが書いた欠陥コードのせいだ」、そう受け取っても無理はない発信でした。

これに対してGitHubが反論しました。

GitHubの内部調査によると、脆弱性があった「jira_issue.yml」の該当箇所は2025年8月25日、GitHubアカウント名sfc-gh-hpathakのSnowflakeのエンジニアが行ったコミットが起源で、AIではなく人間が書いたコードだったと判明したのです。

さらに、2026年6月18日にマージされた同じPRの中でCopilot Autofixが共著者としてクレジットされていたのは、脆弱性のあった「jira_issue.yml」ではなく別ファイル「jira_close.yml」の変更でした。

つまり「AIが脆弱なコードを書いた」という当初の構図は、事実関係としては成立していなかったことになります。

ただ、これでAIの疑いが完全に晴れたわけではありません。

訂正後も残った事実、Copilot Autofixは脆弱性を見逃していた

Wizはこの反論を受けて、ブログの記述を訂正しました。

共同創業者兼CTOのAmi Luttwakさんは「該当PRはCopilotを含む複数人の共著で、当初のブログはAIが脆弱なコードフローを生成したかのように読める内容だった」と説明しています。

「AIが書いた」という説明は取り下げられましたが、それで話が終わったわけではありません。

訂正後も動かない事実が一つ残っています。

GitHub Copilot Autofixは、このPRのコードレビューを担当し「安全」と判定して承認していたのに、コマンドインジェクションの脆弱性を検出できなかったんです。

いわば、研修医の「異常なし」という診断だけで、執刀のゴーサインを出してしまったようなものです。

「AIのレビューを信じた意味は何だったのか」、そう思いますよね。

書いたのが人間かAIかという論点と、レビューしたAIが見逃したという論点は、実は別の話です。

今回の一件が本質的に突きつけているのは後者だと私は見ています。

なぜこの1件がAIコーディングエージェントの責任論に発展したのか

この件は2026年8月17日前後にHacker Newsで話題になり、Forbes、TheHackerNews、SC Media、The Next Webなど複数の海外メディアも後追いで報じました。

「AIが悪いのか人間が悪いのか」、白黒つけたくなりますが、今回はどちらとも言い切れません。

話題になった理由は、この一件が「AIコーディングエージェントの責任は誰が取るのか」という問いを三重に投げかけているからだと思います。

1. 人間が書いた脆弱なコードを、AIのコードレビューが「安全」と承認してしまった
2. その脆弱性を、今度は別のAIエージェントが人間の手を借りずに発見・悪用した
3. 最初にこの一件を報じたWiz自身の説明も、AIの責任を実際より重く見せる形になっていて、あとから訂正が入った

AIが分かりやすく「悪さをした」という構図ではなく、AIのレビューが穴を見逃し、AIの攻撃エージェントがその穴を突き、AIの責任を語る側の説明さえ最初は不正確だった。

犯人を指差すたびに、その先にまた別のAIが立っている、そんなマトリョーシカのような話です。

この三重構造が、単純な「AI叩き」にも「AI擁護」にも回収されない厄介さを生んでいます。

だからこそ、犯人探しをするより、直せることから手をつけていきたいところです。

AIコーディングエージェントを使うチームが見直したいこと

Copilotのようなツールがコードレビューで「安全」と判定を出しても、それを最終承認の代わりにしてはいけない、というのが今回の一件から得られる一番実務的な教訓です。

似たような箇所が、あなたのCI/CDにも眠っているかもしれません。

チームで見直したいポイントは大きく3つあります。

1. CI/CDワークフロー内で外部入力(Issueタイトル、PRの説明文など)をシェルコマンドに直接埋め込んでいないか棚卸しする。env経由で一度受けてから使う、jqなどで安全にパースするといった基本パターンに置き換えるだけで防げます
2. AIコードレビューの「承認」は参考情報として扱い、CI/CDやシークレットを扱う変更は人間のセキュリティレビューを別途通す
3. APIトークンやシークレットは定期ローテーションを前提にした運用にしておく。Snowflakeも開示から1日でトークンを無効化していますが、露出期間そのものをゼロに近づける設計の方が望ましいです

AIにコードを書かせ、レビューさせる時代になっても、CI/CDのワークフローファイルは今まで通り人間が神経質になるべき領域です。

特に外部からの入力を扱う箇所は、書いたのがAIか人間かに関係なく、毎回同じチェックを通す仕組みにしておく方が安全だと思います。

まずは自分のリポジトリのGitHub Actionsを1つ開いて、Issueタイトルやコメントをシェルコマンドにそのまま渡していないか確認してみてください。

それだけで、今回と同じ穴は防げます。