AI Coding Agentのセキュリティリスク：PRの自己承認とメルカリの対策

AI を活用したコーディングエージェントは急速に浸透していますが、設定を誤るとソースコード管理システムに新たなセキュリティリスクが生じます。エージェントが GitHub などのバージョン管理システムと連携する典型パターンを整理し、プルリクエスト自動生成時に起こり得るPRの自己承認問題を示します。その上で、ブランチ保護やルールベースのゲートキーパーなど実践的なガードレールを紹介しながら、AI コーディングエージェントを安全に活用するメルカリでの取り組みを紹介します。

Transcript

1. 1 AI Coding Agentのセキュリティリスク： PRの⾃⼰承認とメルカリの対策 CNCJ: コーディングエージェント × セキュリティ ミートアップ 株式会社メルカリ Choi Chun Ming
2. 2 ⾃⼰紹介 Choi Chun Ming @s3h_____ 株式会社メルカリ Platform Security Team所属 社内のGitHubおよびGoogle Cloudの セキュリティ改善を⾏っている
3. 3 コードレビューについて考えたことがありますか？ PRを作成した⼈はレビューできないのでこうならないが...
4. 4 AI Coding Agentを導⼊すると... こうならないのか、考えたことありますか？
5. 5 1. PRの⾃⼰承認問題 〜AI Coding Agentを添えて〜 2. AI Coding Agentってどうやって動いているの？ 3. AI Coding Agentとバージョン管理システム 4. Status checkでPRを安全に作成する 5. Policy Botを利⽤する 6. Policy Botと他の対策の⽐較 7. まとめ ※スライドは講演後公開します アウトライン
6. 6 • 「PRの⾃⼰承認問題」を解決したい ◦ コードの変更を作成した⼈のほかに、必ずもう1⼈がレビューしなけ ればいけない ◦ セグリゲーション (segregation of duties)：業務における執⾏者と 承認者の権限‧職責を分離し明確に定めること ◦ コンプライアンス上必要な場合あり ▪ PCI-DSS Requirement 6.2.3 • How to bypass GitHub’s Branch Protection (@iso)で⼀部⽰した • AI Coding Agentの導⼊によって、問題がさらに深刻になる 1. PRの⾃⼰承認問題 〜AI Coding Agentを添えて〜
7. 7 2. AI Coding Agentってどうやって動いているの？ → 分類 AI Coding Agentは、主に3種類あります： • 開発者のローカルマシンで動くAI Coding Agent ◦ Claude Code, GitHub Copilot, Cursor, Aider, OpenAI Codex CLI, Gemini CLI • リモート環境で動くAI Coding Agent ◦ Devin, OpenAI Codex, Jules, Cursor bugbot • CI/CDで動くAI Coding Agent ◦ Claude Code Action, Gemini CLI Action ◦ → 主にこちらについて説明します
8. 8 2. AI Coding Agentってどうやって動いているの？ → Claude Code編 （Cursor, Aider, OpenAI Codex CLI, Gemini CLIなども同じ）
9. 9 (OpenAI Codex, Julesなども同じ） 2. AI Coding Agentってどうやって動いているの？ → Devin編
10. 10 2. AI Coding Agentってどうやって動いているの？ → Claude Code Action編 （Gemini CLI Actionなども同じ）
11. 11 思い出してみて... 安全なのかどうか、 考えたことありますか？
12. 12 3. AI Coding Agentとバージョン管理システム 〜AIより前のセキュリティ〜 • GitHubの設定でこのようなレビューを必須にする
13. 13 先の設定のままだと... • AIに変更をお願いした⼈が、そ のまま作成されたPRを承認し マージできる → セグリゲーションが保証され なくなる • これをどうやって対策するの か？ • 2⼈レビュアー必要にする？ → ⽣産性に⼤きく影響 3. AI Coding Agentとバージョン管理システム 〜AI導⼊後のセキュリティ〜
14. 14 Claude Code Actionなど、CIを発⽕させるため権限を与えなければならず、そ れを再利⽤することで「もう⼀つの承認」を作ることができる場合がある 例えば、"Allow GitHub Actions to create and approve pull requests" を正し く設定しないと、このようなフローでスプーフィング※できます： 3. AI Coding Agentとバージョン管理システム 〜スプーフィングが容易に起こります〜 How to bypass GitHub’s Branch Protection (@iso) にご参照ください ※ スプーフィング：別の⼈ 物やプログラムに⾒せかけ る事を利⽤した攻撃
15. 15 3. AI Coding Agentとバージョン管理システム 〜そもそも達成したいこととは？〜 • 開発者が作成するプルリクエストは、別の開発者から⼀つの承認が必要 • 開発者が、AIエージェントを⽤いて作成したプルリクエストは、 開発者2⼈（お願いした⼈と、もう1⼈のレビュアー）の承認が必要 • （+ 限られた例外） 前者に寄せる（1⼈）と、セキュリティの問題が起きる 後者に寄せる（2⼈）と、⽣産性が⼤きく下がることがある → 両⽅実現できるようにしたい
16. 16 4. Status checkでPRを安全に作成する 〜Status checkとは〜 このように、コミットにstatus checkをつけることができる GitHub Actionsから、またはGitHub APIから設定することができる PRをマージするときの必須チェックに設定できます • GitHub：Status checks • GitLab：External status checks • BitBucket：Code insight
17. 17 4. Status checkでPRを安全に作成する 〜Status checkを利⽤する〜 • 開発者が作成するプルリクエストは、別の開発者から⼀つの承認が必要 • 開発者が、AIエージェントを⽤いて作成したプルリクエストは、 開発者2⼈（お願いした⼈と、もう1⼈のレビュアー）の承認が必要 の条件が満たされていたらstatus checkを設定し、またrulesetで必須status checkに設定する。
18. 18 このルールが適⽤されると... 4. Status checkでPRを安全に作成する 〜問題を解決する〜 GitHub Actionsからの承認が カウントされない 承認が1つ⾜りない
19. 19 4. Status checkでPRを安全に作成する 〜Status checkを安全に利⽤する〜 ただし、Status checkは、実は GitHub Actions からでも、 誰もが書き込むことができる！ → そうならないように、専⽤のGitHubアプリを作成して、   そのGitHubアプリからのstatus checkを必須にする では、こちらのstatus checkをどうやって設定するのか？
20. 20 5. Policy Botを利⽤する 〜Policy Botとは〜 palantir/policy-bot（mercari/policy-botにフォーク）は、 「プルリクエストの承認ポリシーを適⽤するGitHubアプリ」 （"A GitHub App that enforces approval policies on pull requests"） → 任意のプルリクエストに対して、条件を満たすときのみstatus checkを設定 するようなGitHubアプリである
21. 21 Policy Botのアーキテクチャがこのようになります： 5. Policy Botを利⽤する 〜Policy Botのアーキテクチャ〜
22. 22 例えばこのようなルールを設定することができる： 5. Policy Botを利⽤する 〜Policy Botを設定する〜 policy: approval: - or: - developer - fallback approval_rules: - name: developer if: only_has_contributors_in: teams: ["developers"] requires: count: 1 - name: fallback requires: count: 2 開発者からのコミットのみならば 1つの承認が必要 2つの承認が必要 2つの承認ルールのいずれかを満たしてい る必要がある
23. 23 今の状態がわかりやすくするために、デバッグ⽤のUIも⽤意されています： 5. Policy Botを利⽤する 〜Policy Botを運⽤する〜
24. 24 影響が出ないように導⼊するため、 • 導⼊するため、⼀ヶ⽉分のプルリクエストの情報を取得し、ルールに満た しているかどうかを確認した ◦ 満たしていないものは最低限の除外ルールを追加した ◦ 今後少しずつ除外ルールを削除する予定 • また、段階的に必須ステータスを有効化した ◦ GitHubのCustom Properties及びOrganization Rulesetを利⽤する ◦ セキュリティチームが管理するレポジトリに展開する → 利⽤上問題ないことを確認してから → 外部向けサービスのリポジトリに展開した 5. Policy Botを利⽤する 〜Policy Botを導⼊する〜
25. 25 最近話題になっている、他の対策との⽐較です。 6. Policy Botと他の対策の⽐較 Organization 全体に適⽤する 回避されない リポジトリかんに ルールを共有する 導⼊の難易度 newmoの ai-pull-request-protection （共通ワークフロー） △1 Workflowまで 共有できる △ github-actions、 status APIで回避 ◯ 共通ワークフローの コードを変更する ◎ 必須workflowを 追加するのみ suzuki-shunsuke/ validate-pr-review-action △1 Workflowまで 共有できる △ status APIで回避 △ 複数ワークフロー ◎ 必須workflowを 追加するのみ mercari/policy-bot ◎ 必須status check ◎ 回避しにくい ◎ 直接定義できる △ サーバーを⽤意する 必要あり [1] rulesetのrequired workflowはpull_request の opened, synchronize, reopenedでのみ発⽕しま すので利⽤できない
26. 26 7. まとめ • 今回は「PRの⾃⼰承認問題」に対して、柔軟に設定できるPolicy Botを⽤ いて対策した • AI Coding Agentを安全に運⽤するのに、まだベストプラクティスがわか らないものが多い • AI Coding Agentの導⼊によって、今までの仮定の中で成り⽴たなくなった ものもあるので、必要なセキュリティ対策を⾒直したい セキュアなAI Coding Agent利⽤を！ スライドは右のURLからアクセスしてください。