AIが直したコードをAIが攻撃する時代へ。Snowflake事例が示すCI/CD防御の新常識

Wizが公開したSnowflake関連の検証事例は、AI開発のリスクをかなり具体的に見せています。要点は、AIが生成した修正が脆弱性を生み、その脆弱性を別のAIエージェントが発見し、悪用可能性を検証したという構図です。

Wizの説明によると、同社の自律型セキュリティエージェント「Red Agent」は、Snowflakeの公開GitHubリポジトリにあったGitHub Actionsのインジェクション脆弱性を発見しました。この脆弱性は、GitHub Copilot Autofix powered by AIによる修正を含むPRで導入されたものだとされています。Red Agentは公開Issueを使ってワークフローを起動し、内部Jiraに使われるAPIトークンへ到達できることを、認可されたセキュリティ検証の範囲で確認しました。

これは単なる「AIがミスをした」話ではありません。ソフトウェア開発の流れそのものが変わる中で、どこに防御線を置くべきかを示す事例です。

AI修正はレビューを不要にしない

GitHub Copilot Autofixのような機能は、脆弱性修正を速くするために非常に有用です。静的解析やセキュリティツールが問題を見つけ、AIが修正案を作る。開発者はそれを確認し、マージする。理想的には、セキュリティ修正のリードタイムは短くなります。

ただし、AIが提案した修正は、あくまで提案です。今回のWizの報告では、既存の安全な入力処理が置き換えられ、GitHub Actionsのrunブロック内でIssueタイトルや本文が危険な形で扱われるようになったと説明されています。つまり、脆弱性を直すはずの変更が、別の脆弱性を作った可能性があります。

人間のレビューであれば必ず防げた、という話でもありません。CI/CDワークフローの安全性は見落とされやすく、アプリケーションコードほど丁寧にレビューされないことがあります。だからこそ、AI修正を入れるほど、レビューの対象をコード本体だけでなく、ワークフロー、権限、シークレットの扱いまで広げる必要があります。

GitHub Actionsは攻撃面になる

この事例で重要なのは、攻撃対象がアプリケーション本体ではなくGitHub Actionsだった点です。

多くの開発チームにとって、CI/CDは裏側の自動化基盤です。テストを走らせ、ビルドし、通知し、デプロイする。普段は意識されにくいですが、CI/CDには強い権限が集まりやすい。クラウド認証情報、パッケージ公開権限、JiraやSlackのトークン、本番環境へつながる鍵。便利な自動化ほど、侵害されたときの影響は大きくなります。

Wizの事例では、公開Issueのタイトルを通じてワークフロー内でコマンドを実行できる可能性が示されました。これは典型的な「ユーザー入力をシェルへ渡す」問題です。しかし、GitHub Actionsではイベント由来の値が自然にワークフローへ入り込むため、見落としやすい。

AIがコードを書いてくれる時代でも、シェル、YAML、CI/CD、権限境界の知識は消えません。むしろ重要になります。

AIエージェント同士の速度差が問題を拡大する

今回の構図が象徴的なのは、攻撃側もAIだったことです。WizのRed Agentは、最初の試行が失敗した後に別のアプローチを試し、到達可能性を検証したとされています。

これは、今後のセキュリティ運用にとって大きな意味があります。AIが脆弱性修正を速くする一方で、AIは脆弱性探索も速くします。防御だけが加速するわけではありません。攻撃側、検証側、研究側も同じように加速します。

これまでなら、人間の攻撃者が公開リポジトリの変更を読み、脆弱性を探し、悪用方法を試すには時間がかかりました。自律型エージェントがその作業を継続的に行えるなら、脆弱性が公開状態になってから悪用可能性が検証されるまでの時間は短くなります。

AI開発時代のセキュリティは、「あとで人間が見る」では間に合わない領域に入りつつあります。

必要なのはAI禁止ではなく、AI修正の防御線

この事例を見て、AIによる修正を使うべきではない、と結論づけるのは短絡的です。AIは脆弱性対応の速度を上げ、開発者の負担を下げる可能性があります。問題は、AI修正を人間のレビューと同じ信頼レベルで扱ってしまうことです。

必要なのは、AI修正専用の防御線です。

まず、CI/CDワークフローには静的解析をかけるべきです。GitHub Actionsのテンプレートインジェクション、危険なrunブロック、過剰な権限、pull_request_targetの誤用、シークレットの露出を検出する仕組みが必要です。

次に、AIが生成したPRにはラベルやメタデータを付け、レビュー基準を変えるべきです。人間が書いたコードより危険という意味ではなく、AIが置換した意図や副作用を追いやすくするためです。

さらに、CI/CDの権限は最小化する必要があります。Issueを処理するワークフローが、内部Jiraの広い読み取り権限を持つべきか。公開イベントから起動されるワークフローに、どのシークレットを渡すべきか。こうした設計を見直す必要があります。

日本企業が見るべきポイント

日本企業でも、GitHub Copilot、CodeRabbit、Devin、Cursor、Codexなど、AI開発支援の導入は進んでいます。最初は個人の生産性向上として始まりますが、すぐにチーム開発、レビュー、CI/CD、リリース運用へ入り込みます。

そのとき重要なのは、AIを使うかどうかではなく、AIが入った開発プロセスをどう監査するかです。

見るべきポイントは明確です。

1つ目は、AI生成変更の可視化です。どのPRがAI生成なのか、どの部分がAIによる修正なのかを追えるようにすること。

2つ目は、CI/CDの棚卸しです。ワークフローごとに、起動条件、扱う入力、持っている権限、使うシークレットを確認すること。

3つ目は、セキュリティレビューの自動化です。AI修正をマージする前に、アプリコードだけでなくGitHub ActionsやIaCもスキャンすること。

4つ目は、障害時の封じ込めです。トークンが漏れても被害範囲を限定できるよう、短寿命トークン、スコープ分離、環境ごとの権限分割を進めること。

AI時代の開発者は「生成後」を設計する

生成AIによって、コードを書く速度は上がります。問題は、書いた後です。レビュー、テスト、権限確認、監査、ロールバック。ここが弱いままだと、速く書けるほど速く壊れます。

Wizの事例は、AIが作った脆弱性をAIが突いたという意味で象徴的です。しかし本質はもっと実務的です。AIが開発フローに入るなら、開発フロー全体をAI前提に作り直す必要があります。

LocalLensJapanとして見ると、これは日本の開発組織にもすぐ関係します。AIコーディング支援は、個人の便利ツールではなく、CI/CDとセキュリティ運用まで含む組織課題になります。AIにコードを書かせるなら、AIが触った場所を機械的に検査し、人間が判断すべき箇所を明確にする設計が必要です。

AI開発の競争は、生成速度だけでは決まりません。生成された変更をどれだけ安全に受け入れられるかで差がつきます。

AIが直したコードをAIが攻撃する時代には、レビューのやり方も、CI/CDの守り方も変えなければなりません。

参考: Wiz、The Hacker News、arXiv: Reliability of AI Bots Footprints in GitHub Actions CI/CD Workflows