GitHub 的 AI 安全 Agent 开始批量挖漏洞了。9 月 28 日，GitHub Security Lab 在官方博客公布：研究员用其开源的 AI 安全 Agent 审计 Android 应用，已发现并报告 24 个漏洞，其中两个高危案例已经公开披露——一个能让任意应用追踪用户的精确位置，另一个能直接接管维基百科账户。
这套工具叫 seclab-taskflow-agent，配套的审计任务流 seclab-taskflows 全部开源。它的思路不是把整个代码库丢给大模型碰运气，而是用 YAML 提示词把审计拆成增量步骤，让研究员把"怎么审"封装成可复用的任务流。针对 Android，这次新增了两个专用任务流：gather_mobile_entry_point_info 负责找出攻击者可控数据能流入的代码入口，并区分移动端与非移动端攻击面；classify_application_local 则按入口点类型，列出该查的常见漏洞类别——比如遇到 intent 入口，就提醒模型检查 confused deputy（混淆代理人）、不安全广播这类移动端特有问题。
跑起来也不复杂：在 seclab-taskflows 仓库开一个 Codespace，执行 ./scripts/audit/run_mobile.sh 加上目标仓库，中等规模仓库一两个小时出结果，结论写进 SQLite 数据库，看 has_vulnerability 列打勾的行即可。门槛有两道：需要 GitHub Copilot 许可，且审计会消耗大量 premium 模型请求，token 账单不便宜。
两个已经披露的高危案例
第一个是 OsmAnd——下载量超 1000 万的开源导航应用。它的 MapActivity 是导出的，任何应用都能向它发 intent；而处理设置导入的函数又直接信任了 intent extras 里的 silent_import、replace 等参数。这意味着，一个毫无权限的恶意应用可以静默改写 OsmAnd 的设置，把地图瓦片地址换成攻击者域名：用户每加载一块地图瓦片，瓦片的精确坐标就会发到攻击者服务器——等于实时位置泄露；同一漏洞还能拿到用户每条路线的起点和终点，而用户毫无察觉。
第二个是维基百科 Android 应用，两个逻辑 bug 链式利用形成账户接管。应用注册了 wikipedia:// deeplink，但主机名解析只检查了域名后缀，导致 evil-wikipedia.org 这类域名也能通过检查，把用户引到攻击者页面；同时 cookie 管理器的域名检查同样只比对后缀，攻击者页面就能拿到维基百科的长期会话 cookie——一个 cookie 通行所有 Wikimedia 项目，用户名、长期 token 一并泄露。
LLM 找得到漏洞，但算不准危害
博客也坦言了这套方法的短板：LLM 很擅长发现漏洞，甚至能挖出人类容易漏掉的逻辑漏洞，但它不擅长估计严重性——经常上报影响很小的低危问题，对路径穿越这类"有缓解因素"的情况也容易误判。每个发现仍然需要懂移动安全的研究员复核，严重时还得让模型实际构造 PoC 来验证可利用性。
这件事的意义不在于"24"这个数字，而在于审计方法第一次被做成了开源、可复现的流水线。此前 Security Lab 已经开源了针对 C/C++ 的 AI 模糊测试任务流（指个仓库地址就能自动挖漏洞），这次补上了移动端。对普通开发者的实际价值很直接：不用等安全团队排期，自己对着仓库跑一遍，就能先扫出一批真实问题。
