oh-my-openagent 安全研究技能（Security Research）实战指南：基于 Team Mode 的并行漏洞可利用性审计

oh-my-openagent 安全研究技能（Security Research）实战指南：基于 Team Mode 的并行漏洞可利用性审计

【免费下载链接】oh-my-openagentOmO: Just type "mass ulw" keyword with your prompt. Now you are the master of graph engineering.项目地址: https://gitcode.com/gh_mirrors/oh/oh-my-openagent

导读

本文详解 oh-my-openagent 内置的security-research技能（SKILL.md），它是一套以"团队模式（Team Mode）"驱动的并行安全审计流程：由 3 名漏洞猎手（vulnerability hunters）与 2 名 PoC 工程师组成临时审计团队，把"泛泛的安全担忧"与"真实可利用的漏洞"区分开，最终输出带攻击路径、CWE 分类、可利用性与影响评分的审计报告。读完本文，你将掌握该技能的硬性前置条件、五成员团队的搭建方式、四阶段并行审计工作流，以及如何在当前仓库中定位它的注册代码与测试验证，从而在你的代码审查、发布前安全检查和威胁建模中直接复用它。

技能定位：它解决什么问题

security-research是 oh-my-openagent 在skills-loader-core包中内置的 Team Mode 技能之一。从其注册源码（security-research.ts）可以看到，它的触发词覆盖英文与韩文："security-research"、"security research"、"security review"、"vulnerability audit"、"exploitability audit"、"보안 리뷰"、"취약점 감사"，并可通过/security-research斜杠命令调用。

它的核心主张是用可利用性（exploitability）校准严重性（severity），而不是靠直觉或模式匹配给漏洞打标签。技能文档开篇即点明目标：运行一次并行安全审计，把"真实可利用的问题"与"泛泛的担忧"分离。这也正是它与普通的security-review类技能的关键差异——后者在仓库中被实现为前者的运行时别名（见 security-review.ts：securityReviewSkill.template直接复用securityResearchSkill.template，描述前缀为Alias for security-research and /security-review）。

硬性前置条件（Hard Preconditions）

技能开始前必须先验证三件事，缺一不可：

1. team_*工具必须可用。这些工具由 Team Mode 注册，而 Team Mode 默认关闭。如果工具不可用，技能会直接停下来并提示用户：

   security-research requires team-mode. Set team_mode.enabled: true in your .omo/omo.jsonc config, restart opencode, then retry.

   这一约束与 Team Mode 的实现一致：Team Mode 技能的模板说明（team-mode.ts）明确指出team_*工具仅在team_mode.enabled=true时全局注册，并按团队角色做访问门控（access-gated）；在技能装配层（skills.ts）中，teamModeSkill也仅在teamModeEnabled为真且未被禁用时才被加入内置技能列表。

2. 必须处于主会话（main session），而不是后台子代理（background subagent）中运行。

3. 必须有具体目标：仓库、diff 范围、PR、发布候选版本（release candidate）、路径清单或威胁面（threat surface）。

如果用户没有给出目标，技能会退化为对"当前仓库 + 当前分支相对上游/合并基（merge base）的 diff"进行审计；若连 diff 都不存在，则审计工作区（working tree）中安全敏感的表面。

严重性判定标准（Severity Standard）

技能把评分框架外部锚定到四套业界标准：

• CWE（cwe.mitre.org）：用于根因弱点（root-cause weakness）分类，CWE 分类与严重性评分必须分开看待；
• OWASP WSTG（OWASP Web Security Testing Guide）：测试方法论的参照；
• OWASP ASVS（Application Security Verification Standard）：控制项验证的参照；
• CVSS v4.0（FIRST CVSS v4.0 规范文档）：可利用性与影响评分的参照。

评分规则非常强硬：

• 没有攻击路径（attack path）就没有严重性（No severity without an attack path）；
• 没有具体利用前置条件（exploit preconditions）和影响（impact）就没有 critical/high 结论；
• CWE 类别与严重性等级分离——先分类、再定级；
• 优先给出小体积、可复现的 PoC，而不是理论化描述；
• 严禁对真实服务或第三方系统执行破坏性利用；当真实执行不安全时，改用本地 fixtures、玩具 payload、dry run 或静态证明。

团队名册与 team_create 调用

技能要求创建一次 Team Mode 运行，包含 5 名成员：

调用方式为team_create+ 内联规格（inline_spec），每个成员通过kind: "category"声明，并携带职责导向的prompt。完整调用示例见 SKILL.md，其结构与 Team Mode 技能模板中team_create({ inline_spec: ... })的用法一致（team-mode.ts 中说明：内联规格可直接传给team_create，省略kind时category隐含kind: "category"）。

角色分工要点：

• surface-hunter只测绘攻击面（入口点、信任边界、攻击者可控输入、数据汇点、权限跃迁、敏感资产），返回证据时必须带文件路径和确切函数；除非能点名攻击路径，否则不分配严重性；
• auth-data-hunter从"攻击者能力 → 影响"推理，只返回具备具体利用前置条件、CWE 候选与验证步骤的发现；
• runtime-supply-hunter聚焦供应链与运行时风险（路径穿越、命令注入、不安全下载、权限边界、依赖/钩子/MCP 假设），必须引用用到的文件路径与命令；
• poc-engineer-a只做"最小安全 PoC"，用玩具输入与本地执行证明或否定可利用性，不扩展范围，报告精确的复现步骤与预期输出；
• poc-engineer-b独立复现并尝试证伪，凡是无法给出可用路径的一律降级；若 PoC 不安全，设计安全的静态/干跑证明并说明限制。

