Security Verify

Security Verify — Verification Workflows

Run security verification checks: pattern scanning, OWASP compliance, and vulnerability assessment.

Usage

/security-verify              # Default: run scan mode
/security-verify scan [path]  # Pattern-based security scanning (SAST)
/security-verify dast <url>   # Dynamic testing against running app (DAST)
/security-verify owasp        # OWASP Top 10 compliance check
/security-verify assess       # Vulnerability CVSS scoring + remediation
/security-verify audit        # Adversarial logic-level code review (CWE + CVSS + exploit)
/security-verify full         # scan + audit combined (use for /health or manual deep check)

Mode: scan

Run pattern-based security scanning against the codebase.

What It Checks

1. Secret Detection — Hardcoded credentials, API keys, private keys
2. SQL Injection — String interpolation in queries, raw SQL
3. XSS — Disabled auto-escaping, innerHTML, unsafe template filters
4. Command Injection — Unsafe subprocess/exec patterns
5. Insecure Deserialization — Unsafe deserializers
6. Weak Cryptography — MD5, SHA1, weak random for security use
7. Multi-Tenant Violations — tenant_id from request, missing tenant filters
8. Cookie Issues — Missing __Host- prefix, missing samesite

Scan Execution

Run the scanner script against target path:

# Full scan — manual usage, scans entire directory
bash "$HOME/.claude/skills/security-verify/lib/scanner-runner.sh" "${TARGET_PATH:-.}"

# Staged-only scan — pre-commit context, scans only git-staged files
bash "$HOME/.claude/skills/security-verify/lib/scanner-runner.sh" --staged

Use --staged when invoked from /pre-commit to limit scope to the current commit's changes. Full-path scanning is for standalone audits.

Review findings, assess severity, and provide fix recommendations.

Dependency Audit

After pattern scan, check for known CVEs:

# Use filtered requirements file to audit only public packages.
if command -v uv &>/dev/null && ([ -f uv.lock ] || [ -f pyproject.toml ]); then
  if uv export --no-hashes --frozen > /tmp/raw-reqs.txt 2>/dev/null; then :; else
    uv run pip freeze > /tmp/raw-reqs.txt 2>/dev/null || true
  fi
  uv run --with pip-audit pip-audit -r /tmp/pip-audit-reqs.txt 2>/dev/null || true
elif command -v pip-audit &>/dev/null; then
  pip-audit --local 2>/dev/null || true
else
  echo "pip-audit not installed"
fi
npm audit --production 2>/dev/null || echo "No package.json"

Report Format

Generate a markdown report with severity counts, findings with file:line references, and fix recommendations.

Mode: dast

Dynamic Application Security Testing against a running application. Tests live HTTP endpoints rather than reading source files.

Prerequisites

• Application must be running and accessible at the provided URL
• curl (always available, zero extra deps)
• nuclei (optional, for deeper template-based scanning): brew install nuclei
• python3 (required if using --nuclei, for JSON parsing)

What It Checks

Tier 1 — curl-based (always runs):

Tier 2 — nuclei (when installed):

DAST Execution

# Tier 1 only (curl-based, zero deps)
bash "$HOME/.claude/skills/security-verify/lib/dast-runner.sh" "http://localhost:8000"

# Tier 1 + Tier 2 (requires nuclei installed)
bash "$HOME/.claude/skills/security-verify/lib/dast-runner.sh" "http://localhost:8000" --nuclei

# Custom per-check timeout (default: 5s)
bash "$HOME/.claude/skills/security-verify/lib/dast-runner.sh" "http://localhost:8000" --timeout 3

Report Format — Active vs Potential

Findings are labelled to distinguish confidence level:

• ACTIVE — Confirmed by server response. Remediate now. (e.g., server returned missing CSP header)
• POTENTIAL — Suspicious behavior requiring manual verification. (e.g., redirect parameter exists but may validate destinations)

Exit codes: 0 = no critical/high findings, 1 = critical/high found, 2 = URL unreachable.

DAST vs SAST

Mode: owasp

Systematic OWASP Top 10 2021 compliance verification.

Categories

Verification Process

For each category:

1. Run automated checks (grep patterns per category)
2. Review findings
3. Mark Pass/Partial/Fail with evidence
4. Generate compliance report

Mode: assess

Deep vulnerability analysis with CVSS scoring and remediation strategies.

Assessment Workflow

