GitHub Actionsでは、${{ ... }} の式はシェルがコマンドを実行する前に展開される。つまり、Issueタイトルにシングルクォートなどを含めれば、想定された文字列の外へ抜け出し、任意のシェルコマンドを追加できる可能性があった。後段で sed による整形を行っていても、すでにシェルによる解釈が済んだ後では、注入を防ぐことはできない。

ワークフローの起動条件が issues: opened だった点も重要だ。公開リポジトリでIssueを作成できるユーザーなら、タイトルを自由に制御できる。Issueイベントだけを対象にするガードは、入力値が信頼できることを意味せず、攻撃者が用意したタイトルのシェル展開を止める対策にはならなかった。

Copilotが「作った」と断定できない理由

問題のコミットには、「Copilot Autofix powered by AI」が共著者として記載されていた。また、AI支援によるレビューで危険な変更が見逃されたとされている。

ただし、公開されている証拠だけでは、Copilotが安全でない変更を実際に生成したのか、人間が作成した変更のレビューや共著に関わっただけなのかは確定していない。したがって、現時点で慎重に言えるのは、Copilotがこの変更に関連し、シェルインジェクションを検出できなかったということだ。

Red Agentはどう発見し、どう検証したのか

WizのRed Agentは、Snowflakeの公開GitHub組織を対象に、CI/CD設定の危険なパターンを自律的に探索した。その過程で、jira_issue.yml が信頼できないIssueデータを run: ブロックへ渡していることを特定し、細工した公開IssueのタイトルからGitHubホステッドランナー上で任意コマンドを実行できると推論した。

脆弱な変更のマージから5日後にあたる6月23日、Red AgentはSnowflakeのHackerOneプログラムで細工したIssueを作成。タイトルを利用してシェル文字列から抜け出し、ワークフローが扱っていたJira認証情報を、検証用に管理されたアウトオブバンドのコールバックへ送信させた。

これは、無許可の侵入ではなく、脆弱性開示プログラムの範囲内で行われた承認済みのセキュリティテストだった。一方で、確認された技術的な問題そのものは現実のものだった。公開Issueの作成だけで、認証情報を扱うワークフローの処理をコマンド実行へつなげられる状態になっていた。

どの情報にアクセスできたのか

侵害されたワークフローには、Snowflake内部JiraのURL、ユーザーのメールアドレス、APIトークンが設定されていた。取得されたトークンは qa@snowflake.net に関連付けられており、Wizはこれを使って内部Jiraポータルへの認証と、アクセス可能な範囲の確認を行った。

報道では、エンジニアリング、セキュリティコンプライアンス、バグバウンティ活動に関するJiraプロジェクトの読み取りアクセスが確認されたとされている。 ただし、トークンの完全な権限一覧や、アクセス可能だった全レコードの確定的な範囲までは、提供された証拠から判断できない。

そのため、最も確実な結論は、取得されたトークンによって機密性の高い内部Jira情報へのアクセスが可能になったということだ。Snowflakeの全システムに無制限にアクセスできたとする根拠は示されていない。

また、問題の場所はリポジトリのCI/CD自動化であり、.NETコネクターの実行時コードではなかった。影響を受けたリリース済みのSnowflake Connector for .NETのバージョンは報告されていない。

Snowflakeの対応と確認された影響

Wizは6月23日に問題を報告し、Snowflakeは同日中にワークフローを修正した。露出したJira認証情報は翌日にローテーションされた。

その後、Snowflakeは監査ログを確認し、情報露出の期間中に操作を行ったのはWizだけだったと結論づけた。Wizも、検証で取得したデータを安全に削除したと説明している。

第三者による不正アクセスは報告されておらず、CVE番号の割り当ても報告されていない。影響を受けたコネクターのリリースも特定されていない。

これらは確認済みの影響範囲を示す重要な制約だが、元のワークフロー設計が安全だったことを意味するわけではない。公開Issueのタイトルを、内部認証情報を扱うシェルコマンドへ直接組み込むべきではなかった。

CI/CDに残る教訓

今回の事例は、AIコーディング支援ツールとAIによる攻撃検証ツールが、同じ開発・運用サイクルの中で対照的に働いた例でもある。AI支援の変更が危険なCI/CD設定を見逃し、別の自律型エージェントが数日以内に発見・検証した。

実務上の対策としては、次の点が重要になる。

• Issueタイトル、プルリクエストのタイトル、ブランチ名、コメントなど、GitHubのコンテキスト値を常に攻撃者が制御できる入力として扱う。
• 信頼できない値を run: スクリプトへ直接埋め込まず、環境変数などを介して渡す。
• JSONの生成ではシェル文字列を連結せず、jq などの構造化ツールを利用する。
• シェルへ値を渡す境界で、適切なクォートと検証を行う。
• 攻撃者が制御できるデータを処理するステップから、認証情報を可能な限り分離する。
• AIが生成・レビューしたセキュリティ関連の変更も、人間が作成したコードと同じ基準で独立検証する。

自動化は、修正を速める一方で、脆弱性の発見や悪用も加速させる。今回の出来事が示すのは、AIを導入すればレビューが不要になるということではなく、AIが関わる変更ほど、入力の信頼境界と実行権限を人間が改めて確認する必要があるという現実だ。

