Security Review

Security Review (OWASP Top 10)

> Purpose: Detect and surface critical security flaws in a codebase via static analysis before deployment, and deliver reproducible evidence and remediation guidance. > > Core principle: This skill is analysis and reporting only. It does not auto-fix anything. > > /audit integration: Performs the security track within /audit's 5-stage quality audit and can deliver results as standard artifacts.

---

MCP Dependencies

| MCP | Required | Purpose | |-----|----------|---------| | None | - | Uses basic search/static analysis tools |

> External SAST/Dependency Scan result files are supported in interpret/summarize mode only.

---

Absolute Prohibitions (Safety & Constraints)

1. No writing exploit code or attack payloads

• Reproduction notes must be limited to "input conditions / flow / expected vs. actual" — no attack code

1. No unsubstantiated assertions

• Every finding must include file_path:line-based evidence

1. No re-exposing secrets or PII

• Raw values must never appear in reports, terminal output, or artifacts

1. No scanning unauthorized targets

• Only inspect explicitly approved code/environments; do not access or test external systems

Sensitive Data Masking Rules

• Tokens, keys, session values, passwords: raw values forbidden
• Default masking: first 3–4 chars + "***" + (length/type hint)
• e.g., AKIA*** (len=20), sk-*** (prefix=sk-), ***PRIVATE KEY***
• When quoting log/sample data, minimize or de-identify user identifiers (email/phone/IP)

Emergency Response Triggers (operational view)

• If any of the following apply, classify immediately as CRITICAL candidate and recommend revocation/reissuance/impact assessment before any fix:
• A secret that appears to be an active (production) key is exposed
• Credentials directly tied to payment/PII/admin access are exposed

---

Actions to Execute Immediately on Skill Activation (High-level)

1. Pre-flight scoping (project characteristics, excluded paths, output artifact format)
2. Secret/credential exposure scan + post-exposure response guidance
3. OWASP A01–A10 coverage (required: A04/A06/A10 included)
4. Web/API high-risk checks (SSRF, file upload, path traversal, deserialization, CSRF, Clickjacking)
5. Dependency/supply-chain risk check (lockfile + install scripts + drift)
6. Triage (false-positive filtering): Source→Sink flow + defense mechanism verification
7. Report: prioritized findings + remediation guide + verification steps

---

Execution Process (Checklist)

Stage 0: Pre-flight Scoping (required)

• In-scope (default)
• src/, app/, server/, api/, infra/ (if present), config files
• Out-of-scope (default)
• Generated/vendor/cache: **/node_modules/**, **/dist/**, **/build/**, **/.next/**, **/coverage/**, **/*.min.*
• Test fixtures included by default (can be excluded if noisy)
• Output artifacts
• (default) Markdown report
• (optional) JSON artifact for /audit integration

Completion criteria: include/exclude paths, scan mode (quick/standard/deep), and output format (md/json) confirmed.

Stage 1: Secret/Credential Exposure

Check items

• Hardcoded API keys, access tokens, private keys, DB URLs
• .env* and credential files tracked in the repo
• Sensitive data printed in log/error messages

Evidence requirements

• file_path:line + (up to 5 lines) snippet (masking applied)

Post-exposure response procedure (include in report)

• Key identifier (service/environment only if possible) + exposure location
• Whether revocation/reissuance is needed + estimated impact scope (env: dev/stage/prod)

Completion criteria: Secret candidates classified as Confirmed / FP (false positive) / Needs-more-context.

Stage 2: OWASP Top 10 (A01–A10) Full Matrix

> Each item requires at least one "detection rule" and "required evidence".

