feat(skills): add security-research orchestration
Ship the documented Team Mode security-research capability as an .agents skill and expose /security-research through transition command wrappers. The exact security-review slug has no reachable history hits; security-research is the documented missing artifact from README and issue #3887. Refs #3887 Plan: plans/security-research-restore.md
This commit is contained in:
YeonGyu-Kim
+6
-4
@@ -4,11 +4,11 @@
|
||||
|
||||
## OVERVIEW
|
||||
|
||||
Project-scope skills + slash commands under the new `.agents/` directory name. During the `oh-my-opencode` → `oh-my-openagent` rename transition, this directory is the **target** of the migration from `.opencode/`. It is a strict SUPERSET of `.opencode/` (5 → 9 skills; same 4 commands).
|
||||
Project-scope skills + slash commands under the new `.agents/` directory name. During the `oh-my-opencode` → `oh-my-openagent` rename transition, this directory is the **target** of the migration from `.opencode/`. It is a strict SUPERSET of `.opencode/` (5 -> 10 skills; 5 commands).
|
||||
|
||||
Loaded alongside `.opencode/` by [`src/features/opencode-skill-loader/`](file:///Users/yeongyu/local-workspaces/omo/src/features/opencode-skill-loader/). When both directories declare the same skill or command name, the higher-priority scope wins per the loader's deduplication rules.
|
||||
|
||||
## SKILLS (9, superset of `.opencode/`)
|
||||
## SKILLS (10, superset of `.opencode/`)
|
||||
|
||||
| Skill | Also in `.opencode/`? | Purpose |
|
||||
|-------|------------------------|---------|
|
||||
@@ -21,16 +21,18 @@ Loaded alongside `.opencode/` by [`src/features/opencode-skill-loader/`](file://
|
||||
| `omomomo/` | NEW | Skill form of the `/omomomo` easter egg |
|
||||
| `publish/` | NEW | Skill form of the `/publish` command |
|
||||
| `remove-deadcode/` | NEW | Skill form of the `/remove-deadcode` command |
|
||||
| `security-research/` | NEW | Team Mode security research audit: 3 vulnerability hunters + 2 PoC engineers |
|
||||
|
||||
The 4 "NEW" skills here are skill-format equivalents of the 4 slash commands that exist in BOTH `.opencode/command/` and `.agents/command/`. They allow the same instructions to be triggered either by an explicit `/command` invocation OR by skill auto-loading on matching prompts.
|
||||
The 5 "NEW" skills here are skill-format equivalents of slash commands that exist in BOTH `.opencode/command/` and `.agents/command/`. They allow the same instructions to be triggered either by an explicit `/command` invocation OR by skill auto-loading on matching prompts.
|
||||
|
||||
## COMMANDS (4 slash commands)
|
||||
## COMMANDS (5 slash commands)
|
||||
|
||||
Identical set to `.opencode/command/`:
|
||||
- `/get-unpublished-changes`
|
||||
- `/omomomo`
|
||||
- `/publish`
|
||||
- `/remove-deadcode`
|
||||
- `/security-research`
|
||||
|
||||
## OTHER CONTENTS
|
||||
|
||||
|
||||
@@ -0,0 +1,16 @@
|
||||
---
|
||||
description: Run the Team Mode security-research audit with 3 vulnerability hunters and 2 PoC engineers
|
||||
---
|
||||
|
||||
<command-instruction>
|
||||
Load and follow the `security-research` skill exactly.
|
||||
|
||||
```text
|
||||
skill(name="security-research")
|
||||
```
|
||||
</command-instruction>
|
||||
|
||||
<user-request>
|
||||
$ARGUMENTS
|
||||
</user-request>
|
||||
|
||||
@@ -0,0 +1,204 @@
|
||||
---
|
||||
name: security-research
|
||||
description: "Team Mode security research skill. Orchestrates 3 vulnerability hunters and 2 PoC engineers to audit a codebase in parallel, prove exploitability, classify root causes, and calibrate severity by actual exploitability. Use for security review, vulnerability research, exploitability audit, pre-release security check, threat model validation, and `/security-research`. Triggers: 'security-research', 'security research', 'security review', 'vulnerability audit', 'exploitability audit', '보안 리뷰', '취약점 감사'."
|
||||
---
|
||||
|
||||
# Security Research - Team Mode Vulnerability Audit
|
||||
|
||||
Use this skill to run a parallel security audit that separates real exploitability from generic concern. The team has 3 vulnerability hunters and 2 PoC engineers.
|
||||
|
||||
## Hard Preconditions
|
||||
|
||||
Before starting, verify:
|
||||
|
||||
1. `team_*` tools are available. If not, stop and tell the user:
|
||||
`security-research requires team-mode. Set team_mode.enabled: true in your oh-my-openagent config, restart opencode, then retry.`
|
||||
2. You are in the main session, not a background subagent.
|
||||
3. You have a concrete target: repository, diff range, PR, release candidate, path list, or threat surface.
|
||||
|
||||
If the user provided no target, audit the current repository and current branch diff against its upstream or merge base. If there is no diff, audit the security-sensitive surfaces in the working tree.
|
||||
|
||||
## Severity Standard
|
||||
|
||||
Use these references as the scoring frame:
|
||||
|
||||
- CWE for root-cause weakness classification: https://cwe.mitre.org/
|
||||
- OWASP WSTG for test methodology: https://devguide.owasp.org/en/06-verification/01-guides/01-wstg/
|
||||
- OWASP ASVS for control verification: https://owasp.org/www-project-application-security-verification-standard/
|
||||
- CVSS v4.0 for exploitability and impact scoring: https://www.first.org/cvss/v4.0/specification-document
|
||||
|
||||
Rules:
|
||||
|
||||
- No severity without an attack path.
|
||||
- No critical or high finding without concrete exploit preconditions and impact.
|
||||
- Keep CWE category separate from severity.
|
||||
- Prefer a small, reproducible PoC over theoretical language.
|
||||
- Never run destructive exploits against real services or third-party systems.
|
||||
- Use local fixtures, toy payloads, dry runs, or static proof when real execution would be unsafe.
|
||||
|
||||
## Team Roster
|
||||
|
||||
Create one Team Mode run with these 5 members:
|
||||
|
||||
| Member | Kind | Category | Role |
|
||||
|--------|------|----------|------|
|
||||
| `surface-hunter` | category | `deep` | Map entry points, trust boundaries, and reachable attack surfaces. |
|
||||
| `auth-data-hunter` | category | `ultrabrain` | Hunt auth, authorization, data isolation, injection, and secret handling flaws. |
|
||||
| `runtime-supply-hunter` | category | `unspecified-high` | Hunt filesystem, subprocess, archive, dependency, hook, MCP, and config risks. |
|
||||
| `poc-engineer-a` | category | `unspecified-high` | Build minimal PoCs for the strongest candidate findings. |
|
||||
| `poc-engineer-b` | category | `deep` | Independently reproduce, falsify, or downgrade candidate findings. |
|
||||
|
||||
Call `team_create` with an inline spec:
|
||||
|
||||
```typescript
|
||||
team_create({
|
||||
inline_spec: {
|
||||
name: "security-research",
|
||||
description: "Parallel exploitability-driven security research team.",
|
||||
members: [
|
||||
{
|
||||
name: "surface-hunter",
|
||||
kind: "category",
|
||||
category: "deep",
|
||||
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",
|
||||
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."
|
||||
}
|
||||
]
|
||||
}
|
||||
})
|
||||
```
|
||||
|
||||
If a category is unavailable, retry once by replacing only that category with `unspecified-high`. Do not reduce the team below 5 members.
|
||||
|
||||
## Workflow
|
||||
|
||||
### Phase 0: Scope and Baseline
|
||||
|
||||
Collect:
|
||||
|
||||
- Target scope and reason for audit.
|
||||
- Branch, base ref, diff, and changed files if this is a change review.
|
||||
- Security-sensitive directories and files if this is a full-repo audit.
|
||||
- Existing tests and commands that exercise relevant surfaces.
|
||||
- Any user-stated constraints, such as no network calls or no destructive tests.
|
||||
|
||||
Use `rg`, `git diff`, `git log`, LSP, and existing tests before assigning work.
|
||||
|
||||
### Phase 1: Independent Hunter Pass
|
||||
|
||||
Send one prompt to the 3 hunters:
|
||||
|
||||
```text
|
||||
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.
|
||||
```
|
||||
|
||||
Wait for all hunters.
|
||||
|
||||
### Phase 2: PoC Pass
|
||||
|
||||
Deduplicate hunter candidates. Send the strongest candidates to both PoC engineers.
|
||||
|
||||
Each PoC engineer must return:
|
||||
|
||||
- Reproduced, falsified, or unsafe-to-run.
|
||||
- Exact commands, fixtures, or static proof.
|
||||
- Observed output or reason it fails.
|
||||
- Severity recommendation using exploitability and impact.
|
||||
- Downgrade rationale for anything not reproduced.
|
||||
|
||||
### Phase 3: Cross-Check
|
||||
|
||||
Send the PoC results back to all 5 members.
|
||||
|
||||
Ask every member:
|
||||
|
||||
- Which findings survive?
|
||||
- Which findings should be downgraded or removed?
|
||||
- What remediation is smallest and specific?
|
||||
- What regression test would prevent recurrence?
|
||||
|
||||
### Phase 4: Final Report
|
||||
|
||||
Produce this report:
|
||||
|
||||
```markdown
|
||||
## 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.
|
||||
```
|
||||
|
||||
## Output Rules
|
||||
|
||||
- Lead with the verdict.
|
||||
- Do not bury blocking issues.
|
||||
- Do not report speculative findings as vulnerabilities.
|
||||
- Do not claim CVSS precision unless you actually scored the metrics.
|
||||
- Include exact file paths and commands for every surviving finding.
|
||||
- If no findings survive PoC, say that plainly and list residual risk.
|
||||
|
||||
+4
-3
@@ -4,9 +4,9 @@
|
||||
|
||||
## OVERVIEW
|
||||
|
||||
Project-scope OpenCode configuration: 5 skills and 4 slash commands committed alongside the source. Picked up by [`src/features/opencode-skill-loader/`](file:///Users/yeongyu/local-workspaces/omo/src/features/opencode-skill-loader/) and the slash-command discovery pipeline.
|
||||
Project-scope OpenCode configuration: 5 skills and 5 slash commands committed alongside the source. Picked up by [`src/features/opencode-skill-loader/`](file:///Users/yeongyu/local-workspaces/omo/src/features/opencode-skill-loader/) and the slash-command discovery pipeline.
|
||||
|
||||
**Relationship to `.agents/`:** `.agents/` is the migration target during the `oh-my-opencode` → `oh-my-openagent` rename. It is a SUPERSET of `.opencode/` (mirrors all 5 skills + adds 4 more, mirrors the 4 commands). Both directories load during the transition; consumers should prefer `.agents/`.
|
||||
**Relationship to `.agents/`:** `.agents/` is the migration target during the `oh-my-opencode` → `oh-my-openagent` rename. It is a SUPERSET of `.opencode/` (mirrors all 5 skills + adds 5 more, mirrors the 5 commands). Both directories load during the transition; consumers should prefer `.agents/`.
|
||||
|
||||
## SKILLS (5)
|
||||
|
||||
@@ -20,7 +20,7 @@ Project-scope OpenCode configuration: 5 skills and 4 slash commands committed al
|
||||
|
||||
Each skill follows the standard layout (`SKILL.md` + optional `scripts/`, `references/`, `assets/`).
|
||||
|
||||
## COMMANDS (4 slash commands)
|
||||
## COMMANDS (5 slash commands)
|
||||
|
||||
| Command | Purpose |
|
||||
|---------|---------|
|
||||
@@ -28,6 +28,7 @@ Each skill follows the standard layout (`SKILL.md` + optional `scripts/`, `refer
|
||||
| `/omomomo` | Easter-egg command — about oh-my-opencode. |
|
||||
| `/publish` | Publish via GitHub Actions workflow. Argument: `<patch|minor|major>`. |
|
||||
| `/remove-deadcode` | Remove unused code with LSP-verified safety + atomic commits. |
|
||||
| `/security-research` | Run the Team Mode security-research audit with 3 vulnerability hunters and 2 PoC engineers. |
|
||||
|
||||
## OTHER CONTENTS
|
||||
|
||||
|
||||
@@ -0,0 +1,16 @@
|
||||
---
|
||||
description: Run the Team Mode security-research audit with 3 vulnerability hunters and 2 PoC engineers
|
||||
---
|
||||
|
||||
<command-instruction>
|
||||
Load and follow the `security-research` skill exactly.
|
||||
|
||||
```text
|
||||
skill(name="security-research")
|
||||
```
|
||||
</command-instruction>
|
||||
|
||||
<user-request>
|
||||
$ARGUMENTS
|
||||
</user-request>
|
||||
|
||||
Reference in New Issue
Block a user