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 / PCI-DSS readiness gaps
  /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

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:

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:

Tailor to the specific app. A personal fitness tracker has different adversaries than a multi-tenant SaaS platform. Remove actors that don’t apply; add app-specific ones.

Data Flow Tracing (/oc-security data-flow)

Trace every sensitive data type from ingress to egress. Connective tissue between attack surface mapping and STRIDE — shows exactly where sensitive data is vulnerable.

Process:

1. Classify data types:

2. Trace each RESTRICTED and CONFIDENTIAL type through the system: ingress → validation → processing → storage → retrieval → egress. Flag every trust boundary crossing. See references/output-templates.md for the trace format.

3. Flag gaps: Data crossing trust boundaries without protection, classification mismatches (RESTRICTED data with INTERNAL-level controls), retention beyond need.

4. Third-party exposure check. For each external integration identified in the attack surface map, assess:

   • What data classification level is shared with the third party?
   • Does the integration use least-privilege (minimal scopes, data minimization)?
   • What’s the blast radius if the third party is compromised?
   • Is the integration authenticated with rotatable credentials (not hardcoded keys)?
   • Does the third party’s privacy/security posture match the data classification?

   This is not full vendor management — it’s a lightweight exposure check that feeds into STRIDE (Spoofing, Information Disclosure) and the OWASP supply-chain and integrity categories (A06/A08 in the 2021 numbering below).

Pillar 2: Compliance Mapping

OWASP Top 10 Checklist (/oc-security owasp)

For each OWASP category, assess the application’s posture. Use web search to confirm the current list (it updates every few years; a 2025 edition has superseded 2021). Fallback if search is unavailable — the 2021 edition, labelled as such in the report so nobody mistakes it for the current list:

A01: Broken Access Control · A02: Cryptographic Failures · A03: Injection · A04: Insecure Design · A05: Security Misconfiguration · A06: Vulnerable/Outdated Components · A07: Identification and Authentication Failures · A08: Software and Data Integrity Failures · A09: Security Logging and Monitoring Failures · A10: Server-Side Request Forgery (SSRF)

Status per category: ✅ PASS, ⚠️ PARTIAL, ❌ FAIL. See references/output-templates.md for the assessment format.

Framework Readiness (/oc-security readiness [framework])

Supported: SOC2, ISO27001, HIPAA, PCI-DSS. Generate a gap analysis of applicable controls vs. current state. See references/output-templates.md for format.

Important: This is readiness mapping, not certification. Always note that actual compliance requires formal assessment by qualified auditors.

Report Regeneration (/oc-security report)

Regenerates the posture report from the current checkpoint without re-running assessments. Requires a checkpoint with at least one completed pillar. If no checkpoint exists, redirects to /oc-security posture.

Pillar 3: Runtime Hardening

HTTP Security Headers (/oc-security headers)

Check the deployed application’s response headers. If a URL is available, fetch it (WebFetch, or curl -sI <url>). Otherwise, check the code for header-setting logic.

Score: X/8 headers configured correctly. Priority fix whichever has highest impact.

Note: X-XSS-Protection is intentionally excluded — it’s deprecated and can introduce vulnerabilities in older browsers. If present in a response, don’t flag as a finding; CSP supersedes it. If set, recommend X-XSS-Protection: 0 to disable legacy behavior.

TLS Configuration (/oc-security tls)

Check: TLS 1.2+ (1.3 preferred), certificate validity, cipher suite strength, HSTS preload status. For edge-proxied sites (Cloudflare, Vercel), TLS is automatic — focus on the platform-specific TLS settings instead.

DNS Security (/oc-security dns)

Check: DNSSEC, CAA records, SPF/DKIM/DMARC (if domain sends email), no dangling CNAMEs (subdomain takeover risk), no unintentional wildcard DNS.

Platform-Specific Hardening (/oc-security cloudflare)

Platform routing: The checks below use Cloudflare as the default (matching the opchain stack). For other platforms, adapt the equivalent controls:

Cloudflare-specific checks (when applicable):

If Cloudflare MCP is connected: Use it to read actual configuration. If not, check wrangler.toml and advise on dashboard settings.

Infrastructure Sweep (/oc-security infra)

Runs all runtime checks in sequence: headers → TLS → DNS → platform config → detection/response → cross-reference with threat model if one exists.

Pre-deployment projects: If no live URL exists, skip runtime checks (headers, TLS, DNS) and instead audit the code that sets these values — middleware, response headers in source, wrangler.toml/vercel.json config. Flag missing header-setting code as findings rather than testing live responses. Resume runtime checks after first deployment.

Detection & Response Readiness

Every hardening sweep includes detection/response checks. Prevention fails eventually (Principle 6: Assume Breach).

Proportional thresholds:

Posture Assessment (/oc-security posture)