| OWASP | Core question (summary) | Minimum evidence (required) | |---|---|---| | A01 Broken Access Control | Is authorization validation missing or bypassable? | Guard/policy code location + access path/resource identifier handling | | A02 Cryptographic Failures | Is storage/transmission/key management weak? | Algorithm/mode/key storage location, TLS/cookie config | | A03 Injection | Does external input reach a dangerous sink? | Source→Sink path + query/command/template construction method | | A04 Insecure Design | Are security controls missing at the design level? | Evidence of absent threat model / ambiguous auth model / unprotected sensitive operations | | A05 Security Misconfiguration | Are there unsafe settings, headers, or debug flags? | Config files/server init code + actual values | | A06 Vulnerable & Outdated Components | Are vulnerable or outdated components in use? | lockfile/version/supply-chain signals (postinstall, etc.) | | A07 Identification & Authentication Failures | Is the authentication flow broken? | Token validation (signature/expiry/iss/aud), session/reset flow evidence | | A08 Software & Data Integrity Failures | Is there update/execution without integrity verification? | External script/update/plugin load paths | | A09 Security Logging & Monitoring Failures | Are security events being logged and detected? | Minimum event list coverage + logging locations | | A10 Server-Side Request Forgery (SSRF) | Does the server make requests based on attacker-controlled input? | URL fetch call sites + validation/blocking logic |

A03 Injection Sub-categories (required)

• SQL / NoSQL
• Command / Shell argument injection
• Template injection
• LDAP / XPath
• CRLF (Header) / Response splitting

Auth/AuthZ Detailed Checklist (required)

• JWT/session: signature, expiry, iss/aud and other critical claim validation
• Password reset / email verification: token lifetime, single-use, post-use invalidation
• Privilege escalation: horizontal (IDOR), vertical (role escalation) paths
• Brute-force defense: rate limit/lockout/2FA enforcement points (if applicable)

Stage 3: Web/API High-Risk Checks (required)

SSRF (overlaps A10 but checked separately)

• Does the server fetch externally supplied URLs?
• Is an allowlist enforced? Are internal IPs/metadata endpoints blocked?

Path Traversal

• Is user input combined with file paths or filenames?
• Missing validation after ../, absolute paths, URL decoding?

File Upload

• Extension/MIME/content-sniffing validation, isolated storage path, executable file blocking
• Post-upload access control (private files/signed URLs, etc.)

Deserialization

• Is untrusted input processed with unsafe deserialization?
• e.g., Python pickle, unsafe YAML load, Java ObjectInputStream (language-specific)

Browser Security: CSRF / Clickjacking

• CSRF defense token / SameSite policy on state-mutating requests
• Clickjacking protection: X-Frame-Options or CSP frame-ancestors

Stage 4: Dependency/Supply-Chain Check

Use when available (if environment permits)

• Node.js: npm audit, pnpm audit, yarn audit
• Python: pip-audit, poetry audit

Supply Chain Risk (static checks)

• Lockfile integrity/drift (e.g., package-lock.json vs. package.json mismatch)
• Presence of postinstall/preinstall install scripts
• Signs of newly added or unfamiliar packages (typosquatting suspects)
• Remote script download/execution patterns

Completion criteria: Record "vulnerabilities (version)" and "supply-chain signals (behavior)" separately.

Stage 4.5: Triage (False-Positive Filtering) & Evidence Collection

Before reporting any candidate vulnerability, verify the following:

• Source→Sink data flow: Does external input (Source) reach a dangerous sink without defense?
• Defense mechanism check: Presence of sanitization/encoding/parameterization/type casting
• Evidence collection rules: file:line + snippet (up to 5 lines, masked) + 1–2 sentences on "why this is dangerous"

Completion criteria: All candidates classified as Confirmed / Likely / Needs-context / False-positive.

Stage 5: Report

Priority Scoring Rule

• Priority = Severity × Exploitability × Exposure Scope × Asset Criticality (PII/payment/admin)

Finding Required Fields

Each issue must include the following fields:

• finding_id: SR-0001 format
• title: One-line summary
• owasp / cwe (where available)
• severity: CRITICAL/HIGH/MEDIUM/LOW
• confidence: High/Medium/Low (static analysis confidence)
• location: file_path:line
• evidence: (up to 5 lines) snippet + key evidence summary
• impact: CIA (Confidentiality/Integrity/Availability) + target asset (e.g., PII, payment, admin access)
• reproduction_notes (safe): Describe input conditions and flow without attack code
• remediation:
• Safe pattern (recommended)
• Unsafe pattern (avoid)
• Verification method (test/re-scan checklist)
• status: New/Confirmed/False-Positive/Accepted-Risk/Fixed (where known)

