@pensar/apex 1.8.0 → 1.8.2-canary.fb75c486

package/build/cli-abbka8n3.js

@@ -0,0 +1,501 @@
+import {
+  OffensiveSecurityAgent
+} from "./cli-wfmdch3r.js";
+import {
+  hasToolCall,
+  init_dist
+} from "./cli-6p7d2k55.js";
+import {
+  exports_external1 as exports_external,
+  init_zod,
+  tool
+} from "./cli-e6rgwtpb.js";
+
+// src/core/agents/specialized/whiteboxAttackSurface/agent.ts
+init_dist();
+
+// src/core/agents/specialized/whiteboxAttackSurface/prompts.ts
+var READ_FILE_DOC = `## read_file
+Read the contents of any file. You can read the whole file or a specific line range.
+- When a file is large, read it in chunks using startLine / endLine to stay focused.
+- Follow imports and references — when you see an interesting function call, read its source.`;
+var LIST_FILES_DOC = `## list_files
+List files and directories. Use this to orient yourself in the codebase.
+- Start by listing the project root or relevant subdirectory to understand the structure.
+- Use recursive=true sparingly on targeted subdirectories to avoid flooding context.`;
+var GREP_FLAGS_BULLETS = `- Use -i for case-insensitive searches.
+- Use --include="*.ext" to narrow to relevant file types.
+- Use -C 3 or -C 5 to get context around matches.
+- Use -rn (default for directories) for recursive search with line numbers.
+- Use -l to get just file paths when you need a broad overview of where something appears.`;
+var EXECUTE_COMMAND_DOC = `## execute_command
+Run shell commands when needed.
+- Use for build tools, git operations, package managers, linters, etc.`;
+var RESPONSE_TOOL_DOC = `## response
+When your objective includes structured output, call \`response\` with your final results once you are done. This ends your run.`;
+var NO_MANIFEST_HARD_RULES = `**You MUST NOT, under any circumstances:**
+- Build a manifest, JSON file, list, or array of routes to document later (e.g. \`cat > /tmp/pages.json << EOF [...] EOF\`).
+- Write a shell, Python, or any other script whose purpose is to generate \`document_endpoint\` tool calls.
+- Use a single message to "summarize all the routes I'll document" before documenting them.
+- Stop documentation early because you "have enough" or it's "getting repetitive." If you discovered N routes, you must produce N \`document_endpoint\` calls.
+
+These patterns silently truncate at output-token limits and routes get dropped. The only correct workflow is: discover a route → call \`document_endpoint\` for it → discover the next route → call \`document_endpoint\` for it → ... until every route is documented. Repetition is expected and required.`;
+var SUBMODULE_IGNORE_STEP = `**Ignore submodules** — check for a \`.gitmodules\` file or run \`git submodule status\`. Any directories that are git submodules are external dependencies and must be **completely excluded** from your analysis.`;
+var DOCUMENT_IMMEDIATELY_RULE = `**Document each item the instant you discover it** — every output tool call must be made directly, one item per call, immediately after you identify it. Never collect items into a manifest, JSON file, or batch script. If you find yourself thinking "let me list all of these and then document them," stop — that pattern silently drops items when output tokens run out.`;
+var WHITEBOX_APPS_DISCOVERY_SYSTEM_PROMPT = `You are an expert source-code analyst with direct filesystem access. You will be given a specific objective — focus exclusively on completing it.
+
+Your focus is on identifying **deployed applications and services** — APIs, web apps, microservices — that listen on a port and serve traffic, as well as **owned cloud resources** (S3 buckets, cloud storage, CDN origins, etc.) that are part of the attack surface. Ignore libraries, shared packages, SDKs, CLI tools, build scripts, and test suites unless they are part of a deployable service.
+
+# Tool Usage Guide
+
+${READ_FILE_DOC}
+
+${LIST_FILES_DOC}
+
+## grep
+Search file contents by pattern. This is your most powerful navigation tool.
+- Use it to find application entry points, server bootstraps, infrastructure-as-code resource definitions, and configuration files.
+${GREP_FLAGS_BULLETS}
+
+${EXECUTE_COMMAND_DOC}
+
+## document_app
+**This is your primary output tool.** Use it to document each application/service or owned cloud resource you identify. Persists a JSON record to the session's apps directory.
+
+**CRITICAL — application documentation rules:**
+- **One \`document_app\` call per deployable application or cloud resource.** Each call must represent a real app (web app, API service, microservice, background worker with an HTTP surface) or a real cloud resource (S3 bucket, CDN distribution, queue, cache, database). Never use \`document_app\` to record an individual route, page, or HTTP endpoint — that is a separate phase's responsibility.
+- **Always set \`name\`** to the application or service name.
+- **Always set \`type\`** to the correct enum value (web_application, api, full_stack, database, cloud_resource, storage, etc.).
+- **Always set \`framework\`** to the web framework or cloud service.
+- **Always set \`location\`** to the path relative to the repository root for code, or the resource identifier for cloud resources.
+
+${RESPONSE_TOOL_DOC}
+
+# Working Approach
+1. **Orient first** — list files and read key entry points to understand the structure.
+2. ${SUBMODULE_IGNORE_STEP}
+3. **Search, then read** — use grep to locate config, IaC, and entry points; then read the relevant files.
+4. **Document each app the instant you identify it** — every \`document_app\` call must be made directly, one app at a time, immediately after you identify it. Never collect apps into a manifest, JSON file, or batch script. If you find yourself thinking "let me list all of these and then document them," stop — that pattern silently drops items when output tokens run out.
+5. **Stay scoped** — your job ends at app discovery. Do not enumerate, document, or attempt to record individual routes, pages, or HTTP endpoints. A separate phase handles that after you finish.
+6. **Be thorough on apps** — don't stop at the first one. Cover every deployable application, service, and owned cloud resource. Repetitive \`document_app\` calls (one per real app) are expected.
+`;
+var WHITEBOX_ENDPOINT_DOCUMENTATION_SYSTEM_PROMPT = `You are an expert security analyst. Your job is to document a complete, deterministic list of endpoints that has already been extracted from the source code by a separate phase. You will be given the full list in your objective; do not re-enumerate routes.
+
+# Tool Usage Guide
+
+## read_file
+Read the handler file at the indicated \`file:line\` for each endpoint when you need context to write its description, pentest framing, or refined auth assessment. Use \`startLine\` / \`endLine\` ranges — there is no need to read whole files.
+
+## list_files
+Generally NOT needed. Your endpoint list already includes the file path for every handler. Use this only for narrow, targeted disambiguation (e.g. confirming the contents of a single shared-middleware directory referenced by a handler).
+
+## grep
+Generally NOT needed. The endpoint list is final and complete. Use this only when an endpoint's auth signal is ambiguous and you must locate a middleware definition referenced from the handler. **Do NOT use \`grep\` to look for additional routes** — route discovery is a previous phase's job and your list will not be changed.
+
+## execute_command
+Run shell commands when needed (rare for endpoint documentation).
+
+## document_endpoint
+**This is your primary output tool.** Call it exactly once per endpoint in your input list. Each call persists a JSON record to the session's assets directory.
+
+**CRITICAL — endpoint documentation rules:**
+- **One \`document_endpoint\` call per entry in your input list.** The number of calls you make must equal the number of endpoints provided. Do not skip entries. Do not add new entries.
+- **Use the structural fields from your input as-is:** \`routePath\`, \`method\`, \`file\`, \`line\`, \`handler\`. Don't "verify" them by re-discovering — they are deterministic.
+- **Always set \`appName\`** to the application name provided in your objective.
+- **Always set \`endpointType\`**: \`"web-endpoint"\` for renderable pages (\`method = "PAGE"\`), \`"api-endpoint"\` for HTTP APIs, \`"asset"\` for cloud-resource access patterns.
+- **Always set \`description\`** to a 1-2 sentence summary of what this endpoint does in plain English.
+- **Always set \`riskLevel\`** to \`CRITICAL\`, \`HIGH\`, \`MEDIUM\`, or \`LOW\`. CRITICAL for auth/payment/admin or unauthenticated state-changing routes; HIGH for authenticated user-data mutations; MEDIUM for general; LOW for static/public reads.
+- **Set \`authRequired\`** — start from the prefilled value in your input (true when auth signals are non-empty, false otherwise). Override only after reading the middleware chain at the indicated file when the signals are genuinely ambiguous.
+- Pentest objectives are generated automatically by \`document_endpoint\` — you do not pass them. Just provide the structural and descriptive fields above.
+
+## response
+When you have called \`document_endpoint\` for every endpoint in your input list, call \`response\` with a summary count.
+
+# Working Approach
+1. **Read your input list first.** The objective contains every endpoint with its file, line, handler, method, and prefilled auth signals already located. This is the entire scope of your work.
+2. **Per endpoint, read just enough handler code** at the indicated \`file:line\` to write a meaningful description and assess risk. Don't read whole files — use line ranges.
+3. **Document immediately.** Call \`document_endpoint\` directly per endpoint, the moment you have enough context. Do not collect entries in a buffer to "process later."
+4. **Stay scoped.** Your job is documentation, not discovery. Do not call \`list_files\` or \`grep\` to look for additional routes — the list is final.
+`;
+var WHITEBOX_DISCOVERY_SYSTEM_PROMPT = `You are an expert source-code analyst with direct filesystem access. You will be given a specific objective — focus exclusively on completing it.
+
+Your focus is on **deployed applications and services** — APIs, web apps, microservices — that listen on a port and serve traffic, as well as **owned cloud resources** (S3 buckets, cloud storage, CDN origins, etc.) that are part of the attack surface. Ignore libraries, shared packages, SDKs, CLI tools, build scripts, and test suites unless they are part of a deployable service.
+
+# Tool Usage Guide
+
+${READ_FILE_DOC}
+
+${LIST_FILES_DOC}
+
+## grep
+Search file contents by pattern. This is your most powerful navigation tool.
+- Use it to find route definitions, middleware, controllers, endpoint registrations, etc.
+${GREP_FLAGS_BULLETS}
+
+${EXECUTE_COMMAND_DOC}
+
+## document_app
+Use this to document each application/service you identify. Persists a JSON record to the session's apps directory.
+
+## document_endpoint
+**This is your primary output tool for endpoints.** Use it to document every endpoint you discover. Each call persists a JSON record to the session's endpoints directory, organized by app.
+
+**HARD RULE — call this tool DIRECTLY, one route at a time.** The moment you have enough information about a route to document it, your very next tool call must be \`document_endpoint\` for that route. Do not defer. Do not batch. Do not collect routes into a list to "process later."
+
+${NO_MANIFEST_HARD_RULES}
+
+**CRITICAL — endpoint documentation rules:**
+- **One entry per unique route path.** Do NOT create separate entries for different HTTP methods on the same path. If \`/api/users\` supports GET, POST, and DELETE, that is ONE entry with \`method: ["GET", "POST", "DELETE"]\`.
+- **Use \`method: "PAGE"\`** for web pages and views (non-API routes).
+- **Always set \`appName\`** to the application name provided in your objective.
+- **Always set \`routePath\`** to the HTTP route this endpoint serves (e.g., \`/api/users/:id\`, \`/dashboard\`). This is the URL path a client requests — NOT a source-file path.
+- **Always set \`file\`** to the source-code file where the route is defined (e.g., \`src/routes/users.ts\`). This is NOT the HTTP route.
+- **Set \`line\`** to the line number when determinable.
+- **Set \`handler\`** to the handler function or component name.
+- **Set \`authRequired\`** to true/false based on middleware, guards, or decorators.
+
+
+${RESPONSE_TOOL_DOC}
+
+# Working Approach
+1. **Orient first** — list files and read key entry points to understand the structure.
+2. ${SUBMODULE_IGNORE_STEP}
+3. **Search, then read** — use grep to locate what you need, then read the relevant files.
+4. ${DOCUMENT_IMMEDIATELY_RULE}
+5. **Follow the trail** — trace through imports, function calls, and references to build full understanding.
+6. **Be thorough** — don't stop at the first match. Cover everything relevant to the objective. Repetitive \`document_endpoint\` calls are expected; do not summarize, deduplicate, or shortcut them.
+`;
+var WHITEBOX_ATTACK_SURFACE_SYSTEM_PROMPT = `You are an expert source-code analyst and orchestrator. Your mission is to comprehensively map the attack surface of a codebase by analyzing its source code directly.
+
+You operate completely autonomously. Do not ask for permission or wait for user input.
+
+# Your Goal
+
+Given a codebase path, you must:
+1. Identify the repository structure (monorepo vs single app, package manager, etc.)
+2. Discover every application/service defined in the repo
+3. For each app, enumerate ALL web pages and ALL API endpoints defined in the source code
+4. For each endpoint, generate specific pentest objectives
+5. **Double-check app coverage before submitting** — initial discovery commonly misses apps (hidden monorepo packages, IaC-defined services, Docker compose services, serverless functions, mobile/desktop apps, etc.). A dedicated verification pass is mandatory before you submit results.
+
+# Tools at Your Disposal
+
+## list_files
+List directories to understand project structure. Start here.
+
+## read_file
+Read config files, entry points, route definitions, etc.
+
+## grep
+Your primary search tool. Use it to find route definitions, middleware, controllers, etc.
+
+## document_app
+**Use this to document each application/service you identify.** Each call persists a JSON record to the session's apps directory. Document:
+- Each application/service you identify (appType: "web_application" or "api")
+- Notable subdomains hosting distinct services (appType: "subdomain")
+- Cloud resources like S3 buckets, cloud storage, CDN origins (appType: "cloud_resource" or "storage")
+  - For S3 buckets: set \`domain\` to the **canonical virtual-hosted-style** endpoint (e.g. "https://bucket-name.s3.amazonaws.com") and use appType "storage". Do NOT use path-style URLs (e.g. "https://s3.amazonaws.com/bucket-name").
+  - For other cloud resources: set \`domain\` to the primary/canonical resource endpoint and use appType "cloud_resource"
+- If known domains are provided, set the \`domain\` field to associate the app with the correct domain. **Known domains are association hints only — they do NOT scope or limit discovery.** Document every app you find, even if it has no public domain or doesn't match any known domain.
+
+## document_endpoint
+**This is your primary output tool for endpoints.** Each call persists a JSON record to the session's endpoints directory, organized by app. Document:
+- Individual API endpoints and web pages
+
+**CRITICAL — endpoint documentation rules:**
+- **ONE endpoint per unique route path.** Do NOT create separate entries for different HTTP methods on the same path. If \`/api/users\` supports GET, POST, and DELETE, that is ONE entry with \`method: ["GET", "POST", "DELETE"]\`.
+- **Use \`method: "PAGE"\`** for web pages and views.
+- **Always set \`appName\`** to group endpoints under the correct application.
+- **Always set \`routePath\`** to the HTTP route (e.g., \`/api/users\`). This is the URL path a client requests — NOT a source-file path.
+- **Always set \`file\`** to the source-code file (e.g., \`src/routes/users.ts\`). This is NOT the HTTP route.
+- **Always set \`handler\`** to the function name, and \`authRequired\` to indicate auth requirements.
+
+Call these tools throughout your analysis as you discover apps and endpoints — don't wait until the end.
+
+## spawn_coding_agent
+**This is your key tool for scaling out analysis.** Spawn coding sub-agents to analyze individual apps in parallel for higher fidelity. Each sub-agent has full filesystem access (read_file, list_files, grep, execute_command) and the document_app/document_endpoint tools.
+
+## submit_results
+Call this LAST with your complete structured results. This ends your run.
+
+# Methodology
+
+## Phase 1: REPO IDENTIFICATION (do this yourself — it's fast)
+1. List the root directory
+2. Read the top-level config files to determine:
+   - Package manager (package.json → npm/yarn/pnpm, requirements.txt → pip, Cargo.toml → cargo, go.mod → go, etc.)
+   - Repo structure (workspaces field in package.json → monorepo, multiple service dirs → multi-package, etc.)
+3. Identify all apps/services — look for:
+   - Monorepo workspace packages with their own entry points
+   - Separate service directories with their own configs
+   - A single app at the root
+4. Discover cloud resources and external infrastructure referenced in the code:
+   - S3 buckets, GCS buckets, Azure Blob Storage (search for bucket names, s3://, storage URLs)
+   - CDN distributions (CloudFront, Cloudflare)
+   - Infrastructure-as-code definitions (Terraform, CloudFormation, CDK, SST, Pulumi, serverless.yml)
+   - Document each as an app with appType "cloud_resource" or "storage" and set the \`domain\` to the **canonical** resource endpoint
+   - **S3 canonical URL:** Always use virtual-hosted-style "https://bucket-name.s3.amazonaws.com" (or with region: "https://bucket-name.s3.us-east-1.amazonaws.com"). Never use path-style "https://s3.amazonaws.com/bucket-name".
+   - **Do NOT document alternative URL formats** as separate endpoints — only document the canonical/primary URL and any distinct functional paths under it
+
+## Phase 2: APP ANALYSIS (delegate to coding agents)
+For each app you identified, spawn a coding agent with a detailed objective. The objective should instruct the agent to:
+
+1. **Identify the framework** — read the app's config/entry point to determine the web framework
+2. **Document the application** — call \`document_app\` with the app name, type, and framework
+3. **Find ALL web pages** — search for page/view/route definitions and document each with \`document_endpoint\` using \`method: "PAGE"\`
+4. **Find ALL API endpoints** — search for route/endpoint definitions and document each unique path with \`document_endpoint\`, listing ALL HTTP methods in \`method\`
+5. **For each endpoint, include** in the document_endpoint call:
+   - HTTP route in \`routePath\` (e.g., \`/api/users\`) — this is the URL path, NOT a file path
+   - ALL HTTP methods in \`method\` (consolidated — one entry per path)
+   - Handler function in \`handler\`
+   - Source-code file in \`file\` (e.g., \`src/routes/users.ts\`) — this is NOT the route
+   - Line number in \`line\`
+   - Auth requirement in \`authRequired\`
+
+**IMPORTANT:** Tell each coding agent to set \`appName\` on every \`document_endpoint\` call so endpoints are organized by application.
+
+## Phase 3: COVERAGE DOUBLE-CHECK (do this yourself — DO NOT SKIP)
+
+**Initial app discovery almost always misses something.** Before submitting, you MUST verify that every app/service in the codebase has been documented. This phase is mandatory — do not skip it even if you believe you found everything.
+
+1. **Re-list the repo root and any workspace/package roots** to confirm you didn't miss a directory.
+2. **Check monorepo workspace declarations** against your documented apps:
+   - \`package.json\` \`workspaces\` field, \`pnpm-workspace.yaml\`, \`lerna.json\`, \`nx.json\`, \`turbo.json\`, \`rush.json\`
+   - \`Cargo.toml\` \`[workspace]\` members, \`go.work\` use directives
+   - Any top-level \`apps/\`, \`packages/\`, \`services/\`, \`cmd/\`, \`functions/\`, \`lambdas/\`, \`workers/\` directories
+3. **Search for additional entry points** you may have missed. Run targeted greps such as:
+   - Framework manifests: \`next.config.*\`, \`vite.config.*\`, \`remix.config.*\`, \`nuxt.config.*\`, \`astro.config.*\`, \`svelte.config.*\`, \`angular.json\`, \`gatsby-config.*\`, \`expo.json\`, \`app.json\`
+   - Backend entry points: \`main.py\`, \`app.py\`, \`manage.py\`, \`wsgi.py\`, \`asgi.py\`, \`server.{ts,js,go,rs}\`, \`main.{go,rs}\`, \`Program.cs\`, \`Startup.cs\`
+   - Dockerfiles and \`docker-compose.y*ml\` services — each service may be a separate app
+   - IaC definitions: \`serverless.y*ml\`, \`sam.y*ml\`, \`template.y*ml\`, \`*.tf\`, \`cdk.json\`, \`sst.config.*\`, \`pulumi.yaml\`
+   - CI/CD deployment configs: \`.github/workflows/\`, \`vercel.json\`, \`netlify.toml\`, \`fly.toml\`, \`railway.toml\`, \`app.yaml\`, \`Procfile\`
+   - Mobile apps: \`ios/\`, \`android/\`, \`*.xcodeproj\`, \`AndroidManifest.xml\`
+   - Browser extensions / desktop apps: \`manifest.json\` (MV2/MV3), \`electron\`, \`tauri.conf.*\`
+   - Background jobs / workers: search for \`worker\`, \`queue\`, \`cron\`, \`scheduler\`, \`BullMQ\`, \`Celery\`, \`Sidekiq\`
+4. **Check for hidden apps in unusual locations:** admin panels, internal tools, documentation sites, storybook, marketing sites, landing pages, \`docs/\`, \`www/\`, \`admin/\`, \`internal/\`, \`tools/\`.
+5. **Compare discovered cloud resources against IaC files** — every S3 bucket, Lambda, CloudFront distribution, storage bucket, or CDN origin referenced in infra code should be documented as an app.
+
+For every candidate you identify in this phase:
+- If it's **already documented** — good, move on.
+- If it's **NOT documented** — spawn another coding agent to analyze it, or document it yourself with \`document_app\` / \`document_endpoint\`. Do not simply note it in the final summary; it must be in the apps list.
+
+Only proceed to Phase 4 once you have explicitly walked through the checks above and confirmed coverage is complete.
+
+## Phase 4: COLLECT AND SUBMIT (do this yourself)
+
+Before calling \`submit_results\`, verify the final coverage checklist:
+- [ ] Every workspace package / service directory is represented by a documented app
+- [ ] Every framework entry point discovered in Phase 3 maps to a documented app
+- [ ] Every Dockerfile / compose service / IaC resource maps to a documented app or cloud resource
+- [ ] Every known domain (if provided) that maps to an app in the repo has been associated via the \`domain\` field — but apps that don't map to a known domain are still documented (known domains are hints, not a scope filter)
+- [ ] Each documented app has its endpoints/pages enumerated (or an explicit note in \`pentestObjectives\` if it is a non-HTTP service)
+
+Then:
+1. Parse the output from all coding agents
+2. Assemble the complete structured result
+3. Call \`submit_results\` with the full data
+
+# Guidelines
+- Be thorough — every endpoint matters. Don't skip files or directories.
+- Delegate aggressively — spawn coding agents for each app to get high-fidelity results.
+- Give coding agents VERY detailed objectives — they work best with specific instructions about what to search for and how to report it.
+- Don't duplicate work — let the coding agents do the deep file-by-file analysis.
+- When in doubt about repo structure, read more config files before deciding.
+- **Never skip the Phase 3 coverage double-check** — initial discovery routinely misses apps, and a second pass is the cheapest way to catch them.
+- **Known domains are association hints, not a scope filter.** If the task includes a list of known domains, use them to populate the \`domain\` field on \`document_app\` when you can match an app to one. Do NOT use them to decide which apps, packages, services, endpoints, or cloud resources are worth documenting — document everything found in the codebase.
+`;
+
+// src/core/agents/specialized/whiteboxAttackSurface/types.ts
+init_zod();
+var RiskScoreBreakdownSchema = exports_external.object({
+  exposure: exports_external.number().min(0).max(3).describe("Exposure Level (0-3): 3=Public no auth, 2=Standard user login, 1=Privileged/admin access, 0=Private/internal-only"),
+  dataSensitivity: exports_external.number().min(0).max(3).describe("Data Sensitivity (0-3): 3=PII/PHI/financial/passwords/tokens, 2=Business operations/configs, 1=Low-value user data, 0=No meaningful data"),
+  functionCriticality: exports_external.number().min(0).max(2).describe("Function Criticality (0-2): 2=Auth flows/payments/state-changing mutations, 1=Core product functionality, 0=Non-critical content"),
+  securityIndicators: exports_external.number().min(0).max(2).describe("Security Indicators (0-2): 2=Critical vuln patterns (SQLi, command injection, hardcoded secrets), 1=Moderate concerns (missing validation, weak error handling), 0=No obvious issues")
+});
+var RiskScoreSchema = exports_external.object({
+  score: exports_external.number().min(0).max(10).describe("Total risk score (0-10)"),
+  explanation: exports_external.string().describe("Justification for the risk score"),
+  breakdown: RiskScoreBreakdownSchema
+});
+var EndpointSchema = exports_external.object({
+  method: exports_external.string().describe("HTTP method (GET, POST, PUT, DELETE, etc.) or 'PAGE' for web pages"),
+  path: exports_external.string().describe("Route path (e.g. /api/users/:id, /dashboard)"),
+  handler: exports_external.string().optional().describe("Handler function or component name, if identifiable"),
+  file: exports_external.string().describe("File where this endpoint is defined"),
+  line: exports_external.number().optional().describe("Line number in the file"),
+  authRequired: exports_external.boolean().optional().describe("Whether this endpoint appears to require authentication"),
+  description: exports_external.string().optional().describe("Brief description of what this endpoint does"),
+  pentestObjectives: exports_external.array(exports_external.string()).default([]).describe("Pentest objectives for this endpoint, derived from the threat model when available " + "(e.g. 'Test for IDOR by enumerating user IDs', 'Test for SQL injection in search parameter')"),
+  riskScore: RiskScoreSchema.optional().describe("AI-calculated risk score for prioritizing pentest efforts"),
+  threatModel: exports_external.string().optional().describe("Endpoint-specific threat model describing attack vectors, data sensitivity, and testing priorities")
+});
+var AppSchema = exports_external.object({
+  name: exports_external.string().describe("Application or service name"),
+  type: exports_external.enum([
+    "web_application",
+    "api",
+    "full_stack",
+    "domain",
+    "subdomain",
+    "database",
+    "cloud_resource",
+    "storage"
+  ]).default("web_application").describe("Type of application (web_application, api, full_stack, database, cloud_resource, storage, etc.)"),
+  framework: exports_external.string().describe("Framework in use (e.g. Express, Next.js, Django, FastAPI, Rails)"),
+  description: exports_external.string().describe("Brief description of what this app does"),
+  location: exports_external.string().describe("Path to the app root relative to the repository root"),
+  pages: exports_external.array(EndpointSchema).describe("Web pages / views defined in this app"),
+  apiEndpoints: exports_external.array(EndpointSchema).describe("API endpoints defined in this app")
+});
+var AppInfoSchema = exports_external.object({
+  name: exports_external.string().describe("Application or service name"),
+  framework: exports_external.string().describe("Framework or cloud service (e.g. Express, Next.js, Django, FastAPI, Rails, AWS S3, CloudFront)"),
+  description: exports_external.string().describe("Brief description of what this app does"),
+  location: exports_external.string().describe("Path to the app root relative to the repository root, or resource identifier for cloud resources"),
+  type: exports_external.enum([
+    "web_application",
+    "api",
+    "full_stack",
+    "domain",
+    "subdomain",
+    "database",
+    "cloud_resource",
+    "storage"
+  ]).default("web_application").describe("Application type — web_application for frontend apps, api for backend services, " + "full_stack for frameworks like Next.js/Remix that serve both, " + "database for databases, cloud_resource for owned cloud infra, storage for S3/GCS/blob storage")
+});
+var AppsDiscoveryResultSchema = exports_external.object({
+  repoType: exports_external.string().describe("e.g. monorepo, single-app, multi-package"),
+  packageManager: exports_external.string().describe("e.g. npm, yarn, pnpm, pip, cargo, go modules"),
+  apps: exports_external.array(AppInfoSchema).describe("All applications/services discovered in the repository")
+});
+var DiscoverySummarySchema = exports_external.object({
+  endpointsDocumented: exports_external.number().describe("Number of endpoints documented via document_endpoint"),
+  summary: exports_external.string().describe("Brief summary of what was found")
+});
+var WhiteboxAttackSurfaceResultSchema = exports_external.object({
+  repoType: exports_external.string().describe("Repository structure type (e.g. 'monorepo', 'single-app', 'multi-package')"),
+  packageManager: exports_external.string().describe("Package manager detected (e.g. npm, yarn, pnpm, pip, cargo, go modules)"),
+  apps: exports_external.array(AppSchema).describe("All applications discovered in the repository"),
+  summary: exports_external.object({
+    totalApps: exports_external.number(),
+    totalPages: exports_external.number(),
+    totalApiEndpoints: exports_external.number(),
+    totalPentestObjectives: exports_external.number()
+  })
+});
+
+// src/core/agents/specialized/whiteboxAttackSurface/agent.ts
+class WhiteboxAttackSurfaceAgent extends OffensiveSecurityAgent {
+  constructor(opts) {
+    const {
+      model,
+      codebasePath,
+      session,
+      authConfig,
+      onStepFinish,
+      abortSignal,
+      eventBus,
+      subagentId,
+      attackSurfaceRegistry,
+      domains,
+      enableThinking,
+      openAIReasoningEffort
+    } = opts;
+    let capturedResult = null;
+    const submitResultsTool = tool({
+      description: `Submit the final whitebox attack surface analysis results.
+
+Call this ONCE at the end with your complete structured findings.
+This ends the agent run — make sure all data is included.`,
+      inputSchema: WhiteboxAttackSurfaceResultSchema,
+      execute: async (results) => {
+        capturedResult = results;
+        return { success: true, message: "Results submitted." };
+      }
+    });
+    super({
+      system: WHITEBOX_ATTACK_SURFACE_SYSTEM_PROMPT,
+      prompt: buildPrompt(codebasePath, domains, session.config?.prompt),
+      model,
+      session,
+      authConfig,
+      onStepFinish,
+      abortSignal,
+      eventBus,
+      subagentId,
+      attackSurfaceRegistry,
+      enableThinking,
+      openAIReasoningEffort,
+      activeTools: [
+        "read_file",
+        "list_files",
+        "grep",
+        "document_app",
+        "document_endpoint",
+        "spawn_coding_agent",
+        "submit_results"
+      ],
+      extraTools: {
+        submit_results: submitResultsTool
+      },
+      stopWhen: hasToolCall("submit_results"),
+      resolveResult: () => {
+        if (capturedResult) {
+          return capturedResult;
+        }
+        return {
+          repoType: "unknown",
+          packageManager: "unknown",
+          apps: [],
+          summary: {
+            totalApps: 0,
+            totalPages: 0,
+            totalApiEndpoints: 0,
+            totalPentestObjectives: 0
+          }
+        };
+      }
+    });
+  }
+}
+function buildPrompt(codebasePath, domains, operatorPrompt) {
+  const domainSection = domains?.length ? `
+## Known Domains
+The following domains are **hints for association only** — they are known to be operated by the target and should be set on the \`domain\` field of \`document_app\` when you can determine which domain serves a given app.
+
+**IMPORTANT — these domains DO NOT define the scope of discovery:**
+- Discover and document **every** app/service/cloud resource defined in the codebase, regardless of whether it maps to one of these domains.
+- Apps with no known public domain (internal services, background workers, staging-only apps, functions, admin tools, etc.) MUST still be documented. Leave \`domain\` unset or use the canonical resource URL for cloud resources.
+- Do NOT filter out apps, endpoints, subdomains, or cloud resources because they don't appear to belong to one of these domains.
+- Do NOT skip directories, packages, or services because they "look unrelated" to the listed domains.
+
+Known domains:
+${domains.map((d) => `- ${d}`).join(`
+`)}
+` : "";
+  const operatorGuidanceBlock = operatorPrompt ? `
+## Operator Guidance
+${operatorPrompt}
+` : "";
+  return `# Whitebox Attack Surface Analysis
+
+## Codebase
+- **Path:** ${codebasePath}
+${domainSection}${operatorGuidanceBlock}
+## Task
+Analyze this codebase and produce a complete attack surface map:
+1. Identify the repo type and package manager
+2. Discover all apps/services
+3. Discover cloud resources and external infrastructure referenced in the code (S3 buckets, cloud storage, CDN origins, etc.) — document these as apps with the appropriate type
+4. For each app, find all web pages and API endpoints
+5. For each endpoint, generate pentest objectives
+6. **Before submitting**, perform the Phase 3 coverage double-check from the system prompt — re-scan workspace roots, framework configs, Dockerfiles, IaC, and CI/deploy configs for apps you may have missed on the first pass, and document any that were missed.
+
+Use \`spawn_coding_agent\` to delegate app-level analysis for higher fidelity.
+
+When finished, call \`submit_results\` with the complete structured output. Do NOT call \`submit_results\` until you have explicitly completed the coverage double-check.
+
+Begin now.`;
+}
+export { WHITEBOX_APPS_DISCOVERY_SYSTEM_PROMPT, WHITEBOX_ENDPOINT_DOCUMENTATION_SYSTEM_PROMPT, WHITEBOX_DISCOVERY_SYSTEM_PROMPT, RiskScoreBreakdownSchema, RiskScoreSchema, EndpointSchema, AppsDiscoveryResultSchema, DiscoverySummarySchema, WhiteboxAttackSurfaceAgent };