如果某个 category 不可用，只允许一次降级重试——将该 category 替换为unspecified-high，且团队人数不得低于 5 人。

四阶段审计工作流

Phase 0：范围与基线（Scope and Baseline）

收集以下信息作为后续所有工作的基线：

• 目标范围与审计原因；
• 变更评审场景下的分支、base ref、diff 与变更文件列表；
• 全仓库审计场景下的安全敏感目录与文件；
• 已存在的、可覆盖相关表面的测试与命令；
• 用户声明的约束（例如禁止网络调用、禁止破坏性测试）。

在分配任务前，优先使用rg、git diff、git log、LSP 与既有测试来建立认知。

Phase 1：独立猎手通道（Independent Hunter Pass）

向 3 名猎手各发一份统一 prompt，包含目标摘要、上下文（diff、文件清单、安全敏感路径、已知约束）与任务要求。每个候选发现必须包含：标题、受影响文件/函数、攻击者能力、攻击路径、影响、CWE 候选、确切证据、安全验证思路。同时明确要求：拒绝泛泛的加固建议（generic hardening advice），只返回有合理路径的候选，然后等待全部猎手返回。

Phase 2：PoC 通道（PoC Pass）

去重猎手候选后，把最强的候选同时交给两名 PoC 工程师。每人必须返回四件事：

• 结论：Reproduced / Falsified / Unsafe-to-run三选一；
• 确切的命令、fixtures 或静态证明；
• 观察到的输出或失败原因；
• 基于可利用性与影响的严重性建议，以及未复现时的降级理由。

Phase 3：交叉复核（Cross-Check）

把 PoC 结果发回全部 5 名成员，让每个人都回答四个问题：

• 哪些发现能存活？
• 哪些应该降级或移除？
• 最小且具体的修复是什么？
• 什么样的回归测试能防止复发？

Phase 4：最终报告（Final Report）

按技能文档给出的固定模板输出 Markdown 报告（SKILL.md），包含：Verdict（PASS / PASS WITH FINDINGS / BLOCK）、Scope、Findings 表格（Severity / Title / CWE / Exploitability / Impact / PoC / Fix）、每个发现的详情（证据、攻击路径、PoC、严重性依据、最小修复、回归检查）、被降级或拒绝的候选清单、以及残余风险（未测试什么、为什么）。

输出规则（Output Rules）

• 以结论（verdict）开头，不把阻塞性问题埋在深处；
• 不把推测性发现当作漏洞上报；
• 除非实际计算了指标，否则不得声称 CVSS 精度；
• 每个存活发现必须带确切文件路径与命令；
• 若 PoC 后无任何发现存活，就直说，并列出残余风险。

仓库内的源码佐证与验证

security-research在仓库中的实现链条清晰可循：

1. 技能定义：security-research.ts 以import ... with { type: "text" }的方式把 SKILL.md 作为模板直接内联进BuiltinSkill，description同时充当触发词清单；
2. 装配入口：skills.ts 将securityResearchSkill与frontendSkill、gitMasterSkill、securityReviewSkill、visualQaSkill等并列加入默认内置技能列表，默认即启用，且不受teamModeEnabled开关影响（它依赖的是运行时team_*工具，而非团队技能本身）；
3. 运行时别名：security-review.ts 表明/security-review只是/security-research的别名，模板完全一致；
4. 测试验证：skills.test.ts 中的两个用例分别断言security-research技能结构正确（description 含 "security research"）、security-review是它的运行时别名（description 含 "Alias for security-research" 且两者 template 相同）；
5. 配置与禁用：runtime-skill-config.ts（runtime-skill-config.ts）中includeResearch = !disabledSkills.has("security-research")表明可通过禁用集关闭该技能；在 omo-opencode 的 agent 名称 schema（agent-names.ts）中也注册了security-research名称。

由此可以推断，该技能与team-mode、git-master、dev-browser等同属"文档型内置技能"体系：SKILL.md 既是给模型的行为说明书，也是技能注册时直接内联的模板内容，测试则保证注册结构与别名关系不漂移。

适用前提与限制

• 该技能强依赖 Team Mode 运行时：必须先在.omo/omo.jsonc中设置team_mode.enabled: true并重启 opencode，team_create/team_send_message/team_task_*/team_status等工具才会注册（团队工具清单与生命周期、关闭契约详见 team-mode.ts）；
• 团队上限为 8 名成员、4 个并行 worker，单条消息 32KB，未读信箱 256KB；团队是**临时（ephemeral）**的，任务全部到达终态（completed/failed）后应由 lead 在同一轮执行关闭序列（team_shutdown_request→team_approve_shutdown→team_delete）；
• 该技能适用于本地代码审计场景，不适用于对线上系统做真实渗透测试——所有 PoC 必须落在本地 fixtures、玩具输入或静态/干跑证明的边界内。

掌握这套流程后，你可以在发布前安全检查、PR 评审、威胁模型验证等场景中，用 5 个并行角色的分工把"看起来可疑"收敛为"可复现、可修复、有攻击路径"的高置信度结论，并输出一份结构统一、可直接进入工单系统的审计报告。

【免费下载链接】oh-my-openagentOmO: Just type "mass ulw" keyword with your prompt. Now you are the master of graph engineering.项目地址: https://gitcode.com/gh_mirrors/oh/oh-my-openagent