security-audit

name	security-audit
description	Use when auditing code for security vulnerabilities, reviewing auth flows, checking OWASP Top 10 risks, validating secrets handling, or assessing dependency and agent-surface security.

Security Audit

Purpose

Find security risks with evidence, prioritize exploitability and impact, and recommend the smallest fix that closes the issue.

Announce: "I'm using the security-audit skill to check security risks."

Use directly for security work or through /sc-audit security for a broader audit. Audit mode is read-only. Caller boundary: inside /sc-audit or /sc-review, even explicit approval to fix requires a transition to /sc-debug, /sc-plan, /sc-work, or /sc-go; do not mutate inside the review route.

Modes

Mode	Trigger	Scope	Output
Pre-flight	During /sc-plan for auth, data, crypto, payments, uploads, webhooks, or external services	Proposed design	Security requirements and tests
Review	During code review	Changed files	Findings with file and line references
Full audit	/sc-audit security or explicit user request	Relevant codebase surface	Prioritized audit report
Incident response	Suspected secret or data exposure	Specific exposure path	Containment, rotation, and follow-up plan

Routing

Load only applicable branches:

• Routes, services, UI, storage, jobs, and integrations: OWASP
• Credential, token, key, log, history, or prompt exposure: secrets
• Dependency provenance, CVEs, lockfiles, or install behavior: supply chain
• Prompts, hooks, skills, workflows, MCP, plugins, or tools: agent surface
• Severity, finding structure, residual risk, and completion checks: reporting

Run threat-modeling first for new auth, PII, permission, payment, webhook, or upload features; use secure-code-patterns for implementation, data-privacy for PII, and compatibility-check for stack support. For compliance evidence, record control intent, evidence path, owner, date, and residual risk. Do not preload unrelated audit checklists.

Mandatory Gates

• Scope gate: Define trusted and untrusted surfaces, assets, actors, entry points, authorization boundaries, and the files or configurations actually checked.
• Finding gate: Every finding needs severity, file:line evidence, exploit or failure path, impact, minimal fix, and verification. Report no-finding checks separately from uninspected areas.
• Secret gate: Never print a discovered secret. Identify only the location and exposure channel; containment, revocation, or rotation requires appropriate authority, and history rewriting always requires explicit approval.
• STOP gate: Surface P0 active exposure, trivial exploit, data loss, auth bypass, or secret leakage immediately; do not bury it behind lower-severity review.
• Fix gate: Do not mark a finding fixed until the original exploit path is impossible and a regression check exists or is explicitly documented as manual.
• Evidence gate: Findings come first in severity order. Preserve command output safely, redact sensitive values, document important no-findings, and state residual risk, owner, and next review.

Related Skills

Use threat-modeling, secure-code-patterns, data-privacy, compatibility-check, code-review, and verification-before-completion for their respective branches and final completion gate.