24 个漏洞真正说明了什么9 月 28 日GitHub Security Lab 公布了一组很有代表性的结果研究人员把面向 Android 的审计流程写成可复用的 AI Taskflow已经发现并报告了24 个 Android 漏洞。这件事比“AI 又会找漏洞了”更值得看因为真正变化的不是模型突然变成安全专家而是安全工程师开始把自己的审计方法拆成一条可以重复执行、可以检查中间结果、可以让不同 Agent 接力的工程流水线。传统做法往往是把整个仓库丢给模型再问一句“帮我找安全问题”。这类提示词看似省事却同时丢掉了攻击面建模、入口点分类、上下文收集、漏洞类型约束和复现验证。仓库越大模型越容易在大量代码里来回漂移。GitHub Security Lab 这次展示的路线恰好相反先把问题拆小再让每一步只处理它应该看到的信息最后把结果汇合。官方发布的 Security Lab Taskflow Agent 是一个支持 MCP 的多 Agent 框架工作流通过 YAML 声明底层使用 OpenAI Agents SDKPydantic 负责语法校验Jinja2 负责模板渲染。它的价值不是提供一个“最聪明的安全模型”而是把研究人员已经验证有效的提示、工具和步骤固化下来让审计经验从一次性对话变成可以版本化的资产。在 Android 场景里这种固化尤其重要。移动应用的高风险问题经常不是某一行代码出现危险函数而是多个组件的权限、Intent、Deep Link、WebView、存储和身份状态拼在一起才形成攻击链。模型如果只盯某个函数很容易看见局部异常却理解不了攻击者从哪里进入、数据如何跨组件流动、最终影响落在哪里。第一步不是找漏洞而是先画出攻击入口GitHub 的移动审计流程新增了一个名为gather_mobile_entry_point_info的任务。它先识别代码里的入口点再区分移动入口和非移动入口。这个动作看上去普通实际决定了后面的搜索空间。对于 AndroidActivity、Service、BroadcastReceiver、ContentProvider、Deep Link、导出的组件以及跨进程接口都可能成为外部输入抵达应用内部逻辑的起点。安全审计最怕把“能被外部触达”和“只在应用内部调用”混在一起。同样一段参数处理代码如果调用者只能是应用自身风险和一个 exported Activity 完全不同。先标注入口就等于给 Agent 一张带边界的地图哪些数据可能由攻击者控制哪些组件处在信任边界上哪些后续调用值得继续追踪。第二个关键任务是修改后的classify_application_local。研究人员没有只让模型自由联想而是明确列出移动端常见漏洞类别让 Agent 根据入口类型逐项考虑风险。例如当入口是 Intent 时就要求关注 confused deputy、危险的 extras、广播暴露等问题。严格清单负责减少漏报更开放的审查负责发现清单之外的组合问题两者通过多轮运行互补。这里体现了一个很实用的 Agent 工程原则模型的创造力适合扩展搜索规则化 Taskflow 适合稳定覆盖。只靠规则容易漏掉新型组合漏洞只靠自由推理每次审计范围又会漂移。把“必须检查什么”和“还可能有什么”分成两条任务再在后面合并结果往往比写一条超长系统提示更稳定。审计方式主要优点主要问题单轮通用 Prompt启动快、成本低覆盖范围漂移难复现容易遗漏入口关系固定规则扫描确定性强、适合已知模式难理解跨组件语义和复杂业务逻辑Taskflow Agent能拆任务、保留上下文、重复运行需要设计流程并承担更多模型调用成本OsmAnd 案例真正的漏洞藏在 Intent extras 里官方文章给出的第一个高影响案例来自 OsmAnd Android 应用。研究人员关注到一个导出的 MapActivity它负责处理设置文件和 Deep Link。危险点并不在“导出 Activity”本身而在它继续接受一组原本只应该由受信任 AIDL 服务传入的 Intent extras包括 settings_version、silent_import、replace 和 export_type_list_key。Android 不会自动限制外部应用给 exported Activity 填哪些 extras。于是只要外部应用能够启动这个 Activity就可以构造原本内部流程才会使用的参数。silent_import 会让导入过程减少用户感知replace 会允许替换现有配置export_type_list_key 又能改变具体导入哪些设置。几个普通布尔值和列表参数组合起来信任边界就被打穿了。更关键的是后续影响。攻击者能够改写地图瓦片配置把原本本地或可信来源的 tile URL 改成攻击者控制的服务器地址。地图加载时请求路径会携带 zoom、x、y 等瓦片坐标。单个请求看起来只是在取一张地图图片但连续坐标足以推导用户查看或经过的位置官方案例还指出同一问题可以进一步暴露路线的起点和终点。这个案例说明为什么 Agent 的优势不应该只用“能不能发现危险 API”来衡量。真正需要的推理链是外部应用能否启动组件 → 哪些 extras 可控 → 这些参数进入什么导入逻辑 → 配置能否改变网络目标 → 网络请求中包含什么位置语义。每一跳都不复杂难的是把几跳连起来。Wikipedia 案例一个 endsWith 串起 Deep Link 与 Cookie第二个案例更适合说明跨组件组合。Wikipedia Android 客户端注册了 wikipedia:// Deep Link并检查 URI 的 authority 是否以 Wikipedia 的基础域名结尾。问题在于字符串后缀判断并不等于真正的域名边界判断。类似 evil-wikipedia.org 这样的攻击者域名同样可能满足错误的 endsWith 条件。一旦攻击者控制的地址被应用内部 WebView 打开问题就从“错误跳转”升级成了应用内网页上下文。GitHub Security Lab 的分析还发现另一个相似的域名后缀判断出现在 Cookie 相关逻辑中。两个原本分散的缺陷组合后攻击者页面有机会拿到原本属于 Wikipedia 域的长期 Cookie从而形成账户接管链。这种漏洞很符合大型代码库的现实第一处代码只负责 URI第二处代码只负责 Cookie两处维护者甚至可能完全不同。基于单文件的代码补全很难主动把它们联系起来而审计 Taskflow 可以先记录“这里存在攻击者可控 WebView 导航”再把这一事实作为后续任务的上下文继续寻找认证信息、脚本桥接和持久化状态。因此多 Agent 在这里并不是为了“同时开几个模型显得更强”。真正有价值的是任务之间存在结构化交接。前一阶段产出入口点和信任边界后一阶段在这个边界上寻找危险数据流再后一阶段要求给出可验证的攻击条件。只要每一阶段的输入输出格式稳定模型替换、提示词迭代和工具升级都不需要推倒整条流水线。为什么重复运行比一次高分答案更重要GitHub Security Lab 明确提到大模型具有非确定性。相同仓库、相同任务不同运行可能看到不同问题。研究人员因此把严格提示和更宽泛提示组合并通过多次运行取长补短。这与传统静态分析“同样输入必须同样输出”的习惯不同却更像人工安全审计第一轮建立地图第二轮沿可疑路径深挖第三轮专门挑战前面的判断。这也意味着评估 Agent 审计能力时不能只问一次运行找到了多少漏洞。更合理的指标应该包括入口点覆盖率、已知漏洞召回率、重复运行新增发现比例、错误报告比例、可复现 PoC 比例、每个有效发现消耗的模型请求和人工复核时间。否则模型很容易用大量低价值告警制造一种“很能找”的假象。官方文章也直接承认一个短板模型对漏洞严重性的判断经常不准。有些报告在静态代码上看起来成立但真实运行条件极其苛刻有些路径遍历看起来能写外部存储最终却会被内部存储的高优先级数据覆盖攻击效果并不存在。能描述风险不等于已经证明风险。把“发现”改造成“可复现”才进入工程阶段所以真正可靠的流水线必须在“疑似漏洞”之后再加一道验证门。对于路径遍历要确认攻击者控制的路径最终是否真的影响应用读取的数据对于 Deep Link要确认恶意 URI 能否进入目标 WebView对于 Intent要确认目标组件在安装包里确实 exported并且调用不需要攻击者拿不到的权限。模型的结论只是候选运行时证据才是安全事实。GitHub 的做法里有一个很重要的细节为了降低误报研究人员会让模型继续生成并运行 PoC迫使它面对真实程序行为。模型在阅读代码时可以忽略生命周期、优先级、系统版本、默认配置等条件但 PoC 一跑这些假设就会被操作系统和程序本身检验。无法复现的报告应该降级而不是靠更自信的自然语言继续往前推。这也是 AI 安全审计与普通代码助手的分水岭。代码助手追求的是尽快给出一个可接受修改安全审计更关心证据链是否闭合。一次真正可提交的发现至少要能回答四个问题攻击者需要什么前置条件攻击输入从哪个入口进入数据或控制流经过哪些关键节点最后能观察到什么安全影响。Taskflow Agent 的工程价值在“声明式”Security Lab Taskflow Agent 把这些步骤放进 YAML而不是把所有逻辑写死在某个 Python 程序里。这样做的好处是研究人员可以把“入口点枚举”“组件分类”“数据流追踪”“PoC 验证”分别维护也可以让不同模型承担不同阶段。某个提示词改进时只需要修改对应任务不必重新设计整套运行器。框架本身支持 personality、toolbox、model config 和 taskflow。Personality 定义 Agent 的角色和任务习惯toolbox 决定它能调用哪些工具model config 把具体模型名称与参数从流程里抽离taskflow 决定任务之间怎样串联。这个分层很像传统 CI业务步骤、执行环境和凭据权限不应该混在同一个脚本里。官方仓库还提供离线 lint可以在不发起模型请求的情况下检查任务流引用、模板语法、模型配置和未知字段。对于要长期维护的 Agent 流程这一点并不花哨却非常关键。提示词一旦进入团队生产它就和配置文件、流水线脚本一样需要静态检查否则一个字段拼错就可能让整轮昂贵审计跑到一半才失败。另一个容易忽视的点是 MCP 环境变量隔离。Taskflow Agent 支持通过 TASKFLOW_ENV_DENYLIST 阻止指定环境变量继承给 MCP 子进程。因为安全 Agent 往往需要 GitHub Token、模型凭据、代码仓库访问权如果工具进程默认继承父进程全部环境审计工具本身反而会扩大秘密暴露面。安全工具不能只检查别人也必须约束自己的能力边界。GitHub 官方 README 还明确提醒项目提供的 Docker 镜像只是部署便利不是安全边界。这句话很值得抄进任何 Agent 平台的设计规范。容器能降低环境污染却不自动解决网络出口、宿主挂载、凭据范围、Docker Socket、内核共享和工具权限问题。把 Agent 放进容器只完成了隔离设计的第一层。成本问题不能靠“模型更便宜”解决官方 Android 审计任务需要 GitHub Copilot 许可并会消耗大量 premium model requests配套 taskflows 仓库也提醒大型项目可能运行数小时。换句话说这套方法不是免费魔法。真正的工程优化方向是减少没有安全价值的上下文和重复推理让贵的模型调用只发生在需要语义判断的节点上。例如入口点枚举可以先由确定性工具完成Agent 只负责解释高价值入口Manifest、Gradle 配置、导出组件等结构化信息可以提前抽取数据库里已经判定无风险的组件不必每次重新读完整代码只有当静态条件满足时才启动更昂贵的跨文件追踪。把程序分析和模型推理组合比让模型从仓库根目录自由漫游更省钱也更容易复现。同样结果存储也应该结构化。官方运行结束后会把审计结果放进 SQLite文章建议在 audit_results 表中查看 has_vulnerability 标记。数据库不是为了好看而是为了让后处理脱离聊天记录。团队可以基于相同字段做去重、人工分派、PoC 状态、严重性复核和 CI 阻断不需要再从几十页自然语言里人工复制。下面这个 Python 脚本可以直接用于这类结果库的第一轮收口。它只依赖标准库先检查 audit_results 的真实字段再筛出 has_vulnerability 为真的记录字段不存在时明确失败不会因为数据库结构变化静默给出空结果。它不替代人工复核只负责把需要继续验证的候选从 SQLite 稳定拉出来。import argparse import sqlite3 import sys def main() - int: parser argparse.ArgumentParser() parser.add_argument(db, helpTaskflow 审计结果 SQLite 路径) args parser.parse_args() conn sqlite3.connect(args.db) conn.row_factory sqlite3.Row columns { row[1] for row in conn.execute(PRAGMA table_info(audit_results)) } if has_vulnerability not in columns: print(audit_results 缺少 has_vulnerability 字段, filesys.stderr) return 2 preferred [ id, title, repo, path, severity, has_vulnerability, description ] selected [name for name in preferred if name in columns] sql SELECT , .join(selected) \ FROM audit_results WHERE has_vulnerability 1 rows conn.execute(sql).fetchall() print(f需要复核的候选: {len(rows)}) for row in rows: print(- * 60) for key in selected: print(f{key}: {row[key]}) return 0 if __name__ __main__: raise SystemExit(main())这段代码真正重要的不是 SQL而是“后处理必须有确定性接口”。Agent 可以负责发现和解释流水线负责保存状态脚本负责机械筛选研究员负责最终判断。把职责拆开后任何一层出错都更容易定位否则一次失败只会留下“模型这次没发挥好”这种无法维修的结论。把这套思路落到自己的代码库如果团队要把类似流程接入日常开发第一版不必追求“自动挖零日”。先选一个边界明确的仓库把历史上已经修复的漏洞当回归样本。要求 Taskflow 在不知道答案文件位置的前提下重新找到入口、给出攻击路径并区分真正可利用问题与只有危险代码形态的问题。先测召回和误报再谈扩大覆盖范围。第二步是把入口信息做成长期资产。移动应用每次发布都可以重新提取 exported 组件、Intent Filter、Deep Link、WebView 配置、权限声明和跨进程接口与上一个版本做差异。Agent 不需要每次重新理解整份 Manifest而是优先审计“这次新增了什么外部入口、哪个入口权限变宽、哪条数据流第一次连到敏感能力”。第三步是给高风险发现强制增加运行时验证。涉及文件读写就准备受控测试目录涉及 URI 就构造真实 Intent涉及 WebView 就观察最终加载 origin涉及认证状态就检查 Cookie 或 Token 是否真的跨越了预期边界。没有运行证据的发现可以保留但不应该和已经闭环的漏洞放在同一优先级。第四步才是并行化。只有当单条流程的输入输出稳定后多 Agent 才会带来速度收益。否则并行只会同时制造更多相互矛盾的报告。比较稳妥的拆法是一个 Agent 负责入口和威胁模型一个负责跨文件数据流一个负责漏洞类别检查一个负责挑战前面结论并设计 PoC最终由确定性规则合并重复项。第五步是记录成本。每次审计至少保存仓库提交 SHA、Taskflow 版本、模型配置、工具版本、请求数量、耗时、候选数、最终确认数和人工复核时间。几轮以后就能看出究竟是哪一步最烧钱、哪个提示贡献最低、哪个模型适合做广搜、哪个模型适合做验证。Agent 工程真正能优化的对象是整条任务成本而不是单次回答分数。24 个漏洞之后安全审计的角色正在变化GitHub Security Lab 这次结果最有价值的地方是它没有把研究员从流程里拿掉。官方文章反而反复强调模型会误判严重性会受复杂运行条件影响最终发现仍需要懂移动安全的人复核。AI 把大量阅读、枚举和候选生成自动化之后人的工作更集中到威胁模型、验证设计、影响判断和修复优先级上。这条路线和“让 AI 自动替代安全团队”差别很大。前者承认模型不稳定所以用 Taskflow、结构化数据库、工具权限和运行证据把不稳定性包在工程边界里后者把自然语言输出直接当事实短期看起来更快长期会把误报、漏报和不可复现问题全部留给下游。从这 24 个 Android 漏洞可以看到安全 Agent 真正成熟的标志不是它能写多长的漏洞报告而是它能否持续回答同一组工程问题攻击面有没有漏输入能不能由攻击者控制影响能不能在真实程序里复现证据能不能被另一个人重跑失败能不能定位到明确阶段。做到这些AI 才从“会分析代码的聊天窗口”变成安全流水线里的一个可管理组件。原始资料GitHub Security Lab《How we found 24 Android vulnerabilities using our open source AI security agent》以及 GitHubSecurityLab/seclab-taskflow-agent、GitHubSecurityLab/seclab-taskflows 两个公开仓库。发布时间与代码状态均以 2026 年 9 月 29 日检索结果为准。最小落地时先守住三条边界如果只准备做第一轮试验可以先把范围压到三个边界。第一Agent 只有只读仓库权限生成 PoC 的环境与生产环境隔离第二所有外部网络访问经过单独工具不让模型获得任意网络能力第三任何写文件、启动模拟器、安装测试包或执行验证命令都在日志里留下任务编号和输入来源。这样即使模型判断错误错误也被限制在可观察、可回滚的实验环境里。接下来再把历史漏洞变成固定回归集。每次修改 Taskflow 或更换模型都用同一批已知问题重新跑一遍记录找到多少、漏掉多少、又新增多少误报。只有回归数据稳定才把新的审计结果送进真实漏洞处理流程。安全 Agent 的版本升级不能只看模型榜单它更像规则引擎升级必须证明旧能力没有悄悄退化。最后要保留人工否决权而且否决理由也进入数据。研究员判定某条报告无效时最好记录是入口不可达、权限条件不成立、数据被后续覆盖还是影响描述被模型夸大。积累一段时间后这些否决标签可以反过来改进 Taskflow让下一轮模型先检查最常见的失败条件。真正会成长的不是单个 Agent而是这套不断吸收验证结果的审计系统。