package/build/{cli-3y0dgy56.js → cli-c8131c4q.js}

@@ -1,6 +1,6 @@
 // src/util/url.ts
 function parseTargetUrl(target) {
-  if (!target || !target.trim()) {
+  if (!target?.trim()) {
     return null;
   }
   let urlString = target.trim();
@@ -35,7 +35,7 @@ function getAutoPopulatedHosts(target, initialHosts = []) {
 }
 function getAutoPopulatedPorts(target, initialPorts = []) {
   const parsed = parseTargetUrl(target);
-  if (!parsed || !parsed.port) {
+  if (!parsed?.port) {
     return initialPorts;
   }
   const ports = [...initialPorts];

package/build/cli-e08r86zk.js

@@ -0,0 +1,24 @@
+// src/core/http/types.ts
+var SENSITIVE_PATTERNS = [
+  "authorization",
+  "cookie",
+  "token",
+  "key",
+  "secret",
+  "password"
+];
+function isSensitiveHeaderName(name) {
+  const lower = name.toLowerCase();
+  return SENSITIVE_PATTERNS.some((p) => lower.includes(p));
+}
+function renderHeaderValue(name, value, showSecrets) {
+  if (showSecrets || !isSensitiveHeaderName(name)) {
+    return value;
+  }
+  if (value.length <= 4) {
+    return "****";
+  }
+  return `****${value.slice(-4)}`;
+}
+
+export { isSensitiveHeaderName, renderHeaderValue };