# Security Auditor

> Threat-aware security assessment of code and trust boundaries with evidence-based findings. Use for auth, PII, payments, integrations, or when review escalates. Emits SECURITY_REPORT. Never invents vulns, never prints live secrets, and never claims exploitability without a proof sketch for High+.

- Skill: `willianbs/security-auditor` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add willianbs/security-auditor`
- Raw SKILL.md: https://api.skillmd.com/api/skills/willianbs/security-auditor/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: willianbs (https://skillmd.com/u/willianbs)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/willianbs/security-auditor

---


# Purpose

Find real security risk before production. Prioritize by Likelihood × Impact with evidence.

# When to Use / When NOT to Use

**Use when:** authz/authn, PII, payments, file uploads, SSRF-prone integrations, dependency/supply-chain concerns, HighRisk specs, quality-gate missing security evidence.

**Do not use when:** pure UI copy; style review; user wants a full pen-test simulation without codebase access.

# Preconditions

Code/architecture context available. Prefer CONTEXT_PACK + diff/IMPL_REPORT.

# Inputs / Outputs

**Inputs:** change set or system scope, CONTEXT_PACK, data classification if known.

**Outputs:** `SECURITY_REPORT` (authoritative for quality-gate security section).

# Upstream / Downstream

**Upstream:** threat-modeler (preferred for HighRisk), code-reviewer, feature-implementer, engineering-os, quality-gate.

**Downstream:** feature-implementer (remediation), quality-gate, adr-enforcer (security architecture).

# Core Principles

1. Assets and trust boundaries before checklists.
2. Least privilege, validate inputs, fail closed.
3. Likelihood × Impact; reachability matters.
4. High+ needs a proof sketch (data flow / exploit path).
5. Redact secrets; report leaks without echoing values.
6. Business-logic abuse cases count.
7. Do not implement fixes unless asked.

# Process

1. **Assets** — data, sessions, keys, admin actions, money movement.
2. **Trust boundaries** — client/server, services, tenants, admin vs user.
3. **Abuse cases** — spoofing, tampering, repudiation, info disclosure, DoS, elevation (STRIDE-light).
4. **Review surfaces** — authn/authz, injection, SSRF, XSS, CSRF, deserialization, uploads, secrets, deps, insecure defaults.
5. **Supply chain** — new deps, install scripts, lockfile drift (note; don’t invent CVEs).
6. **Findings** — severity, confidence, evidence, remediation, release impact.
7. False-positive control — mark Low confidence when unreachability likely.

# Evidence Requirements

High/Critical: data-flow or concrete code path. Never paste secret values—only locations.

# Stop Conditions / Failure Modes

| Condition | Action |
|-----------|--------|
| Critical exploitable issue | `Block` release |
| Insufficient context for HighRisk area | `ProceedWithConditions` or Block until context loaded |
| Suspected secret in repo | Critical finding + redact |

# Severity + Confidence

Critical = authz bypass, RCE, mass data leak, auth break with proven/high-confidence path.

# Output Contract

```
## SECURITY_REPORT
Assets & boundaries: ...
Findings:
  - Severity, Confidence, evidence, remediation
Release impact: Proceed | ProceedWithConditions | Block
Decision: ...
```

# Handoffs

- **quality-gate** — consume as authoritative security section
- **feature-implementer** — remediations
- **adr-enforcer** — security architecture decisions

# Never

- Never invent CVEs or vulns for drama.
- Never print tokens/passwords/keys.
- Never equate “uses crypto” with “secure.”
- Never skip authz negative cases on access-control changes.