Security Review PR Skill

Audit the current pull request for code-level security concerns and fold any findings into the same review.json produced by review-pr.

Required Contract

Read .agents/contracts/review.md and follow it exactly. This skill is a supplement to review-pr; it must not create a separate report, change the review.json schema, loosen diff-line targeting, post to GitHub, call external security APIs, or regenerate snapshots.

When To Apply

• Apply on code and mixed PRs whenever review-pr is applied.
• Do not apply on spec-only PRs handled by review-spec.
• Skip the skill when no changed file introduces code or configuration touching the concerns below.
• Do not duplicate findings the base review-pr pass will already raise.

Security Concerns

Evaluate each changed hunk against these concerns. Treat the list as a checklist, not a ceiling; flag other clearly security-relevant issues when they appear.

Input Validation And Untrusted Data

• User-supplied or network-supplied input used without validation, length limits, or type checks.
• Deserialization of untrusted data, including pickle, yaml.load, eval, Function, or parsed JSON flowing into commands.
• Path traversal from user input concatenated into filesystem paths without normalization or an allowlist.
• SSRF from user-controlled URLs passed to outbound HTTP clients without scheme or host restrictions.
• Unbounded resource use driven by untrusted input.

Output Encoding And Sanitization

• Untrusted data interpolated into SQL, shell commands, HTML, Markdown, log lines, or URLs without proper encoding or parameterization.
• Use of shell=True, string concatenation into process execution, or raw SQL strings.
• Rendering user-supplied Markdown or HTML without sanitization.

Authentication And Authorization

• Missing or weakened authentication on new endpoints, RPC handlers, workflow triggers, or CLI commands.
• Authorization checks that trust client-supplied identifiers instead of the authenticated principal.
• Permission checks removed or made more permissive without clear justification.

Secrets, Crypto, And Sensitive Data

• Hardcoded credentials, API keys, private keys, tokens, or realistic secrets in fixtures.
• Secrets read from insecure locations, passed via command-line arguments, or written to logs, errors, analytics, or serialized payloads.
• Weak or deprecated primitives used for security, hand-rolled crypto, or non-cryptographic randomness used for tokens or security decisions.
• Logging or storing personally identifiable information, auth tokens, session IDs, or request bodies that may contain them without redaction.

Dependencies, Supply Chain, And Defaults

• New dependencies from unknown registries or forks without rationale.
• Loosened pinning that allows untrusted upgrades for sensitive packages.
• Fetching scripts over HTTP or piping downloaded content to a shell.
• Feature flags or configuration options that default to insecure values.
• Weakened CORS, cookie, header, TLS, or file-permission settings.

Reporting

• Prefix every security finding's comment body with [SECURITY] after the severity label, for example ⚠️ [IMPORTANT] [SECURITY] Secret written to logs: ....
• Add a ## Security subsection to the top-level review body only when there are security findings.
• Count security findings toward the same review summary and verdict. A critical security finding should generally produce REJECT.
• Tie findings to changed lines when possible. Put broad or untouched-code security concerns in top-level body.

Boundaries

• Do not run dynamic scans, fetch remote advisories, or call external security APIs.
• Do not speculate about vulnerabilities that cannot be tied to the diff or inspected repository files.
• Do not gate the PR on theoretical risks; prefer 💡 [SUGGESTION] when the risk is low or optional.