| name | security-investigate-issue |
| description | Triages an internally reported security concern for Open Collective codebases (engineering, ops, or security team) - validates reproducibility and impact, asserts the finding with a clear confidence level, and proposes a fix plan when applicable. Writes artifacts under `/workspace/priv/security-issues/<unique-folder>/` including `issue.md` (assertion and verdict), optional `plan.md` when there is a fix to plan, plus a minimal runnable PoC for full confirmation. Offers optional production impact analysis (`impact.md`) at the end when queryable traces may exist. Updates `security/memory.md` after full triage. No external researcher reply or bounty policy. Use when the user describes an internal finding, asks to validate a suspected vulnerability from the team, or wants an engineering handoff without security@ or bounty workflow. |
Security issue investigation - internal (Open Collective)
Triages findings raised inside the org (engineering, ops, security): assertion, evidence, optional fix plan. No external reply or bounty workflow.
Shared triage steps: Read ../security-investigate/_shared.md for issue folder rules, known issue check (local priv/security-issues archive + GitHub MCP search of opencollective-security), core workflow (parse → PoC → classify → severity → fix), security/memory.md update, and plan.md / impact.md structure.
Workflow
Prerequisite: Run _shared.md Known issue check first (local archive, then GitHub). On match: issue.md only (verdict Duplicate, link to prior triage folder and/or existing GitHub issue). On no match: create issue folder, then _shared.md steps 1–6, then update security/memory.md per _shared.md (skip on duplicate).
Internal reference ID (optional)
If the user provides an internal ticket ID (Linear, Jira, incident number, etc.), capture at start and repeat in issue.md (Reference: line). Do not invent an ID.
Output files
All under /workspace/priv/security-issues/<unique-folder>/. PoC in poc/ or poc.*; required for fully confirmed.
| File | When | Contents |
|---|
issue.md | Always | Assertion: reference ID (if any), title suggestion, claim summary, verdict (Confirmed / Provisional / Invalid / Duplicate / Intentional / Unclear) with reasoning, impact, components, code refs, PoC path/run (or why not), severity, next steps. One canonical internal write-up. |
plan.md | Fix to plan | Per _shared.md. |
impact.md | User accepts impact offer | Per _shared.md. Do not create during default triage. |
Production impact analysis (optional)
After the in-chat summary, offer production impact analysis when abuse may leave queryable traces (DB rows, audit logs, etc.). Do not write impact.md unless the user accepts.
- Offer when: Fully or provisionally confirmed findings where forensic checks could clarify whether exploitation occurred in production.
- On accept: Write
impact.md per _shared.md and note the new file in chat.
In-chat summary
Duplicate path: (1) Verdict Duplicate + prior triage folder and/or existing GitHub issue link (2) Search summary (local + GitHub) (3) Folder path + issue.md.
Full triage path:
- Known issue check - Searched
priv/security-issues and GitHub; no confident match (or weak hits ruled out)
- Verdict + reason
- Evidence (+ PoC path/outcome if confirmed)
- Impact (theoretical; in
issue.md — not production forensic queries)
- Suggested severity
- Fix plan pointer (
plan.md when created)
- Memory -
security/memory.md row added or bounty updated (Internal section unless named contact supplied)
- Paths - folder; which of
issue.md / plan.md; PoC location
- Offer production impact analysis (
impact.md) when queryable traces may exist — only write after user accepts
