Agent Skills: Security Verify — Verification Workflows

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):

| # | Category | What it checks | Severity | | --- | ---------------------- | --------------------------------------------------------------------------------------- | ------------- | | 1 | HTTP Security Headers | HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy | LOW–HIGH | | 2 | Cookie Security | Secure, HttpOnly, SameSite flags | MEDIUM–HIGH | | 3 | CORS | Wildcard origins, evil origin reflection | HIGH–CRITICAL | | 4 | TLS/SSL | Protocol version (≥TLS 1.2), cert expiry | MEDIUM–HIGH | | 5 | Information Disclosure | Server version header, X-Powered-By, exposed paths (/.env, /.git, /debug, /admin) | LOW–HIGH | | 6 | Open Redirects | Redirect parameter injection test | HIGH | | 7 | HTTP Methods | TRACE enabled, OPTIONS enumeration | LOW |

Tier 2 — nuclei (when installed):

| # | Category | What it checks | | --- | ------------ | ---------------------------------------------------------------- | | 8 | CVE patterns | Known vulnerability templates for http/, ssl/, misconfiguration/ | | 9 | Auth bypass | Default credentials, auth misconfiguration templates |

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

| | SAST (scan) | DAST (dast) | | ---------- | ------------------------- | ------------------------- | | Input | Source files | Running server | | Finds | Potential vulnerabilities | Active misconfigurations | | Deps | None (bash grep) | curl + optional nuclei | | When | Any time | App must be running | | Pre-commit | Yes (default) | Optional (--dast <url>) |

Mode: owasp

Systematic OWASP Top 10 2021 compliance verification.

Categories

| ID | Category | Key Checks | | --- | ------------------------- | ----------------------------------------------------- | | A01 | Broken Access Control | Authorization on every endpoint, no IDOR, CORS config | | A02 | Cryptographic Failures | TLS 1.2+, Argon2/bcrypt hashing, no weak algorithms | | A03 | Injection | Parameterized SQL, safe subprocess usage | | A04 | Insecure Design | Rate limiting, account lockout, threat model | | A05 | Security Misconfiguration | Debug off, security headers, no defaults | | A06 | Vulnerable Components | No critical CVEs, deps up to date | | A07 | Auth Failures | Strong passwords, session timeout, MFA | | A08 | Integrity Failures | Safe deserialization, yaml.safe_load | | A09 | Logging Failures | Auth events logged, no PII in logs | | A10 | SSRF | URL validation, private IPs blocked |

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

| Score | Severity | | -------- | -------- | | 0.0 | None | | 0.1-3.9 | Low | | 4.0-6.9 | Medium | | 7.0-8.9 | High | | 9.0-10.0 | Critical |

Priority SLAs

| Priority | SLA | Criteria | | -------- | -------- | ---------------------------- | | P0 | 24 hours | Critical+Easy or High+Easy | | P1 | 7 days | Critical+Hard or High+Medium | | P2 | 30 days | Medium or High+Hard | | P3 | 90 days | Low severity |

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.