security-research

安全研究——团队模式漏洞审计

使用此技能运行并行安全审计，区分真实可利用性与泛泛的担忧。团队由 3 名漏洞猎手和 2 名 PoC 工程师组成。

严格前提条件

开始前，请确认：

1. team_* 工具可用。如果不可用，请停止并告知用户： security-research requires team-mode. Set team_mode.enabled: true in your oh-my-openagent config, restart opencode, then retry.
2. 你处于主会话中，而不是后台子 Agent。
3. 你有明确的目标：仓库、差异范围、PR、候选发行版、路径列表或威胁面。

如果用户未提供目标，请审计当前仓库，以及当前分支相对于其上游分支或合并基准的差异。如果没有差异，则审计工作树中与安全相关的攻击面。

严重性标准

使用以下参考资料作为评分依据：

• CWE，用于对根因弱点进行分类：https://cwe.mitre.org/
• OWASP WSTG，用于测试方法：https://devguide.owasp.org/en/06-verification/01-guides/01-wstg/
• OWASP ASVS，用于控制项验证：https://owasp.org/www-project-application-security-verification-standard/
• CVSS v4.0，用于可利用性和影响评分：https://www.first.org/cvss/v4.0/specification-document

规则：

• 没有攻击路径，就不评定严重性。
• 没有具体的利用前提条件和影响，就不报告严重或高危问题。
• 将 CWE 类别与严重性分开。
• 优先提供简短、可复现的 PoC，而不是理论性描述。
• 切勿针对真实服务或第三方系统运行破坏性攻击。
• 如果实际执行不安全，请使用本地测试夹具、玩具载荷、试运行或静态证明。

团队成员

创建一次包含以下 5 名成员的 Team Mode 运行：

成员	类型	类别	职责
surface-hunter	类别	deep-low	绘制入口点、信任边界和可触达的攻击面。
auth-data-hunter	类别	ultrabrain	排查身份验证、授权、数据隔离、注入和密钥处理方面的缺陷。
runtime-supply-hunter	类别	unspecified-high	排查文件系统、子进程、归档、依赖项、钩子、MCP 和配置方面的风险。
poc-engineer-a	类别	unspecified-high	为最有力的候选发现构建最小 PoC。
poc-engineer-b	类别	deep-high	独立复现、证伪或下调候选发现的评级。

使用内联规范调用 team_create：

team_create({
  inline_spec: {
    name: "security-research",
    description: "Parallel exploitability-driven security research team.",
    members: [
      {
        name: "surface-hunter",
        kind: "category",
        category: "deep-low",
        prompt: "You map attack surface. Enumerate entry points, trust boundaries, attacker-controlled inputs, data sinks, privilege transitions, and sensitive assets. Return evidence with file paths and exact functions. Do not assign severity unless you can name an attack path."
      },
      {
        name: "auth-data-hunter",
        kind: "category",
        category: "ultrabrain",
        prompt: "You hunt auth, authorization, tenant/data isolation, injection, SSRF, credential exposure, and confused-deputy flaws. Reason from attacker capability to impact. Return only findings with concrete exploit preconditions, CWE candidates, and verification steps."
      },
      {
        name: "runtime-supply-hunter",
        kind: "category",
        category: "unspecified-high",
        prompt: "You hunt filesystem, subprocess, archive extraction, dependency, hook execution, MCP, config, and environment-variable risks. Check path traversal, command injection, unsafe downloads, permission boundaries, and supply-chain assumptions. Cite file paths and commands used."
      },
      {
        name: "poc-engineer-a",
        kind: "category",
        category: "unspecified-high",
        prompt: "You build minimal safe PoCs for candidate findings. Use toy inputs and local-only execution. Your job is to prove or disprove exploitability, not to broaden scope. Report exact reproduction steps and expected output."
      },
      {
        name: "poc-engineer-b",
        kind: "category",
        category: "deep-high",
        prompt: "You independently reproduce candidate findings and try to falsify them. Downgrade anything without a working path. If a PoC is unsafe to run, design a safe static or dry-run proof and explain the limit."
      }
    ]
  }
})

如果某个类别不可用，请仅将该类别替换为 unspecified-high，然后重试一次。团队人数不得少于 5 人。

工作流程

阶段 0：范围与基线

收集：

• 审计目标范围及原因。
• 如果是变更审查，收集分支、基准引用、差异和已更改文件。
• 如果是全仓库审计，收集与安全相关的目录和文件。
• 用于检查相关攻击面的现有测试和命令。
• 用户说明的任何限制，例如禁止网络调用或破坏性测试。

分配任务前，使用 rg、git diff、git log、LSP 和现有测试。

阶段 1：猎手独立审查

向 3 名猎手发送一条提示词：

Audit target:
{target summary}

Context:
{diff, file list, security-sensitive paths, known constraints}

Task:
Find candidate vulnerabilities in your assigned role. For each candidate include:
- title
- affected file/function
- attacker capability
- attack path
- impact
- CWE candidate
- exact evidence
- safe verification idea

Reject generic hardening advice. Return only candidates with a plausible path.

等待所有猎手完成。

阶段 2：PoC 验证

对猎手提出的候选发现去重。将最有力的候选发现发送给两名 PoC 工程师。

每名 PoC 工程师必须返回：

• 已复现、已证伪或运行不安全。
• 精确命令、测试夹具或静态证明。
• 观察到的输出，或失败原因。
• 基于可利用性和影响的严重性建议。
• 对未复现问题的下调评级理由。

阶段 3：交叉核查

将 PoC 结果发送给全部 5 名成员。

询问每名成员：

• 哪些发现依然成立？
• 哪些发现应下调评级或移除？
• 最小且具体的修复方案是什么？
• 哪项回归测试可以防止问题再次出现？

阶段 4：最终报告

生成以下报告：

## Security Research Result

### Verdict
PASS | PASS WITH FINDINGS | BLOCK

### Scope
- Target:
- Base/diff:
- Commands run:

### Findings
| Severity | Title | CWE | Exploitability | Impact | PoC | Fix |
|----------|-------|-----|----------------|--------|-----|-----|

### Finding Details
For each finding:
- Evidence:
- Attack path:
- PoC:
- Severity rationale:
- Minimal fix:
- Regression check:

### Downgraded or Rejected Candidates
| Candidate | Reason |
|-----------|--------|

### Residual Risk
- What was not tested and why.

输出规则

• 开头先给出结论。
• 不要把阻断性问题藏在后面。
• 不要将推测性发现报告为漏洞。
• 除非确实评估了各项指标，否则不要声称 CVSS 评分精确。
• 对于每项经核实的问题，都要注明准确的文件路径和命令。
• 如果没有任何问题通过 PoC 验证，请明确说明，并列出残余风险。