oc-security-auditor

# Security Auditor

**On first invocation, read `references/orchestrator.md` and follow its welcome protocol.**

Practice-level security assessment that operates above oc-code-auditor. Where oc-code-auditor
greps for SQL injection and hardcoded secrets, oc-security-auditor asks: *What's the threat
model? Who are the adversaries? What's exposed? Is the infrastructure hardened? Are we
compliant?*

Three pillars: **Threat Modeling**, **Compliance Mapping**, **Runtime Hardening**.

For all output formats and report templates, read `references/output-templates.md`.

## /oc-security — Command Reference

```
SECURITY AUDITOR COMMANDS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  THREAT MODELING
  /oc-security threat-model       Full STRIDE analysis of the application
  /oc-security attack-surface     Map all entry points, data flows, trust boundaries
  /oc-security adversaries        Profile likely threat actors and their capabilities
  /oc-security data-flow          Trace sensitive data from ingress to storage to egress

  COMPLIANCE
  /oc-security owasp              OWASP Top 10 compliance checklist (current year)
  /oc-security posture            Full posture assessment (all three pillars)
  /oc-security readiness [framework]  SOC2 / ISO27001 / HIPAA readiness gap analysis
  /oc-security report             Regenerate posture report from last checkpoint

  RUNTIME HARDENING
  /oc-security headers            Audit HTTP security headers (CSP, HSTS, X-Frame, etc.)
  /oc-security tls                TLS/SSL configuration check
  /oc-security dns                DNS security (DNSSEC, CAA, SPF/DKIM/DMARC)
  /oc-security cloudflare         Cloudflare-specific: WAF, Bot Management, Page Rules
  /oc-security infra              Full infrastructure hardening sweep

  UTILITIES
  /oc-security prioritize         Rank all findings by risk × effort matrix
  /oc-security compare [before] [after]  Compare two posture snapshots
  /checkpoint                  Show checkpoint status

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  Type any command to begin. /oc-security to see this again.
```

---

## Relationship to oc-code-auditor

| Layer | Owner | Examples |
|---|---|---|
| **Code-level** | oc-code-auditor | SQLi, XSS, hardcoded secrets, auth middleware, dep vulns |
| **Architecture-level** | oc-security-auditor | Threat models, trust boundaries, data flow, attack surface |
| **Compliance-level** | oc-security-auditor | OWASP Top 10 mapping, SOC2 gap analysis, policy checklists |
| **Infra/runtime-level** | oc-security-auditor | CSP headers, TLS config, DNS security, WAF rules |

**Chaining rules:**
- After `/oc-audit security` (oc-code-auditor) → invoke oc-security-auditor for architecture + infra layers
- During `/oc-security posture` step 2 → check if oc-code-auditor checkpoint exists. If not,
  invoke `/oc-audit security` before proceeding. Threat modeling without code-level findings
  is incomplete.
- If threat model reveals code-level risks not in oc-code-auditor's findings → invoke
  `/oc-audit security` targeted at the specific area

---

## Pillar 1: Threat Modeling

### STRIDE Analysis (`/oc-security threat-model`)

For each component, evaluate all six STRIDE categories:

| Category | Question | Example Finding |
|---|---|---|
| **S**poofing | Can an attacker impersonate a user or system? | API-to-API calls use shared secret with no rotation |
| **T**ampering | Can data be modified in transit or at rest? | No integrity checks on database writes |
| **R**epudiation | Can a user deny performing an action? | No audit log on data mutation endpoints |
| **I**nformation Disclosure | Can sensitive data leak? | Error responses include stack traces; keys enumerable |
| **D**enial of Service | Can the service be made unavailable? | No rate limiting on public endpoints |
| **E**levation of Privilege | Can a user gain unauthorized access? | User ID from client header, not verified session |

### Process

1. **Inventory components.** Read oc-reverse-spec or oc-app-architect checkpoint for architecture.
   If none exists, scan the codebase for: routes, databases, external APIs, auth flows,
   static assets, scheduled tasks, WebSocket connections.

2. **Draw trust boundaries.** Identify where trust level changes. Common patterns:
   - Public internet → edge/CDN (Cloudflare, Vercel, CloudFront)
   - Edge → application server (Worker, Lambda, container)
   - Application → data store (D1, Postgres, DynamoDB, KV)
   - Application → external APIs (third-party services)
   - Client browser → application API
   - Admin interface → application API

3. **Run STRIDE per boundary crossing.** Each data flow that crosses a trust boundary
   gets all six STRIDE checks.

4. **Classify findings** using the risk matrix:

```
RISK = LIKELIHOOD × IMPACT

Likelihood:  HIGH (script kiddie, public, no auth) · MEDIUM (insider/chained) · LOW (physical/privileged)
Impact:      HIGH (breach, full compromise) · MEDIUM (partial exposure, degradation) · LOW (info leak, cosmetic)

           │ Low Impact │ Med Impact │ High Impact
───────────┼────────────┼────────────┼────────────
High Likl. │   MEDIUM   │    HIGH    │  CRITICAL
Med Likl.  │    LOW     │   MEDIUM   │    HIGH
Low Likl.  │    LOW     │    LOW     │   MEDIUM
```

### Attack Surface Mapping (`/oc-security attack-surface`)

Enumerate every entry point: HTTP endpoints, data stores, external integrations, static
assets, trust boundaries. See `references/output-templates.md` for the table format.

### Adversary Profiling (`/oc-security adversaries`)

Define realistic threat actors for the application. Generic starting set:

| Actor | Motivation | Capability | Relevant STRIDE |
|---|---|---|---|
| Opportunist | Curiosity, low-effort gain | Automated scanners, public exploits | S, I, D |
| Disgruntled user | Revenge, disruption | Authenticated access, social engineering | T, R, E |
| Data harvester | PII/PHI for resale | Scripted enumeration, credential stuffing | S, I |
| Competitive actor