---

Output Format

1) Summary Box

• Total score (optional), verdict (OK/NEEDS FIX), severity counts
• Scan scope/mode/excluded paths summary

2) Top Findings Table

| ID | Severity | OWASP | Title | Location | Confidence | |---|---|---|---|---|---| | SR-0001 | HIGH | A03 | ... | src/...:123 | High |

3) Detailed Findings

• One section per finding, using the required fields template above

4) Priority Actions (Top 3)

1. Immediately fix and re-verify CRITICAL/HIGH items
2. Harden shared auth/authz guards and input validation layer
3. Revoke/reissue secrets where exposure is confirmed

5) Confidence & Limitations (required)

• State the limits of static analysis, out-of-scope areas, and items requiring runtime/environment verification

---

Command Flags

| Command | Description | |--------|-------------| | /security-review | Default (standard) scan | | /security-review --mode quick | Fast scan of core rules only | | /security-review --mode deep | Full rules + supply-chain/config deep scan | | /security-review --path | Scan specified path only | | /security-review --include "src/**" | Specify include pattern | | /security-review --exclude "**/node_modules/**,**/dist/**" | Specify exclude pattern | | /security-review --checks "secrets,auth,ssrf" | Re-scan specific categories only | | /security-review --summary | Summary-focused report | | /security-review --owasp | OWASP-mapping-focused output | | /security-review --format md | Default output (Markdown) | | /security-review --format json --out .claude/security-review.json | JSON artifact (automation/integration) | | /security-review --min-confidence high | Output High confidence issues only | | /security-review --severity-threshold high | Use High and above as summary/gate threshold | | /security-review --fail-on high | Fail if any High or above is unresolved (pipeline use) | | /security-review --since | Delta scan focused on changed code | | /security-review --baseline | Compare against existing baseline (skip known/accepted issues) |

---

/audit Integration Contract

Role Separation

• /audit: Aggregate score / gate verdict / overall quality integration
• security-review: Security flaw identification + evidence + remediation guidance

Output Artifacts (recommended)

• Default path: .claude/security-review.json (or --out)
• Minimum required fields:
• scan: include/exclude, mode, checks, timestamp
• findings[]: required finding fields
• limits: out-of-scope, unchecked items
• redaction: masking policy (raw values forbidden)

Deduplication Rules (recommended)

• Dedup key: rule_id (or owasp+cwe) + file + line + sink/source
• Same issue counts as one; if evidence strengthens, update evidence only

Stage Mapping (recommended)

• Attach this skill's results (JSON/report) as "evidence" in the audit security stage
• If other skills/tools provide SAST results, focus on "interpretation/prioritization" rather than duplicate detection

---

Suggested Next Steps

| Situation | Recommended skill | Description | |-----------|-------------------|-------------| | High-risk vulnerability found | /agile iterate | Create and execute prioritized fix tasks | | Pre-deployment comprehensive check | /audit | Full quality audit including security | | Simultaneous code quality improvement | /code-review | Two-stage review to prevent quality regressions | | Prevent recurring vulnerabilities | /guardrails | Strengthen security guards at generation stage |

---

Hook Integration

| Hook | Effect | |------|--------| | skill-router | Auto-detects /security-review keyword | | post-edit-analyzer | Auto-re-checks security patterns after edits | | git-commit-checker | Warns when high-risk vulnerabilities remain unresolved |

---

Last Updated: 2026-03-02 (v1.1.0 - Full rewrite: OWASP A01–A10 complete matrix, Web/API high-risk checks, triage, artifacts/flags, /audit contract added)

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: insightflo
• Source: insightflo/claude-impl-tools
• License: MIT

Install and usage instructions live in the source repository linked above.