The full-stack assessment. Runs all three pillars and produces an executive report.

Step 0: Scope & Classify

Before running checks, determine assessment depth. Ask the user (AskUserQuestion when available, otherwise in chat):

These determine the assessment tier:

Auto-detect from checkpoints when possible; confirm with user. Don’t run Comprehensive on a personal hobby app (Principle 7).

Tier scope is advisory for /oc-security posture only. Individual commands (/oc-security owasp, /oc-security headers, etc.) always run at full depth regardless of tier — if the user explicitly asks, deliver.

Monorepo scoping: For multi-app repos (like acme-core), assess per-app — each app has its own data sensitivity, attack surface, and tier. Shared infrastructure (single Cloudflare account, shared D1 instance, common auth) gets assessed once and cross-referenced by each app’s report. Write one checkpoint per app, not one per repo: treat each app directory as the project-dir, so each lands at <app-dir>/.checkpoints/oc-security-auditor.checkpoint.json.

Process

1. Gather context. Read checkpoints: oc-reverse-spec, oc-app-architect, oc-code-auditor, oc-deploy-ops — the protocol-public fields only (header, progress, progress_summary, context_primer, blockers, eval_scores), never their skill_state.

2. Ensure code-level coverage. If no oc-code-auditor checkpoint exists, invoke /oc-audit security first. Architecture-level assessment without code-level findings is incomplete.

3. Run Pillar 1: Threat model (STRIDE + attack surface + adversaries + data flow).

4. Run Pillar 2: OWASP Top 10 compliance. Add framework readiness for Comprehensive tier.

5. Run Pillar 3: Runtime hardening sweep including detection/response.

6. Synthesize. Cross-reference: do oc-code-auditor findings map to STRIDE categories? (Its checkpoint carries only grade and counts; individual findings come from its audit report in this session or its HIGH+ PM sub-tickets.) Do hardening gaps align with attack surface exposure? Flag anything in threat model not covered by code or infra controls.

7. Produce the Posture Report. See references/output-templates.md for format.

Prioritization (/oc-security prioritize)

Takes all findings across pillars and produces a risk × effort matrix:

                 │ Small Effort │ Medium Effort │ Large Effort
─────────────────┼──────────────┼───────────────┼─────────────
CRITICAL Risk    │ DO NOW       │ DO NOW        │ PLAN NOW
HIGH Risk        │ DO NOW       │ PLAN NEXT     │ PLAN NEXT
MEDIUM Risk      │ QUICK WIN    │ BACKLOG       │ BACKLOG
LOW Risk         │ QUICK WIN    │ ACCEPT        │ ACCEPT

Output: Findings sorted into buckets with specific next actions.

Posture Comparison (/oc-security compare)

Compares two posture snapshots to track improvement. The checkpoint is a single file that each assessment overwrites, so a “before” snapshot is that tracked file at an earlier revision (git show <rev>:.checkpoints/oc-security-auditor.checkpoint.json) or a copy archived under .checkpoints/history/. Input: two revisions, dates, or checkpoint paths. If one argument, compares it against the current checkpoint. Diffs finding counts, OWASP score, header score. Highlights regressions prominently. See references/output-templates.md for format.

Checkpoint Integration

The shared checkpoint schema, write rules and resume protocol live in references/checkpoint-protocol.md, bundled with this skill. This section adds only what is specific to oc-security-auditor.

Location

{project-dir}/.checkpoints/oc-security-auditor.checkpoint.json

When to Write

skill_state

{
  "scope": "posture",                 // posture | threat-model | compliance | hardening
  "tier": "standard",
  "pillar_status": {
    "threat_model": "complete",
    "compliance": "complete",
    "hardening": "in_progress"
  },
  "findings_total": 14,
  "findings_by_risk": { "CRITICAL": 0, "HIGH": 2, "MEDIUM": 8, "LOW": 4 },
  "owasp_score": "7/10",
  "header_score": "5/8",
  "detection_response_score": "3/6",
  "detection_response_applicable": 6,
  "remediation_plan_generated": true,
  "code_auditor_checkpoint_read": true
}

Cross-Skill Reads

Remediation handoff (v1.9): when an assessment produces actionable findings, chain to oc-security-hardening — /oc-harden fix per finding, or /oc-harden baseline for a fresh project — then re-assess the touched pillar (/oc-security posture) and run /oc-security compare to confirm the score moved (compare diffs snapshots; it never re-assesses on its own). This skill assesses; it does not apply fixes.

PM-Tool MCP Integration (v1.2+)

Security findings have higher impact than code findings: they often require coordinated remediation across teams + a paper trail for audit. v1.2 routes /oc-secaudit output through the PM tool with slightly different rules from oc-code-auditor. See oc-integrations-engineer for the canonical PM-MCP patterns.

Posture summary on the linked ticket

