Security PR Review
Purpose
Review changed code with a security-review mindset: prioritize introduced bugs, exploitable regressions,
and missing coverage in the modified attack surface. Focus on what the diff changes, not on writing a
general audit of the whole repository.
Scope Rules
- Prioritize vulnerabilities introduced or exposed by the diff.
- Inspect surrounding code when needed to confirm reachability, auth context, or sanitizer behavior.
- Mention pre-existing issues only when the change makes them reachable, worse, or security-relevant now.
- Findings come first; summary is secondary.
Workflow
Step 1: Read the Diff as an Attack Surface Change
Identify:
- newly added endpoints, handlers, controllers, jobs, or CLI paths
- changed authorization checks or middleware wiring
- new deserialization, template rendering, file, network, or command execution paths
- config changes that weaken defaults or widen trust boundaries
Step 2: Map New Sources, Sinks, and Guards
For changed code, locate:
- attacker-controlled inputs
- dangerous sinks
- sanitization, validation, auth, and feature-flag guards
Do not stop at the edited hunk if the actual sink or protection lives nearby.
Step 3: Trace Security-Sensitive Data Flow
Apply lightweight taint reasoning through:
- helper calls
- serializers and DTOs
- middleware layers
- ORM/query helpers
- template/view rendering
- background job enqueue/dequeue boundaries
Step 4: Review Diff-Specific Risk Patterns
Pay extra attention to:
- string-built queries, filters, or shell commands
- unsafe deserialization, polymorphic typing, object revival, or parser feature flags
- auth checks moved later in the flow
- newly trusted headers, cookies, or client-supplied role fields
- open redirects added through
next, returnTo, or redirect_url
- debug logging of secrets, tokens, or PII
- upload handling, archive extraction, or path joins
- new outbound HTTP fetches or webhook callbacks
- security settings changed from strict to permissive
Step 5: Judge Before Reporting
For every candidate finding, verify:
- the input is actually attacker-controlled
- the changed path is reachable
- protections are not already effective
- the issue is materially exploitable
Drop speculative findings that cannot survive this check.
Step 6: Report Findings and Testing Gaps
Report confirmed issues with:
- severity
- exact changed file and line
- exploit path in one short paragraph
- concrete remediation direction
- missing test coverage if the diff should have added one
If no confirmed issue exists, say so explicitly and note any residual uncertainty or testing gaps.
Review Guardrails
- Do not file a security finding purely because code "looks risky"; explain the actual exploit path.
- Do not ignore new trust boundaries just because the sink is in an unchanged helper.
- Do not report infra-only assumptions as app bugs unless the diff depends on them.
- Do not downgrade auth bugs simply because the endpoint is "internal" without evidence.
- Do not confuse code-quality concerns with security findings unless they create exploitability.
Output Format
Use this structure:
[SEVERITY] <short title>
File: <path>:<line>
Why it matters: <reachability + impact in 2-4 sentences>
Fix: <specific remediation>
Tests: <missing or recommended coverage>
When there are no findings:
No confirmed security findings in the reviewed diff.
Residual risk: <short note or "none identified">
Testing gap: <short note or "none identified">
1---2name: eresus-pr-security-review3description: Security-focused pull request and diff review skill for finding newly introduced vulnerabilities, risky regressions, and missing security tests in changed code. Trigger when the user asks to: "review this PR for security", "check this diff for vulns", "do a security code review", "audit changed files", or wants findings on a patch instead of a full-repo scan. Best used alongside eresus-sast-scanner.4---5
6# Security PR Review
7
8## Purpose
9
10Review changed code with a security-review mindset: prioritize introduced bugs, exploitable regressions,
11and missing coverage in the modified attack surface. Focus on what the diff changes, not on writing a
12general audit of the whole repository.
13
14## Scope Rules
15
16- Prioritize vulnerabilities introduced or exposed by the diff.
17- Inspect surrounding code when needed to confirm reachability, auth context, or sanitizer behavior.
18- Mention pre-existing issues only when the change makes them reachable, worse, or security-relevant now.
19- Findings come first; summary is secondary.
20
21---
22
23## Workflow
24
25### Step 1: Read the Diff as an Attack Surface Change
26
27Identify:
28
29- newly added endpoints, handlers, controllers, jobs, or CLI paths
30- changed authorization checks or middleware wiring
31- new deserialization, template rendering, file, network, or command execution paths
32- config changes that weaken defaults or widen trust boundaries
33
34### Step 2: Map New Sources, Sinks, and Guards
35
36For changed code, locate:
37
38- attacker-controlled inputs
39- dangerous sinks
40- sanitization, validation, auth, and feature-flag guards
41
42Do not stop at the edited hunk if the actual sink or protection lives nearby.
43
44### Step 3: Trace Security-Sensitive Data Flow
45
46Apply lightweight taint reasoning through:
47
48- helper calls
49- serializers and DTOs
50- middleware layers
51- ORM/query helpers
52- template/view rendering
53- background job enqueue/dequeue boundaries
54
55### Step 4: Review Diff-Specific Risk Patterns
56
57Pay extra attention to:
58
59- string-built queries, filters, or shell commands
60- unsafe deserialization, polymorphic typing, object revival, or parser feature flags
61- auth checks moved later in the flow
62- newly trusted headers, cookies, or client-supplied role fields
63- open redirects added through `next`, `returnTo`, or `redirect_url`
64- debug logging of secrets, tokens, or PII
65- upload handling, archive extraction, or path joins
66- new outbound HTTP fetches or webhook callbacks
67- security settings changed from strict to permissive
68
69### Step 5: Judge Before Reporting
70
71For every candidate finding, verify:
72
73- the input is actually attacker-controlled
74- the changed path is reachable
75- protections are not already effective
76- the issue is materially exploitable
77
78Drop speculative findings that cannot survive this check.
79
80### Step 6: Report Findings and Testing Gaps
81
82Report confirmed issues with:
83
84- severity
85- exact changed file and line
86- exploit path in one short paragraph
87- concrete remediation direction
88- missing test coverage if the diff should have added one
89
90If no confirmed issue exists, say so explicitly and note any residual uncertainty or testing gaps.
91
92---
93
94## Review Guardrails
95
96- Do not file a security finding purely because code "looks risky"; explain the actual exploit path.
97- Do not ignore new trust boundaries just because the sink is in an unchanged helper.
98- Do not report infra-only assumptions as app bugs unless the diff depends on them.
99- Do not downgrade auth bugs simply because the endpoint is "internal" without evidence.
100- Do not confuse code-quality concerns with security findings unless they create exploitability.
101
102---
103
104## Output Format
105
106Use this structure:
107
108```markdown
109[SEVERITY] <short title>
110File: <path>:<line>
111Why it matters: <reachability + impact in 2-4 sentences>
112Fix: <specific remediation>
113Tests: <missing or recommended coverage>
114```
115
116When there are no findings:
117
118```markdown
119No confirmed security findings in the reviewed diff.
120Residual risk: <short note or "none identified">
121Testing gap: <short note or "none identified">
122```
aibot88