AIを駆使した OSS脆弱性調査のすゝめ

学生セキュリティLT会&交流会 in 仙台で登壇したスライド

Transcript

1. AI × Code Reading × Responsible Disclosure 2026.07.05 LT会 AIを駆使した OSS脆弱性調査のすゝめ GitHubを知っている人向けに、AI時代のOSS脆弱性 調査をやさしく分解する話 Saku0512 佐藤佑作 saku0512.com
2. GitHubぐらいは知ってる、で十分 このLTのゴール 初学者でも「脆弱性調査の全体像」がつかめる構成 持ち帰ってほしいこと OSS脆弱性調査は、特別な人だけの作業ではな い AIは「答え」より「読む順番」を作るのが強い CVEを狙う前に、根拠を説明できることが大事 今日の主役は「攻撃テク」ではなく、 コードを読んで仮説を検証する型 Saku0512 / AI × OSS Vulnerability Research 02
3. セキュリティに興味を持った流れ CTFから始まり、実装の“なぜ”を追う方向へ 最初は「壊せる」ことより、 “なぜ壊れるのか ” が面白かっ た。 01 CTF 攻撃の形を知る 02 Web / 低レイヤー 原因を実装で見る 03 OSS 実際のコードを読む 04 報告 直るところまで追う 脆弱性調査は「読む → 仮説 → 検証 → 伝える」の繰り返し Saku0512 / AI × OSS Vulnerability Research 03
4. 脆弱性調査って、何を見ているの？ 基本は「入力」が危険な文脈へ入る境界を追うこと 入力 URL / ファイル名 環境変数 / 設定 変換 結合 / パース エスケープ / 正規化 実行・解釈 Shell / DB / HTML Path / Terminal 影響 情報漏えい 権限越え / RCE よくある落とし穴 「文字列として安全」でも、ShellやHTMLに入ると意味が変わる 正規化・エスケープ・権限チェックの順序がずれる 便利機能のHookやPluginは、境界が増えやすい Saku0512 / AI × OSS Vulnerability Research 04
5. AIは「答え」ではなく、読む速度を上げる道具 AIの出力を信じるのではなく、ソースコードで確認する AIに任せること 巨大なリポジトリの地図化 危険な境界の候補出し 過去CVE・修正PRの要約 人間が必ずやること 根拠行を読む 安全な環境で最小再現する 影響範囲を盛らずに書く AIの幻覚は、コードで倒す Saku0512 / AI × OSS Vulnerability Research 05
6. 自分の調査ワークフロー AIを混ぜる場所と、人間が握る場所を分ける 1 OSS選定 小さく・機能が明確 2 入口調査 入力点と権限を見る 3 AIで地図化 候補を広く出す 4 手で読む 根拠行を確認 5 最小PoC 安全に再現 6 報告 直る形で伝える Saku0512 / AI × OSS Vulnerability Research 06
7. 初学者が追いやすい「狙い目」 危ないのは、文字列が別の意味で解釈される境界 見るポイント Command construction 文字列をOSコマンドに連結していないか File / Path handling 正規化前に権限チェックしていないか Hook / Plugin 便利機能がユーザー入力を実行していないか Terminal / Escape 制御シーケンスでUI状態を偽装できないか Auth / Redirect 境界・許可リストの解釈がズレていないか 危険な境界の例 cmd = "tool " + input shell(cmd) # “文字列” が # “命令” になる瞬間 ポイント：探すのは「怪しい関数名」ではなく、入力が危険な文脈に入る “線” Saku0512 / AI × OSS Vulnerability Research 07
8. 結果：公開済 CVE 6件 公開情報ベース。非公開・調整中の内容は話せる範囲だけ 6 公開済CVE Critical 1 / High 3 / Medium 2 CRITICAL 1 HIGH 3 MEDIUM 2 CVE-2026-35585 File Browser / Hook system CVE-2026-40176 Composer / Perforce VCS CVE-2026-54088 File Browser / Hook Auth CVE-2026-48732 Warp / SSH cwd CVE-2026-54686 Warp / DCS lifecycle CVE-2026-54761 Traefik / Gateway namespace 大事なのは数より、「なぜ成立するか」を説明できる状態まで持っていくこと Source: saku0512.com（2026/06/28閲覧） Saku0512 / AI × OSS Vulnerability Research 08
9. 報告で大事なこと 見つける力と同じくらい、伝える力が重要 再現条件を最初に書く 影響範囲を盛らない 原因箇所と修正方針を示す 未公開情報は外に出さない メンテナーに敬意を払う 目的は「壊す」ことではなく、 直るところまで届けること Saku0512 / AI × OSS Vulnerability Research 09
10. 今日からできる練習 AIに聞く前に、何を確認したいかを決める 01 小さなOSSを1つ選ぶ 機能が少なく、ローカルで動かせるものから始める 02 入力点を洗い出す URL・ファイル名・設定・環境変数・ CLI引数を見る 03 AIに“読み方”を聞く 候補と根拠行を出させ、必ず自分でコード確認する 04 既知CVEの修正PRを読む 「どこが直ったか」から逆算すると学びやすい AIへの聞き方例：この関数の入力値が OSコマンド・ファイルパス・ HTML に渡る経路を、根拠行つきで列挙して Saku0512 / AI × OSS Vulnerability Research 10
11. まとめ AIは速度を上げる でも証明するのは人間 脆弱性は境界で生まれる 入力が別の意味に変わる場所を 見る CVEは目的ではなく副産物 根拠を持って報告できることが本 質 Thank you Q&A saku0512.com Saku0512 / AI × OSS Vulnerability Research 11