security-review

Security Review

Conduct a focused security review of the pending changes on the current branch. This is not a general code review. Report only high-confidence security vulnerabilities newly introduced by the branch.

Scope

Review the current branch diff against the default remote branch.

Use read-only git/context commands only:

git status
git diff --name-only origin/HEAD...
git log --no-decorate origin/HEAD...
git diff --merge-base origin/HEAD

If origin/HEAD is unavailable, determine the default remote branch with read-only git commands such as git remote show origin and use the appropriate merge base. Do not edit files. Do not write reports to disk unless the user explicitly asks for a file.

Ignore findings in:

• Documentation files such as Markdown.
• Files that are only unit tests or only used to run tests.
• Third-party dependency/version issues.

Objective

Identify HIGH-CONFIDENCE security vulnerabilities with real exploitation potential. Focus only on security implications newly added by this PR/branch. Do not comment on existing security concerns unless the branch makes them newly exploitable.

Critical instructions:

1. Minimize false positives: Only flag issues where confidence is at least 8/10 or >80%.
2. Avoid noise: Skip theoretical issues, style concerns, best-practice gaps, or low-impact findings.
3. Focus on impact: Prioritize vulnerabilities that could lead to unauthorized access, data breaches, or system compromise.
4. Do not report excluded issue classes, even if they look security-adjacent.

Hard Exclusions

Automatically exclude findings matching these patterns:

1. Denial of Service or resource exhaustion attacks.
2. Secrets or credentials stored on disk if otherwise secured or handled by other processes.
3. Rate limiting concerns or service overload scenarios.
4. Memory consumption or CPU exhaustion issues.
5. Lack of input validation on non-security-critical fields without proven security impact.
6. Input sanitization concerns for GitHub Actions unless clearly triggerable via untrusted input.
7. Lack of hardening measures or missing defense-in-depth controls.
8. Theoretical race conditions or timing attacks. Only report a race condition if concretely exploitable.
9. Outdated third-party libraries.
10. Memory safety issues in Rust or other memory-safe languages.
11. Files that are only unit tests or only used as part of running tests.
12. Log spoofing concerns. Unsanitized user input in logs is not a vulnerability by itself.
13. SSRF where only the path is attacker-controlled. SSRF matters only when attacker controls host or protocol.
14. User-controlled content included in AI system prompts.
15. Regex injection.
16. Regex DoS concerns.
17. Insecure documentation or findings in documentation files.
18. Lack of audit logs.