GitHub Copilotの「Autofix」機能に脆弱性、SnowflakeのJiraが侵害される事態に

AIによる自動修正機能であるGitHub Copilotの「Autofix」において、セキュリティ上の不備を突かれた結果、Snowflake社が利用するJira環境が侵害されるという重大なインシデントが発生しました。AIの提案を鵜呑みにすることの危険性が改めて浮き彫りになっています。

正確なタイトルは「WizのRed Agentが、AI生成されたGitHub Copilotの自動修正機能によってSnowflakeの内部Jiraに入り込んだ」だね。

ワークフローには保護を意図したif条件がある：
if: (github.event_name == 'issues' && github.event.pull_request.user.login != 'whitesource-for-github-com[bot]')
しかし、issuesイベントではgithub.event.pull_requestは常にnullになる。

これ、余計にたちが悪いよ。仮にこの条件式がユーザーIDを正しくチェックしていたとしても、少し考えれば「保護」にはならないって分かるはず。正しく動いたとしても、特定のbotユーザーを1つ除外して他の全ユーザーを許可するだけだから、セキュリティ保護には全くならないんだから。

それより、この条件式自体がそもそも「保護」目的で作られたものじゃなくて、記事がLLMのいい加減な出力（LLM slop）だからそう書かれているだけ、っていう線の方が濃厚だよ。

この脆弱性が導入された時に何をやろうとしていたのかを見ると面白いね[0]。

jira_close.ymlのようなワークフローは非推奨のAtlassian JIRAアクションを使っていてgh-actionsリポジトリに依存している。これは理想的ではなく、不必要に複雑だ。このPRではjira_closeワークフローを更新し、curl経由の直接APIコールに変更する。また、使用されているカスタムフィールドも保持する。

このプロジェクトの管理体制や優先順位については何とも言えないけど、自分の経験から言うと、AI以前ならこの種の変更は「軽微なイライラ案件」として、他にも5万件あるチケットと一緒に「技術負債バックログ」に突っ込まれて、実際には二度と着手されなかったはず。人間がわざわざ時間をかけて問題を理解し、コードを修正し、テストしてデプロイするコストは、この変更から得られるわずかな価値に対して高すぎたからね。

ところが今やAIのおかげで、エージェントを起動して「変更しろ」と伝えるだけ。バックログのJiraチケットを書くのと同じくらいの労力で済んじゃう。

オープンソースで起きている価値の低いPRの問題と似ているけど、企業も気づき始めないといけない。コードは生成が「ほぼ無料」であっても、内部プロセスにおいてレビューや維持管理にかかるコストまでが無料ではないってことに。エージェントなら数行の指示でちょっとした技術負債を解消できるからといって、そうすべきとは限らないんだ。

YAMLはまさに悪夢の仕様だ。

「人間が読める」マークアップを目指した結果、数えきれないほどの地雷を生み出している。

正直、今ならXMLの方がずっとマシだ。

リンクされている最初のPR（#1218）を見ると、Copilotが共同作成したコミットは1つだけで、それは脆弱性とは無関係だし、PR内の他の提案も関係ないよね。何か見落としてるかな？

自分でも同じミスをしたかもしれないな。静的解析を使わずにGitHub Actionsを書くのは怠慢と言われても仕方ない。

CIでzizmorを使おう。https://github.com/zizmorcore/zizmor

    error[template-injection]: テンプレート展開によるコードインジェクション
      --> .github/workflows/jira_issue.yml:24:29
       |
    22 |         run: |
       |         --- このrunブロック
    23 |           # タイトルと本文の特殊文字をエスケープ
    24 |           TITLE=$(echo '${{ github.event.issue.title }}' | sed 's/"/\\"/g' | sed "s/'/\\\'/g")
       |                             ^^^^^^^^^^^^^^^^^^^^^^^^ 攻撃者が操作可能なコードに展開される可能性
       |
       = note: 監査の信頼性 → 高
       = note: この発見には自動修正があります

ここでの興味深い教訓は「AI生成コードは危険」という単純なことじゃない。我々は数十年前から危険なコードと付き合ってきたんだ。より大きな問題は、AIによって変更を導入するコストは劇的に下がったのに、その変更をレビューするコストはそれほど下がっていないという点だね。

今やボトルネックは、コード生成からコード検証へと移っている。

このPR、売り込み方がイマイチだね。

jira_close.ymlのようなワークフローは非推奨のAtlassian JIRAアクションを使っていて、gh-actionsリポジトリに依存している。これは理想的ではなく、不必要に複雑だ。

その後にこう続く。

PRではjira_closeワークフローを更新し、curl経由の直接APIコールに変更する。

「不要な抽象化」を排除するために、手作りのcurlでロジックを我々のコードベースに複製するんだと。参るね。しかもYAMLファイルの中に全て埋め込んで。こんなコード、ジュニアエンジニア（やLLM）が書く典型的なごった煮だよ。レビューで遭遇したら、「素直に簡単なプログラムに書き直してくれ。それが無理なら、手間の割に価値がないからクローズしよう」と優しく伝えるのが正解。

これが、もっと酷い状況になる前の予兆だろうね。

今、業界で起きていること――今回の自動修正の問題はまさにその一例だと思うけど――は、ソフトウェア開発などで蔓延している「LGTM!（これでOK）」レビューの必然的な進化なんだよ。

何年もの間、コードレビューの大多数は「パッと見てLGTM」だった。もちろん、重要なワークフローにはもっと厳しいチェックが入るし、全員が罠にハマったわけじゃない。例外もたくさんある。でも、これがミームとして定着しているのには理由がある。大抵の人は、割り当てられたコードを真剣にレビューなんてしてなかった。ほとんどの内容に実質的なゴム印を押していただけさ。

そんな時代にAIが登場して、今でも人々はAIの相棒Claudeがやっていることに対して責任を負うことを期待されている。PRを少し眺める以上のことをしているなんて考えるのは無理があるし、多くの組織では、意識的に人間をループから外そうとしているんだから。

いつかAIの開発やコードレビューが成熟して、こんなミスは極めて稀になるだろう。ただ、近い将来に関しては、状況が改善する前に、むしろこういう問題をもっと見ることになると予想してるよ。

ヒューマンエラーだね。

AIが生成したコードだって、人間の書いたコードと同じように、コード品質、SAST、SCAなどでスキャンしなきゃいけない。検証せずにAIのコードをそのまま受け入れたなら、それは自業自得だよ！