security-review
Analyze a diff or changed files for common security vulnerabilities (injection, XSS, SSRF, secrets). Defaults to staged changes. Triggers on: "security review", "check for secrets", "vulnerability scan".
- License 许可
- MIT
- 最近更新
- 2026-10-26
- Stars
- ★ 0
- Forks
- 0
01 前言 Front Matter
- name
- security-review
- description
- Analyze a diff or changed files for common security vulnerabilities (injection, XSS, SSRF, secrets). Defaults to staged changes. Triggers on: "security review", "check for secrets", "vulnerability scan".
- allowed-tools
- Read Grep Bash
- argument-hint
- [PR# | path | staged]
03 SKILL.md 正文
Analyze a diff or set of changed files for common security vulnerabilities.
Arguments: $ARGUMENTS (optional: a PR number, file path, or staged for staged changes. Default: staged changes.)
This is a fast checklist on one diff. For a whole-repository or subsystem audit with independently verified findings, use the security-audit skill instead.
Stack detection
Detect what's in the repo before applying checks (run once at the start):
HAS_NODE=$([ -f package.json ] && echo 1)
HAS_GO=$([ -f go.mod ] && echo 1)
HAS_PY=$([ -f pyproject.toml ] || [ -f requirements.txt ] && echo 1)
HAS_RUST=$([ -f Cargo.toml ] && echo 1)
HAS_DOCKER=$([ -f Dockerfile ] || [ -f compose.yml ] || [ -f docker-compose.yml ] && echo 1)
HAS_K8S=$(ls k8s/*.yaml charts/ 2>/dev/null | head -1)
Apply only the relevant checklists below.
What this checks
OWASP Top 10 adapted per detected stack. Each category lists the globs to target and the class of issue to flag.
Frontend (if HAS_NODE and source looks like a web app)
Common frontend globs: src/**/*.{js,jsx,ts,tsx,vue,svelte}, app/**/*.{js,jsx,ts,tsx}, pages/**/*.{js,jsx,ts,tsx}, components/**/*.
- XSS: React's raw-HTML injection prop (
dangerously*), Vue'sv-html, Svelte's{@html ...}, unescaped URL params rendered into the DOM, template-literal injection into DOM sinks. - Open redirect: Unvalidated
window.location/router.pushassignments from user input or URL params. - Sensitive data in client: API keys, tokens, or secrets hardcoded in source files. Anything prefixed
NEXT_PUBLIC_,VITE_,REACT_APP_holding a secret-shaped value is a leak. - localStorage / sessionStorage abuse: Storing auth tokens or sensitive data without namespacing; reading without validation.
- Dependency risk: New npm dependencies added. Run
npm audit(orpnpm audit/yarn audit) and flag known CVEs at moderate+ severity. - CSP / headers: Regressions in
Content-Security-Policy,X-Frame-Options,Referrer-Policy,Permissions-Policy.
Backend (Go, if HAS_GO)
Globs: **/*.go (excluding **/*_test.go unless the test introduces real endpoints).
- SQL injection: String concatenation in queries instead of parameterized statements (
$1,$2, or driver-specific placeholders). - Auth bypass: New routes without the project's auth middleware; protected endpoints that don't call a
RequireAuth/RequireAdminwrapper. - CORS misconfiguration: Wildcard
*origins combined withcredentials: true; reflectedOriginheader without allowlist. - Secret exposure: Hardcoded secrets, API keys, database URLs in Go source or config files.
- Path traversal: User-controlled file paths without
filepath.Clean+ containment checks. - SSRF:
http.Get/http.NewRequeston URLs derived from user input without an allowlist. - Deserialization:
json.Unmarshalintointerface{}combined with type assertions on unvalidated input.
Backend (Node/TS, if HAS_NODE and there's server code)
Globs: api/**/*.{ts,js}, server/**/*.{ts,js}, app/api/**/*.{ts,js} (Next.js route handlers), middleware.{ts,js}.
- NoSQL/SQL injection via unparameterized queries.
- Prototype pollution: unsafe
Object.assign/ spread into user-provided JSON. - Auth bypass, CORS, secret exposure, path traversal, SSRF: same as Go section above.
- Weak crypto:
crypto.createHash('md5')orsha1for anything security-relevant.
Backend (Python, if HAS_PY)
Globs: **/*.py (excluding tests).
- SQL injection: f-string / %-format SQL instead of parameterized cursors.
- Shell injection:
subprocess.*(shell=True)with user-controlled args;os.system. - Unsafe deserialization: Python's binary object-serialization module (flag imports and
loadscalls against untrusted input — prefer JSON); YAML withoutSafeLoader. - Auth, CORS, secrets, path traversal, SSRF: same mental model as above.
Data / config files
Globs: any tracked data file (data/**, content/**, project-specific generated files), plus .env*, config/**, infra/**.
- Credential leakage: Database URLs, API keys, tokens accidentally committed.
- SQL injection via migration: Dynamic SQL or unsanitized interpolation in migration files (
migrations/**.sql,db/migrate/**).
Docker / Kubernetes (if detected)
- Privileged containers:
privileged: true,allowPrivilegeEscalation: true. - Hostpath mounts that expose the host filesystem.
- Secrets in env blocks: plaintext values in
env:whereenvFrom: secretRefis the right pattern. latestimage tags in production manifests.
Steps
-
Determine the diff to review:
- If a PR number was given:
gh pr diff <number> - If a file path was given:
git diff HEAD -- <path> - If
stagedor no argument:git diff --cached(fall back togit diffif nothing staged)
- If a PR number was given:
-
For each changed file, map to the applicable checklists above based on path and file extension.
-
Classify each finding:
- CRITICAL: Exploitable vulnerability (XSS, SQL/NoSQL injection, auth bypass, credential exposure, SSRF with internal network reachable).
- WARNING: Potential issue needing review (new dependency with unclear provenance, broad CORS, missing input validation, weak crypto).
- INFO: Best practice suggestion (namespace localStorage keys, add rate limiting, tighten CSP, prefer typed query helpers).
-
Report as a table:
| Severity | File | Line | Finding | Recommendation |
|---|
- If no issues found, report "Security review: clean."
Do NOT auto-fix. Report findings for the user or the calling workflow to act on.
04 同仓库更多 Skills
yolo
Start temporary autonomy for the current task or an explicit scope with a required --for expiry. Codex permits scoped pushes, merges, deploys, and releases after strict testing and validation; Full access is a separate runtime setting. Claude Code uses a session permission hook with a protected-action denylist.
veracity-audit
Audit a data pipeline for Veracity and Value. Dispatches data-scientist, compliance-auditor, and data-engineer agents with project context injected at dispatch time. All source paths are supplied via flags — no defaults, no project assumptions. Subcommands: audit (full pipeline walk), score-check (scoring math only), gate-check (gate coverage only), source-trace <label> (single source end-to-end). Invoke when: "audit pipeline", "veracity check", "scoring math correct?", "check gates", "trace source", "verify quality gates", "formula correct?".
validate-spec
Audit an already-implemented spec against the codebase. Walks each constraint (ARCH-N, PERF-N, KD-N, etc.) and acceptance criterion, grounds findings in file:line evidence, runs the spec.json acceptance_commands, and writes a single audit doc to docs/audits/. Use whenever the user asks to "validate a spec", "audit a spec", "check if spec is implemented", "verify the spec is done", "is this spec really done", or otherwise wants closure on spec-driven work. Read-only against the spec — produces an audit, never modifies the spec itself.
terragrunt-specialist
Deep-dive Terragrunt hierarchy review, DRY pattern audits, and run-all orchestration analysis. Use for structured investigations of multi-environment Terragrunt layouts, dependency graphs, remote state config, and hook correctness. Triggers on: "Terragrunt audit", "run-all review", "dependency block", "DRY pattern review", "env hierarchy audit", "mock_outputs", "terragrunt hooks".
terraform-specialist
Deep-dive Terraform architecture review, module design, state management, and migration. Use for structured investigations of Terraform workspaces, provider configuration, module coupling, import workflows, and test coverage. Triggers on: "Terraform audit", "module review", "state management", "Terraform import", "workspace design", "provider config review", "Terraform testing".
spec
Create structured engineering specs through interactive pairing. Use when the user wants to create a spec, design doc, technical specification, architecture document, RFC, or engineering plan. Triggers on "let's spec this out", "create a spec", "design doc", "write a technical plan", "plan the architecture". Works for greenfield and brownfield projects. Outputs to docs/specs/.