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 SDK，Pydantic 负责语法校验，Jinja2 负责模板渲染。它的价值不是提供一个“最聪明的安全模型”，而是把研究人员已经验证有效的提示、工具和步骤固化下来，让审计经验从一次性对话变成可以版本化的资产。
在 Android 场景里，这种固化尤其重要。移动应用的高风险问题经常不是某一行代码出现危险函数，而是多个组件的权限、Intent、Deep Link、WebView、存储和身份状态拼在一起才形成攻击链。模型如果只盯某个函数，很容易看见局部异常却理解不了攻击者从哪里进入、数据如何跨组件流动、最终影响落在哪里。
第一步不是找漏洞，而是先画出攻击入口
GitHub 的移动审计流程新增了一个名为gather_mobile_entry_point_info的任务。它先识别代码里的入口点，再区分移动入口和非移动入口。这个动作看上去普通，实际决定了后面的搜索空间。对于 Android，Activity、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", help="Taskflow 审计结果 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 字段", file=sys.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，而是这套不断吸收验证结果的审计系统。