1. Classify vulnerability type (injection, auth, data exposure, XSS, etc.)
2. Evaluate exploitability (Easy/Medium/Hard based on attack vector, complexity, privileges)
3. Assess impact (Confidentiality/Integrity/Availability: None/Low/High)
4. Calculate CVSS v3.1 score using base metrics
5. Prioritize using risk matrix (severity x exploitability -> P0-P3)
6. Recommend remediation with code examples

CVSS Score Ranges

Priority SLAs

Mode: audit

Adversarial logic-level code review. Reads code deeply to find vulnerabilities that grep-based SAST misses — auth bypass, IDOR, race conditions, session fixation, missing ownership checks.

Run as a focused subagent (spawn fresh context to avoid polluting the main conversation with large finding sets). When invoked, spawn an Agent with subagent_type: general-purpose, model: sonnet, and pass the target scope.

Mindset

Assume the code is hostile until proven otherwise. Find vulnerabilities a real attacker would exploit. "If you can't write the exploit scenario in one sentence, downgrade severity."

• Injection: trace user-controlled input → all SQL sinks (raw text(), op.execute(), f-strings in queries). Alembic rule: each op.execute() must be a single statement — two statements separated by ; fail on asyncpg.
• Auth: check every route for Depends(get_current_user) or equivalent. Routes missing auth on sensitive operations (write, delete, admin functions) are CRITICAL.
• IDOR: for every endpoint accepting an object ID (company_id, person_id, job_id), verify ownership check: does the handler confirm the object belongs to the authenticated user/tenant?
• Race conditions: check background job handlers and Celery tasks for TOCTOU patterns on shared resources.

General checks (adapt to target):

• Sensitive data exposure: PII in logs, cleartext credentials in source, debug endpoints accessible in prod
• Input validation: Pydantic model field constraints present at API boundaries (length, range, format)
• CSRF: state-changing endpoints behind Traefik — session cookie SameSite set?
• Insecure deserialization: no yaml.load() without Loader=yaml.SafeLoader; no unsafe deserialization of untrusted binary data
• Security misconfiguration: debug mode off, ALLOWED_HOSTS not *, verbose error messages suppressed

Report Format

Each finding must include:

• ID: SEC-NNN (sequential)
• CWE: CWE-XXX — Name (e.g., CWE-89 — SQL Injection)
• Severity: CRITICAL / HIGH / MEDIUM / LOW with CVSS-ish reasoning
• Location: file.py:line
• Exploit scenario: one sentence describing the attack
• Fix: concrete code-level remediation

When to use

• Manual deep audit before major releases
• After /health security (scan passes but audit finds logic flaws)
• When security-sensitive PR touches auth, session, IDOR-prone endpoints

NOT for pre-commit — use scan there. audit takes minutes; scan takes seconds.

Mode: full

Runs scan + audit sequentially. Use for /health full or when you want complete security coverage in one command.

1. Run scan (SAST grep patterns + dependency audit)
2. Run audit (adversarial logic-level review)
3. Merge findings into unified report ordered by severity

Workflow Integration

Recommended security workflow:

1. Implement → /security [mode] — get implementation guidance
2. Scan → /security-verify scan — SAST: fast grep-based check (seconds, runs in pre-commit)
3. Audit → /security-verify audit — adversarial logic review (minutes, run manually or via /health)
4. Dynamic → /security-verify dast <url> — DAST: test running app (staging/local)
5. Comply → /security-verify owasp — verify OWASP Top 10 compliance
6. Assess → /security-verify assess — CVSS score and prioritize findings
7. Full → /security-verify full — scan + audit combined (use for /health full)

/security-verify scan is called by /pre-commit automatically. /security-verify dast is optional — use --dast <url> with /pre-commit when a local dev server is running. /security-verify audit and full are called by /health security and /health full.

Gotchas

• Bandit requires Python ≤3.13 — Python 3.14 removed .s/.n AST attributes; bandit ≤1.8.x crashes on every file and silently reports 0 findings. Use python3.13 -m bandit (bandit 1.9.4 installed there).
• scanner-runner.sh --staged requires bash 4+ (mapfile); macOS ships bash 3.2 — use full scan mode instead of --staged on macOS.
• False positives in projects/ (JSONL session transcripts), .archive/, and .venv/ — assess as FP, do not report as real issues.
• JS dependency audit gates on CRITICAL only (pnpm audit --audit-level=critical); HIGH vulns in transitive/dev deps (ReDoS in build tools, prototype pollution in bundlers) are noise, not runtime-exploitable — surface them informationally but do not block.
• Python pip-audit runs with no severity threshold (all vulns surfaced + gated) — different ecosystem from JS, more conservative CVE scoring, smaller dep trees.