運用して初めてわかったDevinのセキュリティ課題 - Devin Meetup Tokyo 2025

by Hi120ki

Slide 1

Slide 1 text

1 運⽤して初めてわかったDevinのセキュリティ課題 Devin Meetup Tokyo 2025 株式会社メルカリ Hiroki Akamatsu

Slide 2

Slide 2 text

2 ⾃⼰紹介 Hiroki Akamatsu @hi120ki 株式会社メルカリAI Security Team所属 ● 外部AIツールのセキュリティレビュー ● 安全な利⽤⽅法やガイドライン策定 ● 社内のAIの取り組みのセキュリティ確保 ● Platform(クラウド‧GitHub等)整備 ● 社内LiteLLM基盤構築

Slide 3

Slide 3 text

3 組織でのDevin利⽤所属組織でDevinを利⽤中✋

Slide 4

Slide 4 text

4 組織でのDevin利⽤ AIで起きるヒヤリハット

Slide 5

Slide 5 text

5 組織でのDevin利⽤ AIで起きるヒヤリハット⼤事なファイルが消されるかもテストDBが初期化されるかも認証情報がそのまま表⽰されるかも AIによる変更が確認されず本番適⽤されるかも

Slide 6

Slide 6 text

6 組織でのDevin利⽤セキュリティを気にせずにDevinを使うと ❗Devinが書いたコードを誰もチェックしないまま本番適⽤ ❗Devinから別の⼈のクラウドなどの認証情報を盗める ❗気付かないうちに外部にソースコードが流出‧変更 ❗AI Agentが暴⾛して本番‧テスト環境を破壊

Slide 7

Slide 7 text

7 組織でのDevin利⽤セキュリティを気にせずにDevinを使うと ❗Devinが書いたコードを誰もチェックしないまま本番適⽤ ❗Devinから別の⼈のクラウドなどの認証情報を盗める ❗気付かないうちに外部にソースコードが流出‧変更 ❗AI Agentが暴⾛して本番‧テスト環境を破壊 Devinの機能の理解と使い⽅の改善が必須

Slide 8

Slide 8 text

8 組織でのDevin利⽤抑えるべきポイント 1. Devinってどうやって動いているの? 2. Pull Requestって勝⼿に作られるけどいいの？ 3. 他のツールとの連携のセキュリティはどうする? 4. どうやってDevin‧AI Agentを安全に制御する?

Slide 9

Slide 9 text

9 組織でのDevin利⽤抑えるべきポイント 1. Devinってどうやって動いているの? 2. Pull Requestって勝⼿に作られるけどいいの？ 3. 他のツールとの連携のセキュリティはどうする? 4. どうやってDevin‧AI Agentを安全に制御する? 理解と対策を1つずつ積み重ねていく

Slide 10

Slide 10 text

10 1. Devinってどうやって動いているの? https://docs.devin.ai/integrations/gh

Slide 11

Slide 11 text

11 1. Devinってどうやって動いているの? GitHub Appでコードなどの読み取り書き込みを許可

Slide 12

Slide 12 text

12 1. Devinってどうやって動いているの?

Slide 13

Slide 13 text

13 2. DevinのPull Request DevinのPull Requestをレビューしていますか?

Slide 14

Slide 14 text

14 2. DevinのPull Request Branch Rulesetでレビュー必須化推奨: Require a pull request before merging ● Required approvals = 1 ● Require review from Code Owners ● Require approval of the most recent reviewable push → このままの設定だとDevinが作ったPull Requestを⾃⼰承認可 → 他の⼈のチェックなくコードが本番環境で動作

Slide 15

Slide 15 text

15 2. DevinのPull Requestの⾃⼰承認 Devinが作ったPull Requestを⾃⼰承認 1. Devinに指⽰ 2. DevinがPull Requestを作成 3. Pull Requestを指⽰者が⾃⾝で承認‧マージチェックなくコードがマージされ本番環境へ → Devinだけではなく他のAI Coding Agentサービスも同様

Slide 16

Slide 16 text

