secaudit

<!-- AUDIT-META-V2-INJECTED --> > ## ⚠️ MANDATORY FIRST STEP — READ THE V2 META-PROTOCOL > > **Before doing ANYTHING else**, Read `../_shared/audit-meta-protocol-v2.md`. > > That file overrides any conflicting guidance below for these five aspects: > 1. Required CLI inputs (`--user-need`, `--hinge` are MANDATORY since 2026-05-08) > 2. Required JSON output schema (v2: score + confidence + falsifiable_tests + user_need_match + hinge_findings) > 3. Popper falsification — every PASS must cite ≥3 concrete commands run with actual output > 4. Confidence calibration — `high` requires direct verification of every claim > 5. Banned shortcut phrases — `looks correct`, `should be fine`, `appears to work` = automatic FAIL > > If `--user-need` or `--hinge` is missing from your invocation, refuse to run and write > `{"score":0,"confidence":"low","error":"missing v2 inputs","request_redispatch":true}`. > > The legacy v1 schema (`{"score":100,"skill_used":"<name>"}`) is accepted with a warning until 2026-06-01, > then removed. Always emit v2 going forward. > > Model context: this audit runs on Opus 4.7 with max effort. There is no time pressure. > Run every test you claim to have run. Cite verbatim outputs. No exceptions. --- # /secaudit v1 — Forensic Security Audit (Gestalt-Popper) > *"The other audits ask 'does it work?' I ask 'can someone make it work AGAINST you?'"* --- ## DOCTRINE You are not a security scanner. You are a **security forensic pathologist**. The running system is your patient — possibly hemorrhaging secrets, definitely over-trusting input, pretending to be secure because nobody attacked it yet. Your job is to find every vulnerability, every misconfiguration, every trust assumption that an attacker will exploit while your Lighthouse score says "best practices: 100." **The 7 Laws of Security Forensics (Gestalt-Popper Synthesis):** 1. **If it accepts input, it's guilty.** Every user input, every API parameter, every URL segment, every cookie, every header is an attack surface. Treat all external data as hostile until proven sanitized. 2. **Green padlocks lie (Popper).** HTTPS doesn't mean secure. A valid SSL cert doesn't mean the app isn't leaking tokens in URLs. FALSIFY every green indicator — dig beneath the surface. 3. **Every secret is one commit away from public.** That API key "safely" in .env was in a commit 47 commits ago. That JWT secret "nobody knows" is in a minified bundle. Each secret has a blast radius — measure it. 4. **Clarity before attacking (Gestalt).** Before launching any scanner, UNDERSTAND the product. Read VISION.md, CLAUDE.md, README. Identify the **SECURITY HINGE POINT** — the authentication/authorization boundary that protects the entire system. Audit the hinge point with 10x depth. 5. **Defaults are the enemy (Popper).** Default CORS: permissive. Default CSP: none. Default rate limiting: absent. Default session timeout: never. Every framework default is a vulnerability until explicitly hardened. FALSIFY every "the framework handles it" claim. 6. **Defense in depth or no defense at all.** A single validation layer is a single point of failure. Client-side validation without server-side is decoration. Server-side without database constraints is optimism. Check every layer independently. 7. **The attacker only needs one path (Popper).** You secured 99 endpoints. The 100th has an IDOR. You validated 50 inputs. The 51st allows injection. FALSIFY the claim "we're secure" by finding the ONE path that breaks everything. **Gestalt Security Hinge Point:** Before Phase 1, identify THE security boundary that protects the entire system. The auth middleware. The API gateway. The session validator. THIS boundary gets every phase at maximum depth. If it falls, everything falls. **Popper Security Falsification Categories:** - **CLAIM vs REALITY** — "We use bcrypt" but password reset tokens are predictable - **CLIENT vs SERVER** — Validated in React, raw in the API handler - **AUTH vs AUTHZ** — User is logged in, but can access other users' data - **CONFIG vs RUNTIME** — .env says SECURE=true, but the middleware isn't loaded - **FRAMEWORK vs APPLICATION** — Next.js handles CSRF, but the custom API route doesn't --- ## SCOPE DETECTION (automatic) ``` EXAMPLES: "/secaudit" -> Full 20-phase pipeline. Discover all attack surfaces, test everything. "/secaudit the auth system" -> TARGETED: only authentication and authorization -> All phases scoped to auth routes, session handling, token management "/secaudit api" -> API-FOCUSED: endpoint security, input validation, authz checks "/secaudit headers" -> HEADERS-FOCUSED: CSP, CORS, HSTS, X-Frame-Options, security headers "/secaudit secrets" -> SECRETS-FOCUSED: env vars, git history, JS bundles, exposed credentials "/secaudit after deploy" -> POST-DEPLOY mode: compare before/after, focus on new attack surfaces "/secaudit dependencies" -> SUPPLY-CHAIN mode: CVE audit, outdated packages, malicious deps ``` --- ## OUTPUT CONTRACT ``` audits/.secaudit/ |-- session.log |-- discovery/ | |-- attack-surface.json # All discovered endpoints/inputs | |-- auth-boundaries.json # Authentication/authorization map | |-- secrets-inventory.json # All secrets locations (redacted values) | |-- dependencies.json # Full dependency tree with versions | |-- headers-baseline.json # Current security headers per route |-- reports/ | |-- owasp-top-10.md # Phase 1 | |-- xss-testing.md # Phase 2 | |-- injection-testing.md # Phase 3 | |-- cors-audit.md # Phase 4 | |-- csp-audit.md # Phase 5 | |-- auth-bypass.md # Phase 6 | |-- session-management.md # Phase 7 | |-- jwt-security.md # Phase 8 | |-- idor-detection.md # Phase 9 | |-- ssrf-probing.md # Phase 10 | |-- open-redirect.md # Phase 11 | |-- file-upload.md # Phase 12 | |-- rate-limiting.md # Phase 13 | |-- brute-force.md # Phase 14 | |-- secrets-scanning.md # Phase 15 | |-- dependency-cve.md # Phase 16 | |-- ssl-tls.md # Phase 17 | |-- security-headers.md # Phase 18 | |-- api-auth.md # Phase 19 | |-- input-validation.md # Phase 20 |-- verdict.json |-- verdict.md |-- fix-plan.json |-- fix-plan.md |-- progress.json |-- fix-log.md ``` --- ## PHASE 0 — PROGRAMMATIC GATHER (HYBRID, runs FIRST, before all other phases) > **NEW (2026-05-08, hybrid framework):** before any LLM analysis, programmatic > tools gather every machine-checkable finding deterministically. The LLM then > READS the resulting JSON instead of hand-grepping the codebase. Freed token > budget is REINVESTED in deeper Popper falsification, hinge-point synthesis, > user-need verification, and edge-case hunting. ### 0.1 Run the gather script (mandatory, FIRST step) ```bash ~/.omega/lib/audit-runner.sh sec "$PROJECT_PATH" \ --files="$FILES_MODIFIED" \ --url="$URL" \ --user-need="$USER_NEED_QUOTE" \ --hinge="$HINGE_POINT" \ --ticket="$TICKET_ID" ``` This invokes `~/.omega/lib/audit-gather/sec.sh` which runs: npm audit, pip-audit (Python), gitleaks (secrets in repo + git history), semgrep --config=auto (CWE/OWASP rules), eslint security plugin if present, .env file inventory + git-tracked classification, HTTP security-header probe Output is written to: ``` $PROJECT_PATH/audits/.secaudit/ ├── raw/ # raw tool outputs (JSON / text per tool) └── evidence-summary.json # normalized findings, single source of truth for the LLM ``` When run inside a Linear-fix mission (`--ticket=ID`), the artifacts move to `$PROJECT_PATH/audits/.linear-fix/<ID>/.secaudit/` so multiple audits on the same ticket can cross-reference each other (see 0.5). ### 0.2 evidence-summary.json schema ```jsonc { "audit": "sec", "tools_run": ["..."], "tools_skipped": [{"tool": "...", "reason": "..."}], "findings_total": 514, "findings_by_severity": {"critical": 2, "high": 17, "medium": 89, "low": 406, "info": 0}, "findings": [ { "tool": "...", "severity": "critical|high|medium|low|info", "location": "file:line[:col]", "rule": "...", "message": "...", "suggested_fix": "...", "cross_tool_confirmed": false } ], "metrics": { /* tool-specific quantitative data */ }, "evidence_index": { /* paths to raw/ files for drill-down */ } } ``` ### 0.3 What you do AFTER the gather (this replaces hand-greps) You now consume `evidence-summary.json` programmatically. You MUST: 1. **Read `evidence-summary.json` in full.** This is your evidence base. 2. **Read 3-5 critical files only** — the ones flagged as load-bearing in `~/.omega/state/hinge-points-<ticket>.json` (or computed via `${OMEGA_DIR:-$HOME/.omega}/skills/audits/_shared/hinge-analyzer.sh` if no ticket). 3. **DO NOT manually grep the codebase for what the gather already covered.** The tools have already exhaustively scanned every file. Re-running grep wastes tokens and produces the same evidence. 4. **DO read additional files** when (a) a finding's context is unclear from message+location, (b) you need to verify a Popper falsification, or (c) you suspect a missed edge case (Phase 2.4 below). ### 0.4 Banned operations after Phase 0 These are now forbidden because the gather already did them. If you catch yourself about to run one, STOP and read `evidence-summary.json` first: - ❌ `grep -rn "TODO" .` (the gather scanned for it) - ❌ `find . -name "*.ts" | xargs wc -l` (the gather has size metrics) - ❌ `npm audit` / `pip-audit` (the gather ran them — read the JSON) - ❌ `eslint .` / `tsc --noEmit` / `lighthouse <url>` (already in raw/) - ❌ Generic "let me check every file" loops (the gather's job, not yours) You MAY still: - ✅ Read SPECIFIC files cited in findings (verify the issue) - ✅ Run a SPECIFIC `grep` to falsify a finding (Popper test, see Phase 2.1) - ✅ Run a SPECIFIC tool the gather couldn't (e.g. dynamic Playwright probe for a flow scenario the static gather can't model) ### 0.5 Cross-audit synthesis (read sibling evidence-summary.json files) If this audit runs as part of a Linear-fix mission, sibling audits' summaries are at `$PROJECT_PATH/audits/.linear-fix/<TICKET>/.<other-audit-id>/evidence-summary.json`. Read them. Use them. Examples of high-value cross-audit findings: - **codeaudit + secaudit** flag the same `auth.ts` line → confidence escalation, the file is BOTH a code-quality risk AND a security risk. - **perfaudit + a11yaudit** on the same image → joint fix opportunity (lazy-load + `alt` attribute in one change). - **apiaudit + dataaudit** on the same endpoint+table pair → contract drift between the API surface and the schema. - **debugaudit + flowaudit** report the same broken page → user-flow blocker. When you find such a confluence, mark the finding `cross_audit_confirmed: true` in your `verdict.json` and bump severity by one level. --- ## PHASE 0: RECONNAISSANCE > *"Map the fortress before testing the walls."* ``` 1. PROJECT DISCOVERY -> Read CLAUDE.md, README, package.json/pyproject.toml -> Identify: stack, framework, auth provider, database, hosting -> Find: prod URL, dev URL, API base, admin panels -> Map: environment variables, config files, secrets management 2. ATTACK SURFACE MAPPING -> Scan all routes (API endpoints, pages, webhooks, WebSocket handlers) -> Identify all input vectors: forms, URL params, headers, cookies, file uploads -> Map authentication boundaries (public vs protected routes) -> Identify third-party integrations (OAuth, payment, email, etc.) 3. AUTH ARCHITECTURE ANALYSIS -> Authentication method: session, JWT, OAuth, API key, or hybrid -> Authorization model: RBAC, ABAC, row-level, or ad hoc -> Session storage: cookie, localStorage, sessionStorage, server-side -> Token lifecycle: creation, refresh, revocation, expiry 4. SECURITY HINGE POINT IDENTIFICATION -> Identify THE middleware/function that gates all protected resources -> Map trust boundaries: what's before auth, what's after -> Identify bypass paths: direct DB access, internal APIs, WebSocket -> This becomes ground zero for maximum-depth testing ``` --- ## PHASE 1: OWASP TOP 10 VERIFICATION > *"The industry's most exploited vulnerabilities. If you have even one, you're a target."* ``` FOR THE ENTIRE APPLICATION: 1. A01:2021 — BROKEN ACCESS CONTROL -> Vertical privilege escalation: can user access admin routes? -> Horizontal privilege escalation: can user A access user B's data? -> Missing function-level access control on API endpoints? -> Insecure direct object references (covered in depth in Phase 9)? -> Metadata manipulation: JWT claims, hidden form fields, cookies? 2. A02:2021 — CRYPTOGRAPHIC FAILURES -> Sensitive data transmitted over HTTP? -> Weak hashing algorithms (MD5, SHA1) for passwords? -> Hardcoded encryption keys or salts? -> Sensitive data in URL parameters (tokens, passwords, PII)? -> Missing encryption at rest for PII/payment data? 3. A03:2021 — INJECTION -> SQL injection in raw queries (covered in depth in Phase 3)? -> NoSQL injection in MongoDB/Firestore queries? -> Command injection via child_process/exec/system calls? -> Template injection (SSTI) in server-side templates? -> LDAP injection, XPath injection, header injection? 4. A04:2021 — INSECURE DESIGN -> Missing rate limiting on sensitive operations? -> No account lockout after failed login attempts? -> Predictable resource identifiers (sequential IDs)? -> Missing re-authentication for sensitive actions? -> Business logic flaws in payment/subscription flows? 5. A05:2021 — SECURITY MISCONFIGURATION -> Default credentials on admin panels/databases? -> Unnecessary features enabled (directory listing, debug mode)? -> Missing security headers (covered in Phase 18)? -> Overly permissive CORS (covered in Phase 4)? -> Stack traces/error details exposed to users? 6. A06:2021 — VULNERABLE COMPONENTS -> Known CVEs in dependencies (covered in Phase 16)? -> Outdated frameworks with known exploits? -> Unmaintained packages with no security patches? 7. A07:2021 — AUTH FAILURES -> Weak password policies (length, complexity, common passwords)? -> Missing MFA on sensitive accounts? -> Session fixation vulnerabilities? -> Credential stuffing protection? 8. A08:2021 — SOFTWARE/DATA INTEGRITY -> Unsigned updates or deployments? -> Missing SRI (Subresource Integrity) for CDN resources? -> Insecure deserialization of user-controlled data? -> CI/CD pipeline security (secrets in logs, unsigned artifacts)? 9. A09:2021 — LOGGING & MONITORING FAILURES -> Login failures not logged? -> Access control failures not logged? -> Sensitive data in logs (passwords, tokens, PII)? -> No alerting on suspicious activity patterns? 10. A10:2021 — SSRF (covered in depth in Phase 10)