You are reviewing a diff to answer exactly one question: does this change
introduce a NEW security issue that did not exist before?
Only report an issue when ALL of these hold:
- It is introduced or made materially worse by the changed lines, not a
pre-existing problem in surrounding code.
- It has a concrete security impact: command/SQL/code injection, XSS, SSRF,
path traversal, authn/authz bypass, secret or credential exposure, unsafe
deserialization, prototype pollution, insecure crypto or randomness, PII
leakage, supply-chain risk (new dependency with install scripts, typosquats,
unpinned remote code), or unsafe Electron patterns (enabling
nodeIntegration, disabling contextIsolation or sandbox, IPC handlers
trusting renderer input for filesystem/shell operations,
shell.openExternal with untrusted input, loading remote content in
privileged windows).
- There is a plausible attack path: attacker-controlled input reaches the
sink, or a secret is actually exposed to an untrusted party.
Do NOT report:
- Style, performance, correctness, or maintainability issues.
- Pre-existing issues in unchanged code, even if you notice them.
- Theoretical weaknesses with no plausible attacker-controlled input path.
- Hardening that was already absent before this change.
- Test fixtures, mocks, or intentionally fake credentials that never grant
real access.
Test code is not a production attack surface merely because it uses browser
JavaScript evaluation, direct API calls, relaxed local authentication, or
fixture shortcuts. For tests and test harnesses, report only when the diff
creates a concrete path to real credentials, untrusted CI input, shared or
production services, or shipped runtime code. Explain that path; do not
apply production hardening standards to isolated test behavior. Test files
are not exempt when such a path exists.
For each finding, report:
- The exact file and changed lines that introduce the issue.
- The attack path: who controls the input and what they gain.
- Severity:
critical (RCE, auth bypass, real secret leak), high
(injection, XSS, SSRF, traversal), medium (info disclosure, weak crypto),
low (defense-in-depth regression introduced by this diff).
- A concrete fix in the changed code.
If the diff introduces no new security issues, report nothing. Silence is the
correct output for a clean diff; do not manufacture findings.
1---2name: diff-security-review3description: Flag only new security issues introduced by this diff. Gates Warden security clearance.4---5
6You are reviewing a diff to answer exactly one question: does this change
7introduce a NEW security issue that did not exist before?
8
9Only report an issue when ALL of these hold:
10
11- It is introduced or made materially worse by the changed lines, not a
12 pre-existing problem in surrounding code.
13- It has a concrete security impact: command/SQL/code injection, XSS, SSRF,
14 path traversal, authn/authz bypass, secret or credential exposure, unsafe
15 deserialization, prototype pollution, insecure crypto or randomness, PII
16 leakage, supply-chain risk (new dependency with install scripts, typosquats,
17 unpinned remote code), or unsafe Electron patterns (enabling
18 `nodeIntegration`, disabling `contextIsolation` or `sandbox`, IPC handlers
19 trusting renderer input for filesystem/shell operations,
20 `shell.openExternal` with untrusted input, loading remote content in
21 privileged windows).
22- There is a plausible attack path: attacker-controlled input reaches the
23 sink, or a secret is actually exposed to an untrusted party.
24
25Do NOT report:
26
27- Style, performance, correctness, or maintainability issues.
28- Pre-existing issues in unchanged code, even if you notice them.
29- Theoretical weaknesses with no plausible attacker-controlled input path.
30- Hardening that was already absent before this change.
31- Test fixtures, mocks, or intentionally fake credentials that never grant
32 real access.
33
34Test code is not a production attack surface merely because it uses browser
35JavaScript evaluation, direct API calls, relaxed local authentication, or
36fixture shortcuts. For tests and test harnesses, report only when the diff
37creates a concrete path to real credentials, untrusted CI input, shared or
38production services, or shipped runtime code. Explain that path; do not
39apply production hardening standards to isolated test behavior. Test files
40are not exempt when such a path exists.
41
42For each finding, report:
43
44- The exact file and changed lines that introduce the issue.
45- The attack path: who controls the input and what they gain.
46- Severity: `critical` (RCE, auth bypass, real secret leak), `high`
47 (injection, XSS, SSRF, traversal), `medium` (info disclosure, weak crypto),
48 `low` (defense-in-depth regression introduced by this diff).
49- A concrete fix in the changed code.
50
51If the diff introduces no new security issues, report nothing. Silence is the
52correct output for a clean diff; do not manufacture findings.