Deep Security Audit

Deep Security Audit

A repeatable, multi-agent pipeline that finds real, exploitable security bugs by understanding code, not pattern-matching. It fans work out to scoped finder agents, then makes a second wave of agents try to refute each finding before it's reported — so what survives is high-signal.

Operating rules (non-negotiable)

1. READ-ONLY. Static analysis of source only. Never edit/commit/push. Never run an exploit against a live/hosted system. Local, self-owned, non-destructive PoCs only — and only if the user explicitly asks to verify one.
2. Understand, don't grep. grep is for locating the surface. Every finding must come from an agent that read the handler, its callers, its auth/middleware/validation, and traced reachability. No finding from a raw grep hit alone.
3. Prove the guard is ABSENT. A missing check is only a finding if you verified the framework's normal guard (nonce, capability, policy, permission_callback, auth middleware, prepare(), escaping, validation) is genuinely not there on that path. Frameworks have defaults — check them.
4. Honest CVSS, no inflation. Score CVSS 3.1 by real preconditions. If a BOLA needs an unguessable UUID → AC:H. If exploitation needs auth → PR:L/H. State the precondition. Downgrade the moment evidence contradicts the ceiling.
5. Empirically calibrate when possible. If a "read-back / exfil" claim can be safely checked locally and the data doesn't actually come back (lossy AI/serializer layer, blind SSRF), downgrade it — don't report the theoretical worst case as confirmed.
6. Local ≠ deployed. The checkout may lag or lead production. Flag that findings are "candidates to verify against the deployed branch," and diff against origin/the deploy branch when possible.
7. No false positives from non-runtime code. Ignore tests, stubs, fixtures, seeders, factories, *.min.js, vendor/, node_modules/, and env examples.

Phase 0 — Recon (do this yourself, inline, before fanning out)

1. Detect the framework(s). Look for signal files:
   • Laravel → artisan, composer.json (laravel/framework), routes/*.php, app/Http
   • WordPress plugin → a main *.php with Plugin Name: header, register_rest_route, add_action('wp_ajax_, $wpdb
   • Next.js → next.config.*, app/**/route.ts, pages/api/**, "use server"
   • Express/Node → express(), route files, app.get/post
   • Django → urls.py, views.py; Rails → config/routes.rb, app/controllers
2. Size it. Count source files (exclude vendor/node_modules/tests). This sets the finder count (small ~10, large ~15, huge → split by module).
3. Map the attack surface — enumerate the real entry points and sinks:
   • Routes/endpoints and the auth/middleware on each (this is the spine).
   • Auth/token/session logic; capability/permission/policy layer.
   • Sinks: SQL ($wpdb, DB::raw, ORM raw), HTTP-fetch of user URLs (SSRF), file ops (LFI/traversal/upload), deserialization, command exec, template/HTML output (XSS), redirects, secrets/config.
4. Write a short inventory (route→auth table, sink list) to the scratchpad — the finders use it as ground truth.

See references/frameworks.md for the per-framework surface map and the exact guards to check for each.

Phase 1 + 2 — Fan out finders → adversarially verify (one Workflow)

Author a run-specific Workflow (multi-agent) from the template in references/workflow-template.js. The template encodes the two-phase pipeline:

• Find: N scoped finder agents (one per attack-surface dimension). Each READS the code for its scope and returns structured findings (file:line, vulnerable code, concrete attack, honest CVSS + vector, confidence).
• Verify: every finding is handed to a fresh agent told to REFUTE it — open the exact file, read the guard chain + registration + reachability, and default to confirmed:false unless the code substantiates it. It re-scores CVSS honestly (downgrading for required privileges / non-default config / unguessable ids). Findings run through verify as soon as their dimension finishes (pipeline, no barrier).

Pick dimensions from references/frameworks.md for the detected framework. Scale the finder count to size. Filter to confirmed && exploitable && cvss >= threshold (default 5.0; the user may ask for higher/lower). Sort by adjusted CVSS.

Invoking this skill IS the user's opt-in to multi-agent orchestration — the Workflow call is expected.

Phase 3 — Dedupe, calibrate, report

1. Dedupe. Multiple finders re-find the same root cause (e.g. one missing ownership scope across many controllers). Collapse to unique issues; note the shared root cause and every affected location.
2. Calibrate honestly. Apply rules 4–6. If a claim's worst case is conditional (gadget chain, IMDSv1, an internal service that acts-on-request), say so and score the demonstrated impact, not the ceiling.
3. Write the report (markdown, to scratchpad or ~/Documents), grouped by severity, each finding: title · CVSS + vector · location · root cause (with code) · concrete attack · fix · status (verified-from-source / needs-live-confirm). Include an honest "not confirmed / nothing survived" section and a "verify against deployed" caveat. Lead with a "if you fix only 3 things" list.
4. Offer to (a) write fixes as diffs, (b) produce a responsible-disclosure writeup, or (c) re-verify top findings against the deployed branch.

Disclosure & safety posture

• Frame output as responsible disclosure from an authorized review.
• Redact any real tokens/secrets/UUIDs from the report.
• If asked to actively exploit a hosted/production/third-party system, or to extract live credentials to pivot, decline and explain: the finding is provable from source; live-fire against real infra is intrusion, not testing. Local, self-owned, non-destructive PoCs are fine when the user asks.
• Reserve the catastrophic labels (RCE, account-wide cloud takeover) for cases you can substantiate; prefer a calibrated medium over an inflated critical.