16 2. DevinのPull Requestの⾃⼰承認 AI Coding Agent以外でも起きるPull Requestの⾃⼰承認 GitHubのBranch Protectionの突破⽅法 - Mercari Engineering 1. 別の⼈がPull Requestを作成 2. GitHub Action経由で1のブランチに変更を追加 3. Pull Requestを承認‧マージするチェックなくコードがマージされ本番環境へ

Slide 17

Slide 17 text

17 2. DevinのPull Requestの⾃⼰承認対策 2⼈の承認を必要とするワークフロー整備 (Devinが作るPull Requestのセルフマージを禁⽌する - newmo 技術ブログ) ⽋点 1. 設定によっては制限を回避可 ○ ワークフロー⾃体を書き換え検査を無効化 ○ 同じ名称のStatusを書き込み 2. 組織内の全レポジトリへの⼀括適⽤が不可 ○ Requiring workﬂows with Repository Rulesetsでは pull_request_reviewイベントはサポート対象外 3. AI Coding Agentの追加で更新が必要

Slide 18

Slide 18 text

18 2. DevinのPull Requestの⾃⼰承認対策 palantir/policy-botをフォーク‧導⼊して対策 ● ワークフローやStatusの上書きなどの回避が不可 ● 組織全体に⼀括適⽤可 ● Devinだけではなく他のAI Coding Agentも⼀括で対策

Slide 19

Slide 19 text

19 2. DevinのPull Requestの⾃⼰承認対策 policy-botの運⽤ ● “⼈”のみがコミット‧Pull Requestを作成 → 別の1⼈からの承認が必要 ● “⼈”だけでなく“機械”がコミット‧Pull Requestを作成 → 2⼈(指⽰者+別の1⼈)からの承認が必要この条件を逐次検査しStatusに反映 GitHub組織設定からStatusの通過を必須に設定 → Devinだけではなく他社AI Agent‧他経路からの⾃⼰承認を防⽌

Slide 20

Slide 20 text

20 DevinとGitHubのセキュリティのまとめ組織のBranch Ruleset設定＋ policy-bot ● Require a pull request before merging ○ Required approvals = 1 ○ Require review from Code Owners ○ Require approval of the most recent reviewable push ● 回避が不可かつ組織設定から適⽤可能なセキュリティコントロール安全にDevinの変更を受け⼊れられる環境を構築

Slide 21

Slide 21 text

21 3. Devinとツール連携のセキュリティテスト環境と連携したい API Keyを⼊⼒してくれと促してくるもっと社内情報を渡したいそのままDevinに個⼈のAPI Keyを渡していませんか?

Slide 22

Slide 22 text

22 3. Devinとツール連携のセキュリティ Devinに個⼈のAPI Keyを保存し利⽤ → 現在のDevinの仕様ではあぶないあるOrganization内ですべてのSessionを閲覧‧コマンド実⾏可 ● 他の⼈が作成したSessionをブラウザで開いて... ● その認証情報をそのままチームで使いまわして... → いつ‧どこで‧だれが何を変更したのか追跡不可

Slide 23

Slide 23 text

23 3. Devinとツール連携のセキュリティ 1. テスト環境やプラットフォーム連携はGitHub Actionで ○ GitHub Actionsでのシークレット管理はレポジトリシークレットを使わない(どのワークフローからも取得可) ○ Workload Identity FederationやAssumeRoleWithWebIdentityとクラウド上のシークレット管理 2. Devin Secretで最低限の認証情報を管理 ○ 個⼈に紐づかないサービスアカウントからの認証情報 ○ 読み取り権限のみ‧範囲を指定 ○ 定期的に取り替え

Slide 24

Slide 24 text

24 3. Devinとツール連携のセキュリティどれだけ対策してもDevinには認証情報が残る

Slide 25

Slide 25 text

25 Devin環境内の認証情報 1. GitHub AppのInstall Access Token ○ Organizationに登録されたレポジトリの読み書き権限 ○ 有効期限は1時間 2. Devin Secretに保存されている認証情報 3. Session内に保存された認証情報 → Devinはこれらの認証情報を⾃由に扱うことができる 3. Devinとツール連携のセキュリティ

Slide 26

Slide 26 text