GitHub Actionsでは、${{ ... }} の式はシェルがコマンドを実行する前に展開される。つまり、Issueタイトルにシングルクォートなどを含めれば、想定された文字列の外へ抜け出し、任意のシェルコマンドを追加できる可能性があった。後段で sed による整形を行っていても、すでにシェルによる解釈が済んだ後では、注入を防ぐことはできない。

ワークフローの起動条件が issues: opened だった点も重要だ。公開リポジトリでIssueを作成できるユーザーなら、タイトルを自由に制御できる。Issueイベントだけを対象にするガードは、入力値が信頼できることを意味せず、攻撃者が用意したタイトルのシェル展開を止める対策にはならなかった。

Copilotが「作った」と断定できない理由

問題のコミットには、「Copilot Autofix powered by AI」が共著者として記載されていた。また、AI支援によるレビューで危険な変更が見逃されたとされている。

ただし、公開されている証拠だけでは、Copilotが安全でない変更を実際に生成したのか、人間が作成した変更のレビューや共著に関わっただけなのかは確定していない。したがって、現時点で慎重に言えるのは、Copilotがこの変更に関連し、シェルインジェクションを検出できなかったということだ。

Red Agentはどう発見し、どう検証したのか

WizのRed Agentは、Snowflakeの公開GitHub組織を対象に、CI/CD設定の危険なパターンを自律的に探索した。その過程で、jira_issue.yml が信頼できないIssueデータを run: ブロックへ渡していることを特定し、細工した公開IssueのタイトルからGitHubホステッドランナー上で任意コマンドを実行できると推論した。

脆弱な変更のマージから5日後にあたる6月23日、Red AgentはSnowflakeのHackerOneプログラムで細工したIssueを作成。タイトルを利用してシェル文字列から抜け出し、ワークフローが扱っていたJira認証情報を、検証用に管理されたアウトオブバンドのコールバックへ送信させた。

これは、無許可の侵入ではなく、脆弱性開示プログラムの範囲内で行われた承認済みのセキュリティテストだった。一方で、確認された技術的な問題そのものは現実のものだった。公開Issueの作成だけで、認証情報を扱うワークフローの処理をコマンド実行へつなげられる状態になっていた。

どの情報にアクセスできたのか

侵害されたワークフローには、Snowflake内部JiraのURL、ユーザーのメールアドレス、APIトークンが設定されていた。取得されたトークンは qa@snowflake.net に関連付けられており、Wizはこれを使って内部Jiraポータルへの認証と、アクセス可能な範囲の確認を行った。

報道では、エンジニアリング、セキュリティコンプライアンス、バグバウンティ活動に関するJiraプロジェクトの読み取りアクセスが確認されたとされている。 ただし、トークンの完全な権限一覧や、アクセス可能だった全レコードの確定的な範囲までは、提供された証拠から判断できない。

そのため、最も確実な結論は、取得されたトークンによって機密性の高い内部Jira情報へのアクセスが可能になったということだ。Snowflakeの全システムに無制限にアクセスできたとする根拠は示されていない。

また、問題の場所はリポジトリのCI/CD自動化であり、.NETコネクターの実行時コードではなかった。影響を受けたリリース済みのSnowflake Connector for .NETのバージョンは報告されていない。

Snowflakeの対応と確認された影響

Wizは6月23日に問題を報告し、Snowflakeは同日中にワークフローを修正した。露出したJira認証情報は翌日にローテーションされた。

その後、Snowflakeは監査ログを確認し、情報露出の期間中に操作を行ったのはWizだけだったと結論づけた。Wizも、検証で取得したデータを安全に削除したと説明している。

第三者による不正アクセスは報告されておらず、CVE番号の割り当ても報告されていない。影響を受けたコネクターのリリースも特定されていない。

これらは確認済みの影響範囲を示す重要な制約だが、元のワークフロー設計が安全だったことを意味するわけではない。公開Issueのタイトルを、内部認証情報を扱うシェルコマンドへ直接組み込むべきではなかった。

CI/CDに残る教訓

今回の事例は、AIコーディング支援ツールとAIによる攻撃検証ツールが、同じ開発・運用サイクルの中で対照的に働いた例でもある。AI支援の変更が危険なCI/CD設定を見逃し、別の自律型エージェントが数日以内に発見・検証した。

実務上の対策としては、次の点が重要になる。

• Issueタイトル、プルリクエストのタイトル、ブランチ名、コメントなど、GitHubのコンテキスト値を常に攻撃者が制御できる入力として扱う。
• 信頼できない値を run: スクリプトへ直接埋め込まず、環境変数などを介して渡す。
• JSONの生成ではシェル文字列を連結せず、jq などの構造化ツールを利用する。
• シェルへ値を渡す境界で、適切なクォートと検証を行う。
• 攻撃者が制御できるデータを処理するステップから、認証情報を可能な限り分離する。
• AIが生成・レビューしたセキュリティ関連の変更も、人間が作成したコードと同じ基準で独立検証する。

自動化は、修正を速める一方で、脆弱性の発見や悪用も加速させる。今回の出来事が示すのは、AIを導入すればレビューが不要になるということではなく、AIが関わる変更ほど、入力の信頼境界と実行権限を人間が改めて確認する必要があるという現実だ。