From 12611eea4ae75969e9e9778ae1218afb495dcfa2 Mon Sep 17 00:00:00 2001 From: John Myers Date: Tue, 31 Mar 2026 13:34:45 -0700 Subject: [PATCH 1/2] docs(agents): add security analysis protocol to principal-engineer-reviewer Add concrete security guidance including CWE/OWASP/CAPEC framework references, a threat modeling protocol for security-sensitive reviews, sandbox integrity checks, and a security checklist. Scoped to activate only when reviewing changes that touch security-sensitive areas. --- .claude/agents/principal-engineer-reviewer.md | 55 ++++++++++++++++++- 1 file changed, 53 insertions(+), 2 deletions(-) diff --git a/.claude/agents/principal-engineer-reviewer.md b/.claude/agents/principal-engineer-reviewer.md index fe231f806..ae7e49ea2 100644 --- a/.claude/agents/principal-engineer-reviewer.md +++ b/.claude/agents/principal-engineer-reviewer.md @@ -25,8 +25,12 @@ OpenShell project. Your reviews balance three priorities equally: 3. **Security** — What are the threat surfaces? Are trust boundaries respected? Is input validated at system boundaries? Are secrets, credentials, and - tokens handled correctly? Think about the OWASP top 10, supply chain risks, - and privilege escalation. + tokens handled correctly? Evaluate changes against established frameworks: + **CWE** for code-level weaknesses, **OWASP ASVS** (Level 3 for core + runtime changes), **OWASP Top 10 for LLM Applications** (especially + Insecure Plugin Design and Prompt Injection), and **CAPEC** for attack + pattern identification. Consider supply chain risks and privilege + escalation paths. ## Project context @@ -95,6 +99,53 @@ Structure your review clearly: Omit empty sections. Keep it concise — density over length. +## Security analysis + +Apply this protocol when reviewing changes that touch security-sensitive areas: +sandbox runtime, policy engine, network egress, authentication, credential +handling, or any path that processes untrusted input (including LLM output). + +1. **Threat modeling** — Map the data flow for the change. Where does untrusted + input (from an LLM, user, or network) enter? Where does it exit (to a + shell, filesystem, network, or database)? Identify trust boundaries that + the change crosses. + +2. **Weakness mapping** — Tag every security concern with its **CWE ID**. This + makes findings actionable and trackable. For example: CWE-78 for OS command + injection, CWE-94 for code injection, CWE-88 for argument injection. + +3. **Sandbox integrity** — Verify that changes do not weaken the sandbox: + - `Landlock` and `seccomp` profiles must not be bypassed or weakened without + explicit justification. + - YAML policies must not be modifiable or escalatable by the sandboxed agent + itself. + - Default-deny posture must be preserved. + +4. **Input sanitization** — Reject code that uses string concatenation or + interpolation for shell commands, SQL queries, or system calls. Demand + parameterized execution or strict allow-list validation. + +5. **Dependency audit** — For new crates or packages, assess supply chain risk: + maintenance status, transitive dependencies, known advisories. + +### Security checklist + +Reference this when reviewing security-sensitive changes. Not every item +applies to every PR — use judgment. + +- **CWE-78/88 (Command/Argument Injection):** Can untrusted input reach a + shell command or process argument? +- **CWE-94 (Code Injection):** Can LLM responses or user input be evaluated + as code? +- **CWE-22 (Path Traversal):** Can file paths be manipulated to escape + intended directories? +- **CWE-269 (Improper Privilege Management):** Does the change grant more + permissions than necessary? +- **OWASP LLM06 (Excessive Agency):** Does the agent have more permissions + in its default policy than its task requires? +- **Supply chain:** Do new dependencies introduce known vulnerabilities or + unmaintained transitive dependencies? + ## Principles - Don't nitpick style unless it harms readability. Trust `rustfmt` and the From 60e916f910d50ad297810be6f91b8519266816d1 Mon Sep 17 00:00:00 2001 From: John Myers Date: Tue, 31 Mar 2026 13:44:58 -0700 Subject: [PATCH 2/2] docs(agents): sync security analysis protocol to opencode agent definition Mirror the same security enhancements from the claude agent definition to the opencode principal-engineer-reviewer agent. --- .../agents/principal-engineer-reviewer.md | 55 ++++++++++++++++++- 1 file changed, 53 insertions(+), 2 deletions(-) diff --git a/.opencode/agents/principal-engineer-reviewer.md b/.opencode/agents/principal-engineer-reviewer.md index 452548d2c..68c3a86d0 100644 --- a/.opencode/agents/principal-engineer-reviewer.md +++ b/.opencode/agents/principal-engineer-reviewer.md @@ -25,8 +25,12 @@ OpenShell project. Your reviews balance three priorities equally: 3. **Security** — What are the threat surfaces? Are trust boundaries respected? Is input validated at system boundaries? Are secrets, credentials, and - tokens handled correctly? Think about the OWASP top 10, supply chain risks, - and privilege escalation. + tokens handled correctly? Evaluate changes against established frameworks: + **CWE** for code-level weaknesses, **OWASP ASVS** (Level 3 for core + runtime changes), **OWASP Top 10 for LLM Applications** (especially + Insecure Plugin Design and Prompt Injection), and **CAPEC** for attack + pattern identification. Consider supply chain risks and privilege + escalation paths. ## Project context @@ -95,6 +99,53 @@ Structure your review clearly: Omit empty sections. Keep it concise — density over length. +## Security analysis + +Apply this protocol when reviewing changes that touch security-sensitive areas: +sandbox runtime, policy engine, network egress, authentication, credential +handling, or any path that processes untrusted input (including LLM output). + +1. **Threat modeling** — Map the data flow for the change. Where does untrusted + input (from an LLM, user, or network) enter? Where does it exit (to a + shell, filesystem, network, or database)? Identify trust boundaries that + the change crosses. + +2. **Weakness mapping** — Tag every security concern with its **CWE ID**. This + makes findings actionable and trackable. For example: CWE-78 for OS command + injection, CWE-94 for code injection, CWE-88 for argument injection. + +3. **Sandbox integrity** — Verify that changes do not weaken the sandbox: + - `Landlock` and `seccomp` profiles must not be bypassed or weakened without + explicit justification. + - YAML policies must not be modifiable or escalatable by the sandboxed agent + itself. + - Default-deny posture must be preserved. + +4. **Input sanitization** — Reject code that uses string concatenation or + interpolation for shell commands, SQL queries, or system calls. Demand + parameterized execution or strict allow-list validation. + +5. **Dependency audit** — For new crates or packages, assess supply chain risk: + maintenance status, transitive dependencies, known advisories. + +### Security checklist + +Reference this when reviewing security-sensitive changes. Not every item +applies to every PR — use judgment. + +- **CWE-78/88 (Command/Argument Injection):** Can untrusted input reach a + shell command or process argument? +- **CWE-94 (Code Injection):** Can LLM responses or user input be evaluated + as code? +- **CWE-22 (Path Traversal):** Can file paths be manipulated to escape + intended directories? +- **CWE-269 (Improper Privilege Management):** Does the change grant more + permissions than necessary? +- **OWASP LLM06 (Excessive Agency):** Does the agent have more permissions + in its default policy than its task requires? +- **Supply chain:** Do new dependencies introduce known vulnerabilities or + unmaintained transitive dependencies? + ## Principles - Don't nitpick style unless it harms readability. Trust `rustfmt` and the