26 Devinからの認証情報の流出 → ソースコード流出‧改ざん、情報漏洩等 1. Prompt Injection攻撃によりDevinが攻撃者に誘導‧⾏動 2. Supply-chain攻撃で間接的に流出 3. Devinとツール連携のセキュリティ

Slide 27

Slide 27 text

27 (1) Prompt Injection攻撃によりDevinが攻撃者に誘導‧⾏動 Web検索等で読み込んだコンテキストから指⽰が上書き Codex agent internet access Preset domain listsなど軽減は可根本対策はインターネットの遮断 → ⽣産性への影響 3. Devinとツール連携のセキュリティ

Slide 28

Slide 28 text

28 (2) Supply-chain攻撃で間接的に流出 Devinが偽のツールやライブラリを導⼊して流出 ● 有名ライブラリに名前を似せた偽ライブラリやツール ● 有名ライブラリ⾃体が乗っ取られて改ざん Vulnerability DB - Snyk Malicious Package DevinにはEDR等の⼀定の対策が存在しない → 認証情報が盗まれたことに気付けない → プロンプトで導⼊させない指⽰‧Sessionの監視による軽減 → 認証情報の定期的な取り換え 3. Devinとツール連携のセキュリティ

Slide 29

Slide 29 text

29 4. どうやってDevinを安全に制御する? 攻撃を受けなくてもDevin(= AI Agent)がやらかしてしまう暴⾛して本番環境‧テスト環境を破壊

Slide 30

Slide 30 text

30 4. どうやってDevinを安全に制御する? 攻撃を受けなくてもDevin(= AI Agent)がやらかしてしまう暴⾛して本番環境‧テスト環境を破壊 ● Devinから本番環境へデプロイしない ● Devinには最⼩のアクセス権限を付与

Slide 31

Slide 31 text

31 4. どうやってDevinを安全に制御する? 攻撃を受けなくてもDevin(= AI Agent)がやらかしてしまう暴⾛して本番環境‧テスト環境を破壊 ● Devinから本番環境へデプロイしない ● Devinには最⼩のアクセス権限を付与 AIは実⾏可能なすべての⾏動‧利⽤可能なすべての権限を使う前提 → プロンプトで完全な制御はできない

Slide 32

Slide 32 text

32 4. どうやってDevinを安全に制御する? 攻撃を受けなくてもDevinがやらかしてしまう暴⾛して本番環境‧テスト環境を破壊 ● Devinから本番環境へデプロイしない ● Devinには最⼩のアクセス権限を付与 AIは実⾏可能なすべての⾏動‧利⽤可能なすべての権限を使う前提 → プロンプトで完全な制御はできない → プロンプトで⾏動範囲を指⽰しつつSession履歴の監視による軽減

Slide 33

Slide 33 text

33 Devinの安全な利⽤のために現在AI Agentのエコシステムは発展途上 1. 技術的なガードレール整備が追いついていない ○ 根本対策と軽減策が⼊り乱れる ○ ⽣産性とのバランスを考える必要 2. ユーザーもAIのセキュリティをキャッチアップ中 ○ まずは基本的なセキュリティ対策から ○ ⼀旦セキュリティチームに相談する⽂化

Slide 34

Slide 34 text

34 Devinの安全な利⽤のために現在AI Agentのエコシステムは発展途上 1. 技術的なガードレール整備が追いついていない ○ 根本対策と軽減策が⼊り乱れる ○ ⽣産性とのバランスを考える必要 2. ユーザーもAIのセキュリティをキャッチアップ中 ○ まずは基本的なセキュリティ対策から ○ ⼀旦セキュリティチームに相談する⽂化技術の改善とリテラシー向上で事故なくAI活⽤を続ける

Slide 35

Slide 35 text

35 Devinにリクエストしていること 1. Devin SecretのCreate API追加 → 将来的なSecretの⾃動取り替え実装 2. ある⼈が作成したSessionを他の⼈からRead-onlyに → 別の⼈のSession操作による意図しない変更や情報流出の阻⽌ → 最終的には個⼈ごとに厳密な権限管理が実装されることを期待 3. コミット署名のサポート → GPGキーの共有やghcommit CLIではなく公式のサポートをよりDevinをSecure by Defaultに