Security Scan

Overview

Conduct a security-focused review of the code or change set. Map trust boundaries first, then inspect how untrusted input, credentials, permissions, dependencies, and deployment defaults are handled.

When To Use

• After adding or changing authentication or authorization logic.
• After adding new API endpoints, uploads, background jobs, or external integrations.
• Before production deployment.
• When the change handles untrusted input, secrets, tokens, files, or network calls.
• When the user explicitly requests a security review or audit.

Review Workflow

1. Map the attack surface.

   • Entry points, user-controlled input, file access, network access, storage boundaries, and privileged operations.

2. Review authentication and authorization.

   • Authentication bypasses.
   • Missing authorization checks.
   • Confused trust boundaries between user, service, and admin actions.

3. Review input handling and injection surfaces.

   • SQL, NoSQL, shell, template, and path injection.
   • XSS and unsafe HTML rendering.
   • SSRF, open redirects, and unsafe outbound requests.

4. Review secrets and cryptography.

   • Hardcoded keys, tokens, passwords, or connection strings.
   • Weak password hashing or unsafe token generation.
   • Sensitive data exposure in logs, errors, or client payloads.

5. Review dependency and configuration risk.

   • Known vulnerable dependencies.
   • Overly permissive defaults.
   • Missing secure headers, unsafe CORS, or weak production settings.

6. Review detection and recovery.

   • Are important security-relevant failures logged?
   • Would an operator be able to detect abuse or investigate an incident?

7. Report severity-rated findings with remediation guidance.

   • CRITICAL: exploitable issue or active secret exposure; block deployment.
   • HIGH: serious vulnerability or major trust-boundary weakness; fix before release.
   • MEDIUM: meaningful hardening gap or partial control failure.
   • LOW: defense-in-depth improvement or cleanup.

Security Checklist

• Authentication and authorization boundaries are explicit and enforced.
• Untrusted input is validated, normalized, and escaped at the correct boundary.
• Queries and commands are parameterized and never built from raw user input.
• Secrets are not stored in source, test fixtures, logs, or client-visible responses.
• File and network access respect allowlists and path or host validation where appropriate.
• Dependency versions and deployment defaults do not introduce known high-risk vulnerabilities.

Operating Rules

• Think in trust boundaries and attacker-controlled inputs, not only code style.
• Prefer reproducible exploit paths over vague warnings.
• Name the impacted asset or permission boundary for every serious finding.
• Include a practical remediation path, not just the vulnerability label.
• If no critical issues are found, still call out hardening gaps and any unreviewed surfaces.

Default Deliverable Shape

Return these sections:

1. Attack Surface
2. Findings - ordered by severity with file and line references where possible.
3. Exploit Path / Impact - why each important issue matters.
4. Remediation - concrete fixes and safer patterns.
5. Residual Risks - remaining uncertainty or unreviewed areas.