📦 deps(thirdparty): update snapshots

2026-07-18 00:02:59 +00:00
parent 82f7c6e56a
commit 47ce7f78dc
1446 changed files with 141041 additions and 6442 deletions
@@ -0,0 +1,46 @@
+# Reconnaissance
+
+### Phase 1: Understand the application
+
+Before looking for bugs, understand what you're auditing. This requires depth, not just a directory listing. Launch **multiple `research` agents in parallel** to map different aspects of the codebase:
+
+**Agent 1a: Overview, tech stack, and comparable baseline**
+```
+Explore the codebase at <path>. Answer:
+1. What is this application? What kind of software? (web app, API, CLI tool, library, daemon, desktop app, mobile backend, etc.)
+2. Who uses it and how? (end users, developers, operators, other services)
+3. What's the tech stack? (languages, frameworks, databases, runtime, deployment model)
+4. What comparable mainstream software exists? What security tradeoffs does the comparable accept?
+5. What's the high-level directory structure?
+Return specific file paths for key entry points.
+```
+
+**Agent 1b: Trust boundaries and access control**
+```
+Explore the codebase at <path>. Find and read ALL code related to:
+1. Trust boundaries — where does untrusted input enter the system? (HTTP requests, CLI args, file reads, IPC, message queues, environment variables, config files, etc.)
+2. Authentication — how do callers prove identity? (sessions, tokens, API keys, mTLS, Unix sockets, etc.) If there's no authentication, note that.
+3. Authorization — how are permissions enforced? (middleware, decorators, capability checks, file permissions, etc.) If there's no authorization model, note that.
+4. Privilege separation — does the code run as root? Drop privileges? Use sandboxing? Fork workers?
+5. Any bypass mechanisms (dev-only modes, test helpers, setup flows, debug flags)
+Return the trust model: who are the actors, what can each do by design, and which code enforces it. Include specific file paths and line numbers.
+```
+
+**Agent 1c: Input surface inventory**
+```
+Explore the codebase at <path>. Produce a complete inventory of where external input enters the system:
+1. Network-facing surfaces (HTTP endpoints, gRPC services, WebSocket handlers, TCP/UDP listeners, etc.) — list each with method/verb and purpose
+2. File-based input (file uploads, config file parsing, log ingestion, import/export, etc.)
+3. IPC and inter-service input (message queues, shared memory, Unix sockets, environment variables, CLI arguments)
+4. User-generated content surfaces (anywhere users provide content that is stored and later rendered, served, or processed)
+5. External integrations (OAuth, webhooks, third-party APIs, plugin loading, dynamic code execution)
+6. All places where input reaches dangerous sinks (SQL/query builders, HTML/template output, file paths, shell commands, deserialization, eval, dynamic imports)
+Return specific file paths. Be exhaustive.
+```
+
+Collect all three agents' outputs and synthesize them into `<output-dir>/architecture.md`:
+- 1-2 page structured summary covering application type, tech stack, trust model, input surfaces, and baseline comparable
+- Include the key file paths from all agents — these become the starting points for Phase 2
+- This document is injected verbatim into every Phase 2 agent prompt
+
+If Phase 1 agents reveal the codebase is larger or more complex than expected (e.g., plugin system, multi-tenant architecture, complex auth chains, multiple deployment targets), launch additional `research` agents to map those areas before proceeding. The quality of Phase 2 depends entirely on the quality of Phase 1.