Security & Compliance Hardening

Audits third-party dependencies for exploitable CVEs, abandonment, license exposure, and supply-chain hygiene, and delivers a ranked findings report with a remediation order. Use when someone asks "is this package safe to add", "audit our dependencies", "npm audit is screaming, what actually matters", "can we use this GPL library", or is preparing a security review or vendor questionnaire. Do NOT use for triaging vulnerabilities in first-party code or a full CVE queue - use vulnerability-triage instead; for reviewing the code you wrote for security flaws - use secure-code-review instead; for how secrets are stored and rotated - use secrets-hygiene instead; for assembling compliance evidence - use soc2-evidence-helper instead.

Guides detection, emergency rotation, and prevention of leaked secrets and credentials across source code, git history, CI pipelines, logs, and infrastructure config. Use when someone says "I think I committed an API key", "a secret leaked", "scan the repo for credentials", "how should we store secrets", or is setting up secrets management for an application, CI/CD, or Kubernetes. Do NOT use for detecting or redacting personal data like names, emails, or SSNs - use pii-scrubber instead; for routine non-secret environment configuration on Vercel, use vercel-env-management.

Maps engineering controls to SOC 2 Trust Service Criteria, builds a continuous evidence-collection plan with cadences per control family, and produces the control-to-evidence table auditors work from. Use when someone asks "what evidence do we need for SOC 2", "map our controls to the Trust Service Criteria", "how do we prepare for Type II fieldwork", "the auditor asked for access reviews", or is closing findings or standing up a compliance program. Do NOT use for building an incident postmortem - use postmortem-writer instead; do NOT use for finding and prioritizing actual vulnerabilities - use vulnerability-triage instead; this skill organizes proof that controls operate, it does not implement the controls.

Prioritizes vulnerability findings from scanners, pentest reports, and bug bounty submissions by real-world exploitability rather than raw CVSS, assigning internal severity tiers with fix SLAs. Use when someone asks "which of these CVEs do we fix first", "triage this scanner report", "is this CVSS 9.8 actually critical for us", or is facing a wall of security findings and needs an actionable queue. Do NOT use for enumerating threats in a design that has not shipped - use threat-model-stride instead; for an active exploitation incident in production, use sev-triage; for reviewing the code itself, use secure-code-review.

Reviews code for the security flaw classes that cause the most breaches - broken authorization and IDOR, injection, SSRF, mass assignment, and unsafe deserialization - and returns a short, focused findings list with concrete fixes. Use when someone asks "review this code for security issues", "is this endpoint safe", "check this PR for vulnerabilities", or is shipping auth logic, new API endpoints, file handling, or anything that touches untrusted input. Do NOT use for general code quality, style, or maintainability review - use code-review-checklist instead; for prioritizing findings a scanner already produced, use vulnerability-triage; for design-stage analysis before code exists, use threat-model-stride.

Reviews code for OWASP Top 10 vulnerabilities with concrete fix recommendations.

Detects and redacts personally identifiable information from text, logs, datasets, and LLM prompts using layered pattern, checksum, and NER detection, then picks the right redaction mode for each downstream use. Use when someone asks "scrub PII from these logs", "redact personal data before sending it to the LLM", "is this dataset safe to share", or is wiring up logging, analytics, or third-party exports that might carry user data. Do NOT use for leaked API keys, tokens, or credentials - use secrets-hygiene instead.