After every /oc-secaudit run, post a structured summary on the linked PM ticket (if any):

Security audit: Posture grade {A-F}.
STRIDE findings: {C N, H N, M N, L N}
OWASP Top 10: {N FAIL, N PARTIAL, N PASS}
Top three (by exploitability × impact):
  1. {component} — {one-line finding}
  ...
Compliance lens: {SOC2 / ISO27001 / HIPAA / PCI-DSS mapping summary}
Counts + tier: .checkpoints/oc-security-auditor.checkpoint.json

CRITICAL findings as incident tickets

CRITICAL findings get the incident issue-type from .opchain/pm.yaml, not bug:

• priority: highest tier.
• labels: security, incident, severity:CRITICAL, compliance:<framework-if-relevant>.
• parent: the source PR ticket if invoked from one; otherwise unparented.
• assignee: unassigned, unless remediation_owners.security is set in .opchain/pm.yaml (an optional key — see oc-integrations-engineer’s pm.yaml example).
• body: full finding + threat-model reference + suggested remediation + compliance-impact statement.

Why incident-typed: a CRITICAL security finding is treated as an active operational concern, not a backlog bug. Incident-typed tickets in most PM tools route to on-call workflows + status pages.

HIGH findings as security sub-tickets

HIGH findings get filed as bug-typed sub-tickets parent-linked to the source PR ticket, same shape as oc-code-auditor’s HIGH+ pattern. Labels include security, severity:HIGH, and the relevant OWASP category.

Compliance crosswalk artifacts

In regulated runs (the readiness frameworks above; CMMC or FedRAMP only when the user supplies that control catalogue) the crosswalk artifact (mapping findings → compliance controls) is also attached to the ticket as a comment + uploaded as a file attachment if the PM tool supports it. The crosswalk is the auditor-facing artefact; the PM ticket is the engineer-facing surface.

Re-scan hygiene

/oc-secaudit re-runs check existing security tickets. A finding that no longer reproduces gets a oc-security-auditor verified clean in {sha} comment + transition to done. Regressions reopen the same ticket rather than create duplicates.

Cross-domain + regulated environments

In environments with the broker / redactor / cross-domain rules described in oc-integrations-engineer/references/pm-mcp-protocol.md § Compliance posture, the oc-security-auditor’s PM-MCP writes pass through the same broker as every other tool call — same audit log, same scope rules. The Security Lead role typically holds elevated PM-MCP scope by design.

Failure modes

• No linked ticket + CRITICAL finding → still file the incident ticket unparented; the gravity warrants a PM record even without context linkage.
• MCP unavailable → log to checkpoint as deferred; never block the audit on PM availability.
• BAA / DPA missing on the configured PM provider → refuse to write the body of compliance findings; only post the grade + count. No config records BAA/DPA status, so ask the user once and record the answer in skill_state.

Principles

1. Architecture before code. A perfectly secure function in a badly designed system is still insecure. Start with the threat model.
2. Risk-based prioritization. Not every finding needs a fix. Accept LOW risks with eyes open rather than creating an infinite backlog.
3. Concrete remediation. “Implement proper access control” is useless. “Add requireAuth() middleware to /api/admin/* routes” is actionable.
4. Don’t duplicate oc-code-auditor. Code bugs are oc-code-auditor’s job. Cross-reference; don’t re-scan.
5. Compliance ≠ security. Passing a checklist doesn’t mean secure. The threat model is the real assessment; compliance is the paper trail.
6. Assume breach. Include detection and containment, not just prevention.
7. Proportional response. Match security investment to data sensitivity and exposure. A hobby app doesn’t need SOC2.

Candidate-bound deployment handoff

After completing the existing verification criteria, obtain the source identity with node scripts/lib/release-evidence.mjs --print-candidate --json. Publish a versioned verification.verdict entry in this skill’s checkpoint handoffs, using that exact candidate_identity object. This identity excludes checkpoint evidence from the source projection; it does not attest built bytes or ignored environment configuration. Do not manufacture PASS from a prior summary. Missing criteria produce FAIL or INCOMPLETE.

Required fields: a unique handoff id, contract_version: "1.0", type: "verification.verdict", ISO created_at and actual verified_at, producer: { "skill": "oc-security-auditor", "run_id": "<actual-run-id>" }, the printed candidate_identity as candidate, and payload: { "verdict": "PASS|FAIL|INCOMPLETE", "policy": "pre-deploy-security-posture-v1" }. Replace the verdict placeholder with the actual result. Preserve prior run history and write through the checkpoint protocol. If source content changes before evidence is committed, recompute the identity and re-run affected verification before producing a new handoff.

The deployment wrapper consumes this required handoff before building or deploying and blocks if it is missing, invalid, stale, or non-PASS. Executable verification is a separate A receipt, produced in the current checkout; this checkpoint is not a substitute.