back
loading skill details...
AI-powered codebase security scanner that reasons about code like a security researcher — tracing data flows, understanding component interactions, and…
Security Review An AI-powered security scanner that reasons about your codebase the way a human security researcher would — tracing data flows, understanding component interactions, and catching vulnerabilities that pattern-matching tools miss. When to Use This Skill Use this skill when the request involves: Scanning a codebase or file for security vulnerabilities Running a security review or vulnerability check Checking for SQL injection, XSS, command injection, or other injection flaws Finding exposed API keys, hardcoded secrets, or credentials in code Auditing dependencies for known CVEs Reviewing authentication, authorization, or access control logic Detecting insecure cryptography or weak randomness Performing a data flow analysis to trace user input to dangerous sinks Any request phrasing like "is my code secure?", "scan this file", or "check my repo for vulnerabilities" Running /security-review or /security-review <path> How This Skill Works Unlike traditional static analysis tools that match patterns, this skill: Reads code like a security researcher — understanding context, intent, and data flow Traces across files — following how user input moves through your application Self-verifies findings — re-examines each result to filter false positives Assigns severity ratings — CRITICAL / HIGH / MEDIUM / LOW / INFO Proposes targeted patches — every finding includes a concrete fix Requires human approval — nothing is auto-applied; you always review first Execution Workflow Follow these steps in order every time: Step 1 — Scope Resolution Determine what to scan: If a path was provided (/security-review src/auth/), scan only that scope If no path given, scan the entire project starting from the root Identify the language(s) and framework(s) in use (check package.json, requirements.txt, go.mod, Cargo.toml, pom.xml, Gemfile, composer.json, etc.) Read references/language-patterns.md to load language-specific vulnerability patterns Step 2 — Dependency Audit Before scanning source code, audit dependencies first (fast wins): Node.js: Check package.json + package-lock.json for known vulnerable packages Python: Check requirements.txt / pyproject.toml / Pipfile Java: Check pom.xml / build.gradle Ruby: Check Gemfile.lock Rust: Check Cargo.toml Go: Check go.sum Flag packages with known CVEs, deprecated crypto libs, or suspiciously old pinned versions Read references/vulnerable-packages.md for a curated watchlist Step 3 — Secrets & Exposure Scan Scan ALL files (including config, env, CI/CD, Dockerfiles, IaC) for: Hardcoded API keys, tokens, passwords, private keys .env files accidentally committed Secrets in comments or debug logs Cloud credentials (AWS, GCP, Azure, Stripe, Twilio, etc.) Database connection strings with credentials embedded Read references/secret-patterns.md for regex patterns and entropy heuristics to apply Step 4 — Vulnerability Deep Scan This is the core scan. Reason about the code — don't just pattern-match. Read references/vuln-categories.md for full details on each category. Injection Flaws SQL Injection: raw queries with string interpolation, ORM misuse, second-order SQLi XSS: unescaped output, dangerouslySetInnerHTML, innerHTML, template injection Command Injection: exec/spawn/system with user input LDAP, XPath, Header, Log injection Authentication & Access Control Missing authentication on sensitive endpoints Broken object-level authorization (BOLA/IDOR) JWT weaknesses (alg:none, weak secrets, no expiry validation) Session fixation, missing CSRF protection Privilege escalation paths Mass assignment / parameter pollution Data Handling Sensitive data in logs, error messages, or API responses Missing encryption at rest or in transit Insecure deserialization Path traversal / directory traversal XXE (XML External Entity) processing SSRF (Server-Side Request Forgery) Cryptography Use of MD5, SHA1, DES for security purposes Hardcoded IVs or salts Weak random number generation (Math.random() for tokens) Missing TLS certificate validation Business Logic Race conditions (TOCTOU) Integer overflow in financial calculations Missing rate limiting on sensitive endpoints Predictable resource identifiers Step 5 — Cross-File Data Flow Analysis After the per-file scan, perform a holistic review: Trace user-controlled input from entry points (HTTP params, headers, body, file uploads) all the way to sinks (DB queries, exec calls, HTML output, file writes) Identify vulnerabilities that only appear when looking at multiple files together Check for insecure trust boundaries between services or modules Step 6 — Self-Verification Pass For EACH finding: Re-read the relevant code with fresh eyes Ask: "Is this actually exploitable, or is there sanitization I missed?" Check if a framework or middleware already handles this upstream Downgrade or discard findings that aren't genuine vulnerabilities Assign final severity: CRITICAL / HIGH / MEDIUM / LOW / INFO Step 7 — Generate Security Report Output the full report in the format defined in references/report-format.md. Step 8 — Propose Patches For every CRITICAL and HIGH finding, generate a concrete patch: Show the vulnerable code (before) Show the fixed code (after) Explain what changed and why Preserve the original code style, variable names, and structure Add a comment explaining the fix inline Explicitly state: "Review each patch before applying. Nothing has been changed yet." Severity Guide Severity Meaning Example 🔴 CRITICAL Immediate exploitation risk, data breach likely SQLi, RCE, auth bypass 🟠 HIGH Serious vulnerability, exploit path exists XSS, IDOR, hardcoded secrets 🟡 MEDIUM Exploitable with conditions or chaining CSRF, open redirect, weak crypto 🔵 LOW Best practice violation, low direct risk Verbose errors, missing headers ⚪ INFO Observation worth noting, not a vulnerability Outdated dependency (no CVE) Output Rules Always produce a findings summary table first (counts by severity) Never auto-apply any patch — present patches for human review only Always include a confidence rating per finding (High / Medium / Low) Group findings by category, not by file Be specific — include file path, line number, and the exact vulnerable code snippet Explain the risk in plain English — what could an attacker do with this? If the codebase is clean, say so clearly: "No vulnerabilities found" with what was scanned Reference Files For detailed detection guidance, load the following reference files as needed: references/vuln-categories.md — Deep reference for every vulnerability category with detection signals, safe patterns, and escalation checkers Search patterns: SQL injection, XSS, command injection, SSRF, BOLA, IDOR, JWT, CSRF, secrets, cryptography, race condition, path traversal references/secret-patterns.md — Regex patterns, entropy-based detection, and CI/CD secret risks Search patterns: API key, token, private key, connection string, entropy, .env, GitHub Actions, Docker, Terraform references/language-patterns.md — Framework-specific vulnerability patterns for JavaScript, Python, Java, PHP, Go, Ruby, and Rust Search patterns: Express, React, Next.js, Django, Flask, FastAPI, Spring Boot, PHP, Go, Rails, Rust references/vulnerable-packages.md — Curated CVE watchlist for npm, pip, Maven, Rubygems, Cargo, and Go modules Search patterns: lodash, axios, jsonwebtoken, Pillow, log4j, nokogiri, CVE references/report-format.md — Structured output template for security reports with finding cards, dependency audit, secrets scan, and patch proposal formatting Search patterns: report, format, template, finding, patch, summary, confidence
don't have the plugin yet? install it then click "run inline in claude" again.
added explicit decision points for each vulnerability type, structured 11-step procedure with input/output contracts, documented environment setup requirements, clarified output format and success criteria, included edge cases like git history scanning and dependency severity triage, and made blocking conditions for deployment explicit.
run this skill when adding authentication, handling user input, working with secrets, creating API endpoints, or implementing payment/sensitive features. it ensures all code follows security best practices and identifies potential vulnerabilities before they hit production. use it as a gate before any deployment touching auth, data, or external integrations.
no external connections required. you need:
.env.local exists and is in .gitignorenpm audit --json)secrets management audit
sk-, key=, password, token, secretprocess.env.OPENAI_API_KEY).env.local and .env are listed in .gitignoregit log --all --full-history -- .env .env.local to catch leaked secrets in historyinput validation check
database query security
+, template literals with ${} in queries.eq(), raw SQL with $1, $2)authentication and token handling
HttpOnly; Secure; SameSite=Strictauthorization checks
XSS prevention
dangerouslySetInnerHTML without sanitizationCSRF protection
rate limiting
sensitive data logging
dependency security
npm auditrun pre-deployment checklist
if hardcoded secrets found (step 1): rotate those secrets immediately, remove from code and git history using git filter-branch or BFG Repo-Cleaner, re-add via environment variables, redeploy.
if input validation missing (step 2): generate Zod schema template for the endpoint and block deployment until validation is added. for file uploads, enforce size and type checks before processing.
if parameterized queries not used (step 3): refactor to ORM or parameterized SQL immediately, do not pass to production.
if tokens in localStorage (step 4): switch to httpOnly cookies with Secure and SameSite flags before merging.
if authorization checks missing (step 5): add role/permission verification before any data access, enable Supabase RLS policies.
if user content rendered without sanitization (step 6): add DOMPurify and CSP headers before deployment.
if CSRF protection absent (step 7): add CSRF token validation on all POST/PUT/DELETE endpoints.
if rate limiting missing (step 8): add rate limit middleware to all endpoints, stricter limits on expensive operations.
if sensitive data in logs (step 9): redact passwords, tokens, card numbers, remove stack traces from client responses.
if npm audit shows vulnerabilities (step 10): if high/critical severity, update packages or hold deployment until patched. if optional/low, document and proceed.
if checklist fails more than 3 items (step 11): do not deploy. fix all blocker items before resubmitting for review.
success means a security audit report document containing:
.gitignore status, git history scan resultfile location: save as SECURITY_AUDIT_<timestamp>.md in project root or docs folder. include date, reviewer name, and recommended actions.
you know the skill worked when:
if any blocker item fails (hardcoded secrets, missing validation, SQL injection risk, tokens in localStorage), the skill output is "SECURITY REVIEW FAILED - do not deploy" and a blocking PR comment is required.
credits: original skill by affaan-m (skills.sh). enriched for implexa standards with explicit decision branches, edge case handling, and pre-deployment validation gates.