coverme-scanner 1.10.2 → 1.11.0

package/dist/prompts/coverme-command.md

@@ -1,2466 +1,298 @@
-# CoverMe Multi-Agent Scan Orchestration
+# CoverMe Security Scanner
 
-**Ultrathink** - Analyze deeply, consider edge cases, trace data flows completely.
+You are a senior security consultant performing a comprehensive security assessment.
 
-Execute this multi-agent security scan with cross-validation.
+**Ultrathink** - Analyze deeply, read actual code, trace data flows.
 
 ---
 
-## CRITICAL: FILE-BASED AGENT OUTPUT (Prevents Token Overflow)
+## PHASE 1: DISCOVERY
 
-**Each agent MUST save its findings to a file instead of returning them to the orchestrator.**
-
-This prevents the orchestrator from hitting max tokens when consolidating 17+ agents.
-
-### Agent Output Rules:
-
-1. **Each agent saves to**: `.coverme/agents/{AGENT_ID}.json`
-2. **Create directory first**: `mkdir -p .coverme/agents`
-3. **Agent returns ONLY**: `{"status": "complete", "file": ".coverme/agents/SEC.json", "findingsCount": 5}`
-4. **Orchestrator reads files** after all agents complete
-
-### Agent Output File Format:
-```json
-{
-  "agentId": "SEC",
-  "agentName": "Security Core Scanner",
-  "scanDate": "2026-02-18T10:00:00Z",
-  "duration": "45s",
-  "findings": [...],
-  "positives": [...],
-  "skipped": false,
-  "skipReason": null
-}
-```
-
-### Orchestrator Consolidation:
-```bash
-# After all agents complete, read all findings:
-cat .coverme/agents/*.json | jq -s 'map(.findings) | flatten'
-```
-
-This architecture allows unlimited agents without token overflow.
-
----
-
-## PHASE 0: PROJECT DISCOVERY & ARCHITECTURE MAPPING
-
-Before scanning, understand what you're scanning and build the architecture map.
-
-### Step 0: Initialize Agent Output Directory
-
-```bash
-mkdir -p .coverme/agents
-```
-
-### Step 1: Gather Project Statistics
-
-### Step 1: Gather Project Statistics
-
-```bash
-# List ALL top-level directories (excluding hidden, node_modules, dist, build)
-ls -d */ 2>/dev/null | grep -v -E '^(node_modules|dist|build|\.)/
-
-# Count files and lines of code
-find . -type f \( -name "*.ts" -o -name "*.js" -o -name "*.tsx" -o -name "*.jsx" -o -name "*.py" -o -name "*.go" -o -name "*.java" -o -name "*.rb" -o -name "*.php" -o -name "*.cs" -o -name "*.swift" -o -name "*.kt" \) -not -path "*/node_modules/*" -not -path "*/.git/*" -not -path "*/dist/*" -not -path "*/build/*" -not -path "*/__pycache__/*" | wc -l
-
-# Count lines of code (approximate)
-find . -type f \( -name "*.ts" -o -name "*.js" -o -name "*.tsx" -o -name "*.jsx" -o -name "*.py" -o -name "*.go" \) -not -path "*/node_modules/*" -not -path "*/.git/*" -not -path "*/dist/*" 2>/dev/null | head -100 | xargs wc -l 2>/dev/null | tail -1
-
-# Generate project tree (2 levels deep)
-find . -maxdepth 2 -type d -not -path "*/node_modules/*" -not -path "*/.git/*" -not -path "*/dist/*" -not -path "*/__pycache__/*" -not -path "*/build/*" | sort
-```
-
-### Step 2: Read Project Info
-
-```bash
-cat package.json 2>/dev/null | head -30
-cat README.md 2>/dev/null | head -100
-ls -la
-ls src/ 2>/dev/null || ls app/ 2>/dev/null || ls lib/ 2>/dev/null
-```
-
-### Step 3: Create Project Overview
-
-Include these statistics in the final report:
-
-```json
-{
-  "filesScanned": 45,
-  "linesOfCode": 4850,
-  "projectTree": "project-name/\n├── src/\n│   ├── api/\n│   ├── services/\n│   └── utils/\n├── tests/\n└── package.json",
-  "projectOverview": {
-    "name": "project-name",
-    "type": "Backend API | Frontend SPA | Full-stack | CLI | Library | Microservice",
-    "stack": ["Node.js", "TypeScript", "React", "PostgreSQL", "Redis"],
-    "purpose": "1-2 sentence description of what this project does",
-    "architecture": "Monolith | Microservices | Serverless | Hybrid",
-    "keyComponents": ["backend-api/", "frontend/", "services/", "packages/", "etc"]
-  }
-}
-```
-
-**IMPORTANT**:
-- `filesScanned` - Count of source code files analyzed (not node_modules/dist)
-- `linesOfCode` - Total lines in source files (approximate is fine)
-- `projectTree` - ASCII tree representation of main directories (use tree format with ├── and └──)
-- `keyComponents` - **MUST include ALL top-level directories** containing source code. Do NOT skip any directory. List every folder from `ls -d */` excluding node_modules/dist/build/.git
-
-This context helps readers understand the security findings in context.
-
-### Step 3: Check for Previous Scan Results
-
-```bash
-cat .coverme/scan.json 2>/dev/null | head -5 || echo "NO_PREVIOUS_SCAN"
-```
-
-**IF previous scan.json exists:**
-- Load previous findings to track what was resolved since the last scan
-- Compare current findings against previous findings
-- Any finding from previous scan NOT found in current scan = "Previously Resolved"
-- Include a `previouslyResolved` array in the final output showing what was fixed
-- This builds trust and shows security progress over time
-
-**Format for previously resolved:**
-```json
-{
-  "id": "PREV-001",
-  "title": "Original finding title from previous scan",
-  "originalSeverity": "critical|high|medium|low",
-  "resolution": "How it was fixed — be specific: 'Replaced string concatenation with parameterized queries via Prisma ORM. Verified no raw SQL remains.'",
-  "resolvedDate": "Date of current scan"
-}
-```
-
-**Example Previously Resolved section (from Officely report):**
-- "DuckDB SQL Injection (was CRITICAL) — Resolved: enable_external_access=false sandbox + comprehensive SQL validation blocklist."
-- "Admin API Fail-Open (was HIGH) — Resolved: Binds to 127.0.0.1, fail-closed when no ADMIN_ALLOWED_IPS. Three-layer defense."
-- "Redis KEYS in Production (was HIGH) — Resolved: All paths now use SCAN via cursor-based scanKeys()."
-
-**IF NO previous scan:**
-- Skip — set `previouslyResolved` to empty array `[]`
-
-### Step 4: Check for Runtime Verification (SSH)
-
-```bash
-cat .coverme/runtime.json 2>/dev/null || echo "NO_RUNTIME_CONFIG"
-```
-
-**IF runtime.json exists with environments:**
-- Runtime verification is ENABLED
-- Store the SSH details for use in AGENT 22 (Runtime Verification)
-- The agent will SSH to compare actual runtime vs code expectations
-
-**IF NO runtime.json:**
-- Runtime verification is DISABLED (skip AGENT 22)
-- This is normal - many projects don't need runtime verification
-
-### Step 5: Architecture Discovery (AGENT 0)
-
-**This runs FIRST, before all other agents. Its output feeds into every subsequent agent.**
-
-Build a comprehensive architecture map by analyzing:
-
-```bash
-# Detect databases
-grep -r -l "prisma\|mongoose\|sequelize\|typeorm\|pg\|mysql\|redis\|mongodb" --include="*.json" --include="*.ts" --include="*.js" . 2>/dev/null | head -5
-
-# Detect auth providers
-grep -r -l "clerk\|auth0\|firebase.auth\|passport\|next-auth\|supabase.auth" --include="*.ts" --include="*.js" . 2>/dev/null | head -5
-
-# Detect external APIs
-grep -r "fetch\|axios\|got\|request" --include="*.ts" --include="*.js" . 2>/dev/null | grep -v node_modules | head -10
-
-# Detect infrastructure
-ls -la Dockerfile docker-compose* k8s/ helm/ .github/workflows/ 2>/dev/null
-```
-
-**Save architecture map to `.coverme/agents/ARCH-D.json`:**
-```json
-{
-  "agentId": "ARCH-D",
-  "agentName": "Architecture Discovery",
-  "architecture": {
-    "components": [
-      {"name": "API Server", "type": "service", "tech": "Express.js", "files": ["src/server.ts"]},
-      {"name": "PostgreSQL", "type": "database", "tech": "Prisma", "files": ["prisma/schema.prisma"]},
-      {"name": "Redis", "type": "cache", "tech": "ioredis", "files": ["src/redis.ts"]}
-    ],
-    "trustBoundaries": [
-      {"name": "Client → API", "from": "Browser", "to": "API Server", "protocol": "HTTPS"},
-      {"name": "API → DB", "from": "API Server", "to": "PostgreSQL", "protocol": "TLS"}
-    ],
-    "externalDependencies": [
-      {"name": "Stripe", "type": "payment", "files": ["src/payments/stripe.ts"]},
-      {"name": "OpenAI", "type": "ai", "files": ["src/ai/openai.ts"]}
-    ],
-    "criticalAssets": [
-      {"name": "User Credentials", "location": "PostgreSQL", "protection": "bcrypt"},
-      {"name": "API Keys", "location": "Environment", "protection": "Secrets Manager"}
-    ]
-  },
-  "detectedTechnologies": {
-    "hasAI": true,
-    "hasRedis": true,
-    "hasEnclave": false,
-    "hasDatabase": true,
-    "databaseType": "PostgreSQL"
-  }
-}
-```
-
-**This architecture map is used by:**
-- All scanners to understand context
-- EXEC agent for executive summary
-- Final report for architecture overview
-
----
-
-## CRITICAL OUTPUT FORMAT
-
-Every finding MUST include ALL these fields for the report to work:
-
-```json
-{
-  "id": "PREFIX-XXX",
-  "title": "Descriptive title specific to the exact vulnerability (NOT generic category labels)",
-  "severity": "critical|high|medium|low|info",
-  "category": "Category name",
-  "file": "exact/path/to/file.ts",
-  "line": 123,
-  "endLine": 156,
-  "code": "the vulnerable/problematic code snippet",
-  "description": "Precise technical narrative: what function has the issue, how it manifests, why it's dangerous. Include DREAD-D score inline for HIGH/CRITICAL.",
-  "impact": "Security impact - what an attacker could exploit, potential damage, real-world risk",
-  "attackChain": "Step-by-step exploitation: 1. Attacker does X, 2. System responds with Y, 3. Attacker gains Z",
-  "recommendation": "Immediately actionable: specific function names, specific patterns, specific code changes",
-  "cwe": "CWE-XXX (if applicable)",
-  "confidence": 85,
-  "fixOwner": "developer|devops|architect",
-  "fixType": "code|config|infrastructure|design",
-  "crossReferences": ["OTHER-ID-1"],
-  "dread": {
-    "damage": 8,
-    "reproducibility": 9,
-    "exploitability": 7,
-    "affectedUsers": 10,
-    "discoverability": 6,
-    "score": 8.0
-  }
-}
-```
-
-### fixOwner & fixType Guidelines
-
-**fixOwner** - Who should fix this:
-- `developer` - Code change required (validation, sanitization, logic fix)
-- `devops` - Infrastructure/config change (NetworkPolicy, firewall, K8s config, CI/CD)
-- `architect` - Design decision needed (authentication strategy, data flow, service boundaries)
-
-**fixType** - What kind of fix:
-- `code` - Change application code
-- `config` - Change configuration files (env, yaml, json)
-- `infrastructure` - Change deployment/infra (K8s, Docker, cloud)
-- `design` - Requires architectural redesign
-
-## DREAD SCORING (for HIGH and CRITICAL findings)
-
-Calculate DREAD score (1-10 for each, average for final score):
-
-- **Damage**: How severe is the impact? (10 = full system compromise, 1 = minimal)
-- **Reproducibility**: How easy to reproduce? (10 = always works, 1 = rare conditions)
-- **Exploitability**: How easy to exploit? (10 = script kiddie, 1 = expert + physical access)
-- **Affected Users**: How many users impacted? (10 = all users, 1 = single admin)
-- **Discoverability**: How easy to find? (10 = obvious, 1 = requires source code)
-
-**Score interpretation**:
-- 9.0-10.0 = CRITICAL (exploit immediately)
-- 7.0-8.9 = HIGH (fix within days)
-- 5.0-6.9 = MEDIUM (fix within sprint)
-- 3.0-4.9 = LOW (backlog)
-- 1.0-2.9 = INFO (document only)
-
-## PROFESSIONAL WRITING STANDARDS
-
-**Every finding must read as if written by an experienced security consultant, not a generic scanner.**
-
-### Title Quality
-Titles must be descriptive and specific to the exact vulnerability — not generic category labels.
-
-**BAD (generic):**
-- "Hardcoded credentials found"
-- "Missing input validation"
-- "XSS vulnerability"
-
-**GOOD (descriptive, specific to the code):**
-- "Hardcoded Tracker API Keys and Hash Salts in Helm Values"
-- "Attestation Fallback Accepts Unverified Enclave Keys"
-- "Credit Deduction After GPU Processing in Non-Streaming Path"
-- "Command Injection via Unvalidated Model Name in pm2 delete"
-
-### Description Quality
-Descriptions must trace the exact technical flow: what function, what input, what happens, and what the consequence is — in ONE precise paragraph.
-
-**BAD (vague):**
-"There is a security issue with hardcoded credentials in the configuration file. This could allow unauthorized access."
-
-**GOOD (precise technical narrative):**
-"Staging and production Helm values contain hardcoded API keys (stg-tracker-api-key, prd-tracker-api-key) and hash salts in plaintext, committed to version control. Anyone with repo access can write arbitrary data to the tracker. DREAD-D: 6.5."
-
-**GOOD (traces the full attack flow):**
-"When the attestation bundle endpoint is unavailable, fetchEnclaveInfo() falls back to the legacy /api/v1/enclave endpoint and stores keys with keysVerified: false. The browser silently proceeds to encrypt messages with public keys that have not been cryptographically bound to hardware attestation — enabling a man-in-the-middle attack by a compromised gateway."
-
-**GOOD (explains business logic flaw):**
-"In the non-streaming path, credit deduction happens after the enclave has processed the request. A concurrent request could deplete credits between the pre-flight check and the deduction, consuming GPU resources without payment. The streaming path handles this correctly."
-
-### Recommendation Quality
-Recommendations must be immediately actionable — specific function names, specific patterns, specific code.
-
-**BAD:**
-"Fix the hardcoded credentials"
-"Add input validation"
-
-**GOOD:**
-"Move to AWS Secrets Manager alongside existing KP_SECRETS_PATH pattern. Remove from version control. Rotate immediately."
-"Extract to trackRedisMetrics(redis, models, userIdentifier) and call from both paths."
-"Move validation to the top of startModels(). Apply in stopModels(). Use execFileAsync('pm2', ['delete', model])."
-"Validate against whitelist from models.json or restrict to ^[a-zA-Z0-9_-]+$."
-
-### Cross-Referencing
-When multiple agents identify the same issue from different perspectives, MERGE them using dual IDs:
-- "CR-02 / T-EKS-3: Hardcoded Tracker API Keys and Hash Salts in Helm Values"
-- "T-EKS-4 / CR-18: User Identity Logged and Hash Truncated to 64 Bits"
-- "T-BFF-3 / CR-08: Error Details Leaked to Clients"
-
-This shows the issue was found independently from multiple angles, increasing confidence.
-
-### Quantitative Precision
-Always include specific numbers when available:
-- Line counts: "160 lines of Redis metrics tracking code is duplicated verbatim"
-- Percentages: "5.3% of the codebase"
-- Bit lengths: "truncates SHA-256 to only 16 hex characters (64 bits)"
-- Specific values: "session timeout of 24h", "maxAge: 31536000"
-
-### DREAD Score Inline
-For HIGH and CRITICAL findings, include the DREAD-D score directly in the description text: "DREAD-D: 6.3."
-
-### Positive Observations Depth
-Positive observations must cite specific technical evidence, not generic praise.
-
-**BAD:**
-"Good authentication implementation"
-
-**GOOD:**
-"Zero-Knowledge Architecture — EKS gateway genuinely never sees plaintext. Encrypted payloads flow through without decryption. Well-enforced across all components."
-"Atomic Credit Operations — Lua scripts for token burning and balance deduction prevent cross-pod race conditions. Check-and-deduct is atomic."
-"Secure File Handling — MIME + magic number validation, memory-only storage, size limits. secureDeleteFile() overwrites with random data before deletion."
-
----
-
-## FIELD GUIDELINES
-
-### description (REQUIRED — PROFESSIONAL QUALITY)
-Write a precise technical narrative explaining:
-1. **What** specific function/file/pattern has the issue
-2. **How** the vulnerability manifests (trace the data flow)
-3. **Why** it's dangerous (the consequence in one clause)
-4. Include DREAD-D score inline for HIGH/CRITICAL: "DREAD-D: 6.5."
-
-### impact (REQUIRED)
-Explain the real-world security impact. Be specific about:
-- What an attacker could do (e.g., "steal session tokens", "access other users' data")
-- The potential damage (e.g., "full account takeover", "data breach")
-- Why this matters to the business (e.g., "regulatory compliance violation", "reputation damage")
-
-Example: "An attacker could inject malicious scripts that steal session cookies, enabling full account takeover of any logged-in user"
-
-### recommendation (REQUIRED — ACTIONABLE)
-Must include at least one of:
-- Specific function/method name to create or modify
-- Specific configuration change with exact values
-- Specific library/pattern to use
-- Code snippet showing the fix
-
----
-
-## PHASE 1: BATCHED DISCOVERY (Memory-Efficient)
-
-**CRITICAL: To prevent memory overflow, run agents in SMALL BATCHES of 3-4 agents max.**
-
-### Memory Management Rules:
-1. **Never run more than 4 agents in parallel** - prevents context overflow
-2. **Each agent returns ONLY a status message** - not full findings
-3. **Agents save findings to files** - orchestrator reads files later
-4. **Wait for batch to complete before starting next batch**
-
-### Batch Schedule:
-```
-Batch 1 (Core Security):  SEC, AUTH, API, INFRA
-Batch 2 (Specialized):    AI, BIZ, DATA, PERF
-Batch 3 (Quality):        QUAL, TEST, DEAD, PII
-Batch 4 (Deep Analysis):  REDIS, RESIL, DB, ARCH
-Batch 5 (Validation):     DESIGN, CTX, ENC, DUP
-Batch 6 (Summary):        EXEC (single agent)
-```
-
-**IMPORTANT: Each agent MUST follow these steps:**
-
-1. **Create output directory**: `mkdir -p .coverme/agents`
-2. **Scan the codebase** according to agent-specific instructions
-3. **Save findings to file**: `.coverme/agents/{AGENT_ID}.json`
-4. **Return ONLY a short status** (not findings!): `{"status": "complete", "file": ".coverme/agents/{AGENT_ID}.json", "count": N}`
-
-**DO NOT return full findings in agent response - this causes memory overflow!**
-
-**Agent output file template:**
-```json
-{
-  "agentId": "SEC",
-  "agentName": "Security Core Scanner",
-  "scanDate": "{{SCAN_DATE}}",
-  "skipped": false,
-  "skipReason": null,
-  "findings": [/* array of findings */],
-  "positives": [/* array of positive observations */]
-}
-```
-
-**For CONDITIONAL agents (AI, REDIS, ENC, DB):**
-- First detect if relevant code exists
-- If NOT found: `{"skipped": true, "skipReason": "No AI/LLM code detected", "findings": []}`
-- If found: proceed with normal scan
-
----
-
-### AGENT 1: Security Core Scanner (ID prefix: SEC)
-
-Scan {{PROJECT_PATH}} for OWASP Top 10 and core security vulnerabilities.
-
-CHECK FOR:
-- SQL/NoSQL Injection (parameterized queries missing)
-- XSS (reflected, stored, DOM-based)
-- Command Injection (shell commands with user input)
-- Path Traversal (../ in file operations)
-- SSRF (user-controlled URLs in fetch/axios)
-- XXE (XML parsing without disabling entities)
-- Insecure Deserialization (JSON.parse on untrusted data)
-- Hardcoded Secrets (API keys, passwords, tokens in code)
-- Weak Cryptography (MD5, SHA1 for passwords, ECB mode)
-- Insecure Random (Math.random for security purposes)
-
-**DATABASE-SPECIFIC DANGEROUS FUNCTIONS** (check for ANY database):
-- DuckDB: read_text(), read_blob(), read_csv_auto(), read_parquet(), glob(), getenv(), httpfs
-- SQLite: load_extension(), readfile(), writefile()
-- PostgreSQL: pg_read_file(), pg_ls_dir(), COPY TO/FROM
-- MySQL: LOAD_FILE(), INTO OUTFILE, INTO DUMPFILE
-- MongoDB: $where with user input, mapReduce with user functions
-- Redis: EVAL/EVALSHA with user input, CONFIG, DEBUG commands
-
-**BLOCKLIST BYPASS PATTERNS**:
-- Keyword blocklists that miss database-specific functions
-- Case sensitivity bypass (READ_TEXT vs read_text)
-- Unicode homoglyph bypass
-- Comment injection (SELECT/**/read_text)
-- Encoding bypass (hex, base64, URL encoding)
-
-For EACH finding, output the FULL JSON format above.
-
----
-
-### AGENT 2: Auth & Session Scanner (ID prefix: AUTH)
-
-Scan {{PROJECT_PATH}} for authentication and session vulnerabilities.
-
-**FIRST: Detect which auth method(s) this project uses:**
-
-| Auth Type | Detection Pattern |
-|-----------|-------------------|
-| OAuth/OIDC | `oauth`, `oidc`, `authorization_code`, `client_id`, `redirect_uri` |
-| JWT | `jsonwebtoken`, `jwt`, `Bearer`, `accessToken`, `refreshToken` |
-| Session-based | `express-session`, `cookie-session`, `session.save`, `req.session` |
-| API Keys | `x-api-key`, `apiKey`, `api_key`, `API_SECRET` |
-| Basic Auth | `Basic `, `Authorization`, `btoa`, `base64` |
-| Clerk | `@clerk`, `useAuth`, `clerkMiddleware` |
-| Auth0 | `@auth0`, `auth0-js`, `auth0-react` |
-| Firebase Auth | `firebase/auth`, `signInWith`, `onAuthStateChanged` |
-| Passport.js | `passport`, `passport-local`, `passport-jwt` |
-| Supabase Auth | `@supabase/auth`, `supabase.auth` |
-| NextAuth | `next-auth`, `NextAuth`, `getServerSession` |
-| Custom | `login`, `authenticate`, `verifyToken`, `checkAuth` |
-
-**FOR EACH AUTH TYPE DETECTED, check specific vulnerabilities:**
-
-**OAuth/OIDC:**
-- Open redirect in return_url/redirect_uri (CRITICAL!)
-- State parameter missing or predictable
-- PKCE not implemented for public clients
-- Token stored in localStorage (XSS vulnerable)
-- Refresh token rotation missing
-- ID token validation incomplete
-
-**JWT:**
-- `alg: none` accepted (signature bypass)
-- Weak secret (< 256 bits)
-- No expiry (`exp` claim missing)
-- Secret in code/env without rotation
-- `HS256` when `RS256` needed (shared secret risk)
-- Token not invalidated on logout
-
-**Session-based:**
-- Session ID in URL (referer leak)
-- Session not invalidated on logout
-- Session timeout too long (>24h)
-- Session fixation (not regenerated after login)
-- Session data not encrypted
-- Missing `secure`, `httpOnly`, `sameSite` on cookies
-
-**API Keys:**
-- API key in URL (logged, cached, referer leak)
-- No key rotation mechanism
-- Same key for all environments
-- Key logged or in error messages
-- No per-key rate limiting
-
-**Password/Credentials:**
-- Password reset: predictable tokens
-- Password reset: no expiry
-- No rate limiting on login
-- User enumeration via different responses
-- Passwords stored without hashing
-- Weak password policy
-
-**UNIVERSAL AUTH CHECKS (all types):**
-- Brute force protection missing
-- MFA bypass paths
-- Account lockout not implemented
-- Auth state not cleared on logout
-- Sensitive endpoints without auth
-
-**MEMORY SAFETY FOR SECRETS**:
-- Cryptographic keys not zeroed after use
-- Passwords stored in String instead of char[]
-- Session tokens not cleared on logout
-- Private keys in JavaScript objects (V8 heap)
-
-**TIMING ATTACKS**:
-- Non-constant-time string comparison for tokens/secrets
-- Early return on auth failure leaking valid usernames
-- Different response times for valid vs invalid credentials
-
-For EACH finding, output the FULL JSON format.
-
----
-
-### AGENT 3: API Security Scanner (ID prefix: API)
-
-Scan {{PROJECT_PATH}} for API security issues.
-
-CHECK FOR:
-- Missing authentication on endpoints
-- Broken authorization (IDOR, privilege escalation)
-- Input validation missing (Zod/Joi schemas)
-- Rate limiting issues (non-atomic INCR+EXPIRE in Redis)
-- CORS misconfiguration (Access-Control-Allow-Origin: *)
-- Mass assignment (spreading req.body into DB)
-- Webhook signature verification missing (HMAC)
-- GraphQL introspection enabled in production
-- API versioning issues
-- Excessive data exposure in responses
-
-**CORS MISCONFIGURATION** (MEDIUM):
-Look for these vulnerable patterns:
-```javascript
-// VULNERABLE - reflects ANY origin
-res.header('Access-Control-Allow-Origin', req.headers.origin);
-res.header('Access-Control-Allow-Origin', '*');
-
-// VULNERABLE - no whitelist validation
-app.use(cors({ origin: true }));
-```
-Only mark as safe if there's explicit whitelist validation:
-```javascript
-const allowedOrigins = ['https://app.example.com'];
-if (allowedOrigins.includes(origin)) { ... }
-```
-
-**HELMET MISCONFIGURATION** (MEDIUM):
-```javascript
-app.use(helmet());  // Using defaults only - INSUFFICIENT!
-```
-Check that helmet() includes:
-- Custom `contentSecurityPolicy` with proper directives
-- `hsts: { maxAge: 31536000, includeSubDomains: true, preload: true }`
-- Proper `referrerPolicy`
-Report as MEDIUM if using only defaults without customization.
-
-**FAIL-OPEN vs FAIL-CLOSED PATTERNS** (CRITICAL):
-- IP whitelist empty/missing = allow all (should deny all)
-- Auth middleware errors = request passes through (should block)
-- Rate limiter Redis down = no limiting (should block or use fallback)
-- Config missing = insecure defaults (should fail startup)
-- Feature flag missing = feature enabled (should be disabled)
-- RBAC role not found = access granted (should deny)
-
-Look for patterns like:
-```
-if (whitelist.length > 0) { check() }  // FAIL-OPEN: empty whitelist bypasses
-if (!config.AUTH_REQUIRED) { next() }  // FAIL-OPEN: missing config = no auth
-catch(e) { next() }                     // FAIL-OPEN: error = proceed
-```
-
-**ADMIN/INTERNAL API EXPOSURE**:
-- Admin APIs bound to 0.0.0.0 instead of 127.0.0.1
-- Internal ports exposed without auth
-- Debug endpoints in production
-- Metrics/health endpoints exposing sensitive data
-
-For EACH finding, output the FULL JSON format.
-
----
-
-### AGENT 4: Infrastructure Scanner (ID prefix: INFRA)
-
-Scan {{PROJECT_PATH}} for infrastructure and DevOps issues.
-
-CHECK FOR:
-- Secrets in git-tracked files (Helm values, K8s manifests, .env committed)
-- Real IPs/hostnames committed to repo
-- Docker issues (running as root, secrets in layers)
-- K8s pod security context missing
-- CI/CD pipeline security (missing quality gates)
-- Missing security headers in server config
-- TLS/SSL configuration issues
-- Debug mode enabled in production configs
-- Exposed internal ports
-- Missing resource limits
-
-**SECRETS IN CONFIGURATION FILES** (check ALL config formats):
-- Helm values.yaml / values-*.yaml with hardcoded secrets
-- Kubernetes secrets not using external secrets manager
-- Docker Compose with hardcoded passwords
-- Terraform tfvars with credentials
-- Ansible vault passwords in plaintext
-- CI/CD pipeline secrets in yaml files (.github/workflows, .gitlab-ci.yml)
-
-**SECRETS IN GIT HISTORY** (CRITICAL CHECK!):
-Run these commands to check if secrets were EVER committed:
-```bash
-git log --all --full-history -- "**/secrets*" "**/credentials*" "**/*.env"
-git log --all -p -S "AWS_SECRET" -S "PRIVATE_KEY" --source
-```
-If secrets appear in history, they are EXPOSED even if now gitignored!
-
-**PRIVILEGE ESCALATION RISKS**:
-- Containers/processes running as root
-- Missing securityContext in K8s (runAsNonRoot, readOnlyRootFilesystem)
-- Privileged containers
-- Host path mounts to sensitive directories
-- Missing capability drops (drop: ALL)
-- Service accounts with excessive permissions
-
-**CONFIGURATION THAT SHOULD FAIL AT STARTUP**:
-- Required environment variables not validated at startup
-- Missing config = silent fallback to insecure defaults
-- No validation of secret strength/format at startup
-
-**DEPENDENCY SECURITY** (HIGH if missing):
-Check for presence of:
-- `npm audit` or `yarn audit` in CI pipeline
-- Dependabot/Renovate configuration (.github/dependabot.yml, renovate.json)
-- SBOM generation (cyclonedx, syft)
-- Snyk/Trivy/Grype scanning
-Report as HIGH if NONE of these exist - supply chain risk!
-
-**LOGGING & MONITORING**:
-- Log rotation configured? (maxFiles, maxsize in Winston/Pino)
-- Log retention policy defined?
-- Sensitive data redacted from logs?
-Report as LOW if log rotation missing - disk exhaustion risk.
-
-For EACH finding, output the FULL JSON format.
-
----
-
-### AGENT 5: Data & Privacy Scanner (ID prefix: DATA)
-
-Scan {{PROJECT_PATH}} for data protection and privacy issues.
-
-CHECK FOR:
-- PII logging (emails, IPs, names in logs)
-- GDPR deletion bugs (incomplete data removal)
-- Encryption at rest missing for sensitive fields
-- Data residency violations
-- Backup encryption missing
-- Sensitive data in URLs/query params
-- Missing data classification
-- Retention policy not enforced
-- Export functionality exposing too much data
-- Cross-tenant data leakage
-
-For EACH finding, output the FULL JSON format.
-
----
-
-### AGENT 6: AI/LLM Security Scanner (ID prefix: AI)
-
-**CONDITIONAL AGENT** - First detect if this project uses AI/LLM:
-
-```bash
-# Search for AI/LLM indicators
-grep -r -l "openai\|anthropic\|langchain\|ollama\|huggingface\|llama\|gpt-\|claude\|gemini\|bedrock\|vertex" --include="*.ts" --include="*.js" --include="*.py" --include="*.json" .
-```
-
-**IF NO AI CODE FOUND**: Output and skip:
-```json
-{"skipped": true, "reason": "No AI/LLM code detected in project", "findings": []}
-```
-
-**IF AI CODE FOUND**: Scan {{PROJECT_PATH}} for AI/LLM specific vulnerabilities.
-
-CHECK FOR:
-- Prompt injection (user input directly in prompts)
-- Content filter fail-open (errors bypass safety)
-- CDN imports without SRI (integrity hashes missing)
-- Model output not sanitized before use
-- Sensitive data sent to external AI APIs
-- AI decision logging insufficient for audit
-- Rate limiting on AI endpoints
-- Cost controls missing
-- Jailbreak prevention missing
-- PII in training data/prompts
-
-**LLM OUTPUT → CODE EXECUTION CHAINS**:
-- LLM generates SQL that gets executed (SQL injection via prompt injection)
-- LLM generates code that gets eval'd
-- LLM generates shell commands that get executed
-- LLM generates file paths that get accessed
-- LLM output used in template rendering (SSTI)
-
-**VALIDATION OF LLM OUTPUT**:
-- Is there ANY validation between LLM output and dangerous operations?
-- Are blocklists/allowlists applied to LLM-generated content?
-- Can the blocklist be bypassed? (check for completeness)
-- Is validation case-insensitive?
-- Does validation handle encoded input?
-
-**PROMPT SANITIZATION WEAKNESSES**:
-- Regex-based filtering (easily bypassed with synonyms, encoding, whitespace)
-- Literal string matching (bypass with Unicode homoglyphs)
-- Missing: base64 encoded payloads, ROT13, leetspeak variations
-
-For EACH finding, output the FULL JSON format.
-
----
-
-### AGENT 7: Performance & DoS Scanner (ID prefix: PERF)
-
-Scan {{PROJECT_PATH}} for performance and denial-of-service issues.
-
-CHECK FOR:
-- N+1 query patterns
-- ReDoS (regex denial of service)
-- Memory leaks (event listeners not removed, growing caches)
-- Unbounded data structures
-- Missing pagination
-- SSE/WebSocket buffering entire streams
-- Heavy computation blocking event loop
-- Missing connection pooling
-- Resource exhaustion (no limits on uploads, requests)
-- Synchronous operations that should be async
-
-**DANGEROUS DATABASE OPERATIONS IN HOT PATHS**:
-- Redis KEYS command (blocks entire server, O(n) scan)
-- MongoDB find() without limit
-- SQL SELECT without LIMIT on large tables
-- Full table scans in request handlers
-- Aggregations without indexes
-
-**BLOCKING OPERATIONS**:
-- Synchronous file I/O in request handlers
-- crypto.pbkdf2Sync / crypto.scryptSync in hot paths
-- JSON.parse on unbounded input
-- Regex on user input without timeout
-- DNS lookups without caching
-
-For EACH finding, output the FULL JSON format.
-
----
-
-### AGENT 8: Business Logic Scanner (ID prefix: BIZ)
-
-Scan {{PROJECT_PATH}} for business logic vulnerabilities.
-
-CHECK FOR:
-- Race conditions (TOCTOU, double-spend)
-- Workflow bypass (skipping required steps)
-- Price/quantity manipulation
-- Negative value attacks
-- State machine violations
-- Time-based attacks (timing side channels)
-- Non-constant-time comparisons for secrets
-- Duplicate request handling (missing idempotency)
-- Business rule bypass
-- Inconsistent validation between client/server
-
-For EACH finding, output the FULL JSON format.
-
----
-
-### AGENT 9: Code Quality Scanner (ID prefix: QUAL)
-
-Scan {{PROJECT_PATH}} for code quality issues that affect security/reliability.
-
-CHECK FOR:
-- Error handling swallowing exceptions silently
-- Missing error boundaries
-- Inconsistent error responses
-- Dead code with security implications
-- DRY violations in security code
-- Complex functions (high cyclomatic complexity)
-- Any/unknown types masking issues
-- Missing null checks
-- Callback hell making auditing hard
-- Anti-patterns (god objects, tight coupling)
-
-**DEAD CODE WITH SECURITY IMPLICATIONS** (CRITICAL):
-- Old/commented code that has BETTER security than current code
-- Deprecated functions with security controls not ported to replacement
-- Legacy validation code that was more thorough
-- Backup implementations with different (better) security model
-- TODO/FIXME comments about security issues never addressed
-
-Look for patterns:
-- `// OLD: validated input here` followed by code that doesn't
-- Functions named `*_secure`, `*_safe`, `*_v2` that are unused
-- Commented-out security checks with no explanation
-- Multiple implementations where one is more secure but unused
-
-**SECURITY-CRITICAL CODE WITHOUT TESTS**:
-- Authentication/authorization code with 0% test coverage
-- Input validation functions without unit tests
-- Cryptographic operations without test vectors
-- Rate limiting logic without integration tests
-
-For EACH finding, output the FULL JSON format.
-
----
-
-### AGENT 10: Testing & Reliability Scanner (ID prefix: TEST)
-
-Scan {{PROJECT_PATH}} for testing and reliability gaps.
-
-CHECK FOR:
-- Missing tests for security-critical paths
-- No CI quality gates
-- Missing health checks
-- No graceful shutdown handling
-- Circuit breakers missing
-- Retry logic without exponential backoff
-- Missing observability (logging, metrics, tracing)
-- Feature flags without cleanup
-- Database migrations without rollback
-- No chaos/failure testing evidence
-
-For EACH finding, output the FULL JSON format.
-
----
-
-### AGENT 11: Redis & Cache Security Scanner (ID prefix: REDIS)
-
-**CONDITIONAL AGENT** - First detect if this project uses Redis/Cache:
-
-```bash
-# Search for Redis/Cache indicators
-grep -r -l "redis\|ioredis\|memcached\|node-cache\|lru-cache\|cache-manager" --include="*.ts" --include="*.js" --include="*.json" --include="*.yaml" .
-```
-
-**IF NO CACHE CODE FOUND**: Output and skip:
-```json
-{"skipped": true, "reason": "No Redis/Cache code detected in project", "findings": []}
-```
-
-**IF CACHE CODE FOUND**: Scan {{PROJECT_PATH}} for Redis, Memcached, and cache-related security issues.
-
-**REDIS SECURITY:**
-
-**DANGEROUS COMMANDS:**
-- `KEYS *` in production code (blocks entire server, use SCAN instead)
-- `FLUSHALL`, `FLUSHDB` accessible without protection
-- `DEBUG`, `CONFIG` commands enabled in production
-- `EVAL`/`EVALSHA` with user-controlled scripts (Lua injection)
-- `MIGRATE` command enabled (data exfiltration risk)
-
-**AUTHENTICATION & ACCESS:**
-- Redis without AUTH (requirepass not set)
-- Redis exposed on 0.0.0.0 instead of 127.0.0.1
-- Missing ACL configuration (Redis 6+)
-- Default port 6379 exposed externally
-- Missing TLS for Redis connections
-- Connection strings with passwords in code/logs
-
-**DATA SECURITY:**
-- Sensitive data stored without encryption
-- PII in Redis without TTL (data retention violation)
-- Session data without proper expiration
-- Cache keys predictable/enumerable (info disclosure)
-- No key prefix separation between tenants (multi-tenant leak)
-
-**RACE CONDITIONS:**
-- Non-atomic read-modify-write patterns
-- Missing WATCH/MULTI/EXEC for transactions
-- INCR + EXPIRE not atomic (use SET with NX and EX)
-- Distributed locks without proper implementation (SETNX issues)
-
-**MEMORY & DoS:**
-- No maxmemory configuration
-- No eviction policy (maxmemory-policy)
-- Unbounded lists/sets that can grow infinitely
-- Missing key expiration (TTL) for temporary data
-- Pub/Sub without subscriber limits
-
-**SERIALIZATION:**
-- Pickle/Marshal deserialization from Redis (RCE risk)
-- JSON parsing without validation
-- Protobuf/MessagePack without schema validation
-
-Example finding:
-```json
-{
-  "id": "REDIS-001",
-  "title": "Redis KEYS command used in production",
-  "severity": "high",
-  "fixOwner": "developer",
-  "fixType": "code",
-  "file": "src/cache/redis.ts",
-  "line": 45,
-  "code": "await redis.keys('user:*')",
-  "description": "KEYS command blocks the entire Redis server. With large datasets this can cause seconds of downtime.",
-  "recommendation": "Use SCAN with cursor-based iteration instead: `for await (const key of redis.scanIterator({ MATCH: 'user:*' }))`"
-}
-```
-
-For EACH finding, output the FULL JSON format.
-
----
-
-### AGENT 12: Resilience & Fallback Scanner (ID prefix: RESIL)
-
-Scan {{PROJECT_PATH}} for resilience patterns and fallback mechanisms.
-
-**CIRCUIT BREAKERS:**
-- External service calls without circuit breaker
-- Circuit breaker without proper thresholds
-- No fallback when circuit is open
-- Missing health check for circuit recovery
-- Circuit breaker state not monitored/alerted
-
-**RETRY PATTERNS:**
-- Retries without exponential backoff
-- Retries without jitter (thundering herd)
-- Retries without max attempts limit
-- Retrying non-idempotent operations
-- No retry budget (retry storms)
-
-**TIMEOUTS:**
-- HTTP calls without timeout
-- Database queries without timeout
-- External API calls without timeout
-- Cascading timeouts not configured properly
-- Timeout longer than upstream caller's timeout
-
-**FALLBACKS:**
-- No fallback for critical external dependencies
-- Fallback that calls same failing service
-- Missing cached fallback data
-- No degraded mode implementation
-- Feature flags without fallback behavior
-
-**BULKHEADS:**
-- Single connection pool for all operations
-- No isolation between critical and non-critical paths
-- Thread/worker pool exhaustion possible
-- No request queuing limits
-- Missing backpressure handling
-
-**GRACEFUL DEGRADATION:**
-- All-or-nothing service behavior
-- No partial response capability
-- Missing feature flags for degradation
-- No read-only mode fallback
-- Essential vs non-essential features not separated
-
-**HEALTH CHECKS:**
-- Health check that calls external dependencies
-- No distinction between liveness and readiness
-- Health check timeout too short/long
-- Missing dependency health in readiness check
-- Health endpoint exposed without rate limiting
-
-Example finding:
-```json
-{
-  "id": "RESIL-001",
-  "title": "External API call without circuit breaker",
-  "severity": "medium",
-  "fixOwner": "developer",
-  "fixType": "code",
-  "file": "src/services/payment.ts",
-  "line": 78,
-  "code": "await axios.post(paymentApi, data)",
-  "description": "Payment API calls have no circuit breaker. If the API is slow/down, requests will pile up and exhaust resources.",
-  "recommendation": "Wrap with circuit breaker: `const result = await circuitBreaker.fire(() => axios.post(...))`"
-}
-```
-
-For EACH finding, output the FULL JSON format.
-
----
-
-### AGENT 13: PII & Sensitive Data Scanner (ID prefix: PII)
-
-Scan {{PROJECT_PATH}} for PII exposure and sensitive data handling issues.
-
-**PII IN LOGS:**
-- Email addresses logged
-- Phone numbers logged
-- IP addresses logged without justification
-- Names/addresses in logs
-- User IDs that can be linked to PII
-- Request/response bodies logged without redaction
-- Error messages containing PII
-
-**PII IN URLS:**
-- PII in URL path (e.g., /user/john@email.com)
-- PII in query parameters
-- Session tokens in URLs (referer leak)
-- Sensitive data in URL fragments
-
-**PII IN STORAGE:**
-- PII stored without encryption at rest
-- PII in plaintext in database
-- PII in local storage/session storage (browser)
-- PII in cookies without encryption
-- Backup data containing unencrypted PII
-
-**PII IN TRANSIT:**
-- PII sent over non-HTTPS connections
-- PII in WebSocket without TLS
-- PII in email notifications (plaintext)
-- PII passed to third-party services without DPA
-
-**PII RETENTION:**
-- No TTL on PII data
-- No data deletion mechanism
-- Soft delete keeping PII accessible
-- Audit logs retaining PII indefinitely
-- Analytics containing raw PII
-
-**GDPR/CCPA COMPLIANCE:**
-- No data export functionality
-- No data deletion on request
-- Missing consent tracking
-- No purpose limitation enforcement
-- PII shared without consent
-
-**SENSITIVE DATA TYPES TO FIND:**
-- SSN, passport numbers, national IDs
-- Credit card numbers (even partial)
-- Bank account numbers
-- Health/medical information
-- Biometric data
-- Location data (precise GPS)
-- Authentication credentials
-- API keys/tokens
-
-**DETECTION PATTERNS:**
-```
-email: /[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}/
-phone: /(\+\d{1,3}[-.\s]?)?\(?\d{3}\)?[-.\s]?\d{3}[-.\s]?\d{4}/
-ssn: /\d{3}[-]?\d{2}[-]?\d{4}/
-credit_card: /\d{4}[-\s]?\d{4}[-\s]?\d{4}[-\s]?\d{4}/
-ip_address: /\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}/
-```
-
-For EACH finding, output the FULL JSON format.
-
----
-
-### AGENT 14: Dead Code & Unused Scanner (ID prefix: DEAD)
-
-Scan {{PROJECT_PATH}} for dead code, unused dependencies, and technical debt.
-
-**UNUSED CODE:**
-- Functions never called
-- Classes never instantiated
-- Variables assigned but never read
-- Exported functions with no importers
-- Event handlers never triggered
-- API endpoints not used by any client
-
-**COMMENTED CODE:**
-- Large blocks of commented-out code
-- TODO/FIXME comments older than 6 months
-- "Temporary" code that became permanent
-- Debug code left in production
-- Console.log/print statements
-
-**UNUSED DEPENDENCIES:**
-- npm/pip packages installed but never imported
-- Devdependencies in production bundle
-- Duplicate dependencies (different versions)
-- Dependencies imported but functions not used
-- Polyfills for supported browser versions
-
-**UNREACHABLE CODE:**
-- Code after return/throw/break
-- Conditions that are always true/false
-- Switch cases that can never match
-- Error handlers that can never trigger
-- Feature flags that are always on/off
-
-**DEAD FEATURE FLAGS:**
-- Feature flags that are always enabled (remove flag)
-- Feature flags that are always disabled (remove code)
-- Feature flags with no owner
-- A/B tests that concluded but weren't cleaned up
-
-**DEPRECATED PATTERNS:**
-- Using deprecated APIs (with console warnings)
-- Legacy code paths kept "just in case"
-- Backward compatibility code for old versions
-- Shims for removed features
-
-**SECURITY IMPLICATIONS:**
-- Commented security checks (why removed?)
-- Unused auth middleware (was security removed?)
-- Dead validation code (security regression?)
-- Unused rate limiting (intentional removal?)
-
-**TECHNICAL DEBT INDICATORS:**
-- Files not modified in >2 years
-- Code with "hack", "workaround", "temporary" comments
-- Duplicate implementations of same logic
-- Copy-pasted code blocks
-
-Example finding:
-```json
-{
-  "id": "DEAD-001",
-  "title": "Unused npm dependency: lodash",
-  "severity": "low",
-  "fixOwner": "developer",
-  "fixType": "code",
-  "file": "package.json",
-  "line": 15,
-  "description": "lodash is listed as dependency but no imports found in codebase. Increases bundle size and potential security surface.",
-  "recommendation": "Remove with: npm uninstall lodash"
-}
-```
-
-For EACH finding, output the FULL JSON format.
-
----
-
-### AGENT 15: Database Security Scanner (ID prefix: DB)
-
-**AUTO-DETECT DATABASE TYPE(S)** - First identify which database(s) this project uses:
-
-| Database | Detection Pattern |
-|----------|-------------------|
-| PostgreSQL | `pg`, `postgres`, `@prisma`, `typeorm`, `knex`, `DATABASE_URL.*postgres` |
-| MySQL | `mysql`, `mysql2`, `mariadb` |
-| SQLite | `sqlite`, `better-sqlite3`, `sql.js` |
-| MongoDB | `mongoose`, `mongodb`, `@mongo` |
-| DynamoDB | `@aws-sdk/client-dynamodb`, `dynamodb`, `DocumentClient` |
-| Redis | `redis`, `ioredis` |
-| Elasticsearch | `@elastic`, `elasticsearch` |
-| DuckDB | `duckdb`, `@duckdb` |
-| Supabase | `@supabase/supabase-js`, `supabase`, `createClient.*supabase` |
-| Prisma | `@prisma/client` |
-| TypeORM | `typeorm`, `@Entity` |
-| Sequelize | `sequelize` |
-| Drizzle | `drizzle-orm` |
-| PlanetScale | `@planetscale`, `planetscale` |
-| Neon | `@neondatabase`, `neon` |
-| Turso | `@libsql`, `turso` |
-
-**IF NO DATABASE FOUND**: Output and skip:
-```json
-{"skipped": true, "reason": "No database code detected in project", "findings": []}
-```
-
-**IF DATABASE FOUND**: Scan for issues SPECIFIC to the detected database type(s).
-
-Scan {{PROJECT_PATH}} for database security issues across all database types.
-
-**SQL INJECTION (all SQL databases):**
-- String concatenation in queries
-- Template literals with user input in SQL
-- Raw queries without parameterization
-- Dynamic table/column names from user input
-- ORDER BY with user-controlled column names
-- LIMIT/OFFSET from unvalidated user input
-
-**NOSQL INJECTION:**
-- MongoDB: $where with user input
-- MongoDB: $regex with user-controlled patterns
-- MongoDB: operator injection ({$gt: ""})
-- DynamoDB: condition expressions with user input
-- Elasticsearch: query string queries with user input
-
-**DANGEROUS DATABASE FUNCTIONS:**
-```
-PostgreSQL: pg_read_file(), pg_ls_dir(), COPY TO/FROM, lo_import/export
-MySQL: LOAD_FILE(), INTO OUTFILE, INTO DUMPFILE, LOAD DATA
-SQLite: load_extension(), readfile(), writefile()
-DuckDB: read_text(), read_blob(), read_csv_auto(), read_parquet(), glob(), httpfs
-MongoDB: $where, mapReduce with user functions
-Redis: EVAL with user scripts, CONFIG, DEBUG
-```
-
-**ACCESS CONTROL:**
-- Database user with excessive privileges (GRANT ALL)
-- Application using root/admin database user
-- Same credentials for read and write operations
-- No row-level security (RLS) for multi-tenant
-- Missing column-level encryption for sensitive data
-
-**CONNECTION SECURITY:**
-- Database connection without TLS/SSL
-- Connection strings with credentials in code
-- Connection pooling without limits
-- No connection timeout configured
-- Database exposed on public IP
-
-**QUERY PATTERNS:**
-- SELECT * instead of specific columns
-- No LIMIT on SELECT queries
-- Missing indexes on filtered columns
-- N+1 query patterns
-- Full table scans in request handlers
-- Unbounded JOINs
-
-**MIGRATIONS & SCHEMA:**
-- Migrations without rollback capability
-- Schema changes without backup
-- Dropping columns with data
-- Changing column types without data migration
-- Foreign keys without ON DELETE policy
-
-**DATA INTEGRITY:**
-- Missing foreign key constraints
-- No unique constraints where needed
-- Missing NOT NULL on required fields
-- No CHECK constraints for data validation
-- Orphan records possible
-
-**BACKUP & RECOVERY:**
-- No backup configuration found
-- Backups not encrypted
-- No point-in-time recovery capability
-- Backup credentials in code
-- No backup verification/testing
-
-**ORM SPECIFIC:**
-```javascript
-// Prisma - raw queries
-prisma.$queryRaw`SELECT * FROM users WHERE id = ${userId}` // SAFE
-prisma.$queryRawUnsafe(`SELECT * FROM users WHERE id = ${userId}`) // VULNERABLE
-
-// Sequelize - raw queries
-sequelize.query(`SELECT * FROM ${table}`) // VULNERABLE if table is user input
-
-// TypeORM - raw queries
-repository.query(`SELECT * FROM users WHERE name = '${name}'`) // VULNERABLE
-
-// Mongoose - operator injection
-User.find({ username: req.body.username }) // VULNERABLE to {$gt: ""}
-```
-
-**AUDIT & LOGGING:**
-- No audit logging for sensitive operations
-- Query logging including sensitive data
-- No tracking of who accessed what data
-- Missing created_at/updated_at timestamps
-- No soft delete (audit trail lost)
-
-Example finding:
-```json
-{
-  "id": "DB-001",
-  "title": "SQL injection via string concatenation",
-  "severity": "critical",
-  "fixOwner": "developer",
-  "fixType": "code",
-  "file": "src/repositories/user.ts",
-  "line": 34,
-  "code": "db.query(`SELECT * FROM users WHERE id = ${userId}`)",
-  "description": "User ID is concatenated directly into SQL query, allowing SQL injection attacks.",
-  "recommendation": "Use parameterized query: db.query('SELECT * FROM users WHERE id = $1', [userId])"
-}
-```
-
-For EACH finding, output the FULL JSON format.
-
----
-
-### AGENT 16: Network & Architecture Scanner (ID prefix: ARCH)
-
-Scan {{PROJECT_PATH}} for network architecture and service boundary issues.
-
-**CRITICAL DISTINCTION - Code vs Infrastructure fixes:**
-
-For EACH finding, determine:
-- Is this fixable by changing CODE? → fixOwner: "developer"
-- Is this fixable by NetworkPolicy/firewall/K8s config? → fixOwner: "devops"
-- Does this need architecture redesign? → fixOwner: "architect"
-
-CHECK FOR:
-
-**SERVICE BOUNDARIES:**
-- Internal endpoints exposed externally (should be internal-only)
-- Missing network segmentation between services
-- Service-to-service communication without mTLS
-- Internal IPs hardcoded instead of service discovery
-- Admin/debug ports accessible from outside
-
-**TRUST BOUNDARIES:**
-- Which endpoints are meant to be internal-only?
-- Are internal endpoints protected by network policy OR code auth?
-- Document the INTENDED architecture, not just what's missing
-
-**KUBERNETES/INFRASTRUCTURE:**
-- Missing NetworkPolicies for namespace isolation
-- Services using ClusterIP that should be internal
-- LoadBalancer exposing internal services
-- Missing Ingress rules for path-based routing
-- Pod-to-pod communication without restrictions
-
-**FOR EACH FINDING, specify:**
-```json
-{
-  "fixOwner": "devops",
-  "fixType": "infrastructure",
-  "recommendation": "Add NetworkPolicy to restrict /api/v1/internal/* to enclave namespace only",
-  "notCodeFix": true
-}
-```
-
-If you find an endpoint that lacks authentication but is INTENDED to be protected by network policy:
-- Mark as fixOwner: "devops", NOT "developer"
-- Recommendation should be NetworkPolicy, NOT code auth
-- Add note: "Protected by network segmentation - verify NetworkPolicy exists"
-
-For EACH finding, output the FULL JSON format.
-
----
-
-### AGENT 17: Design Decision Detector (ID prefix: DESIGN)
-
-Scan {{PROJECT_PATH}} for intentional design decisions that might look like bugs.
-
-**GOAL: Prevent false positives by identifying documented/intentional patterns**
-
-CHECK FOR:
-
-**DOCUMENTED DECISIONS:**
-- Comments explaining WHY something is done a certain way
-- README/docs explaining architecture choices
-- ADR (Architecture Decision Records) files
-- SECURITY.md or similar documentation
-
-**INTENTIONAL PATTERNS:**
-- Content filtering disabled with comment "for transparency"
-- Auth bypassed for specific endpoints with documentation
-- Longer session timeouts with business justification
-- Relaxed validation with explicit reason
-
-**CODE PATTERNS THAT ARE NOT BUGS:**
-- `// Intentional: ....` or `// Design decision: ...`
-- `// SECURITY: This is safe because...`
-- `// TODO: This is acceptable for now because...`
-- Feature flags controlling security features with documentation
-
-**FOR EACH PATTERN FOUND, output:**
-```json
-{
-  "id": "DESIGN-001",
-  "type": "documented_decision",
-  "title": "Content filtering disabled",
-  "file": "src/ai/chat.ts",
-  "line": 45,
-  "reason": "Documented in code comment: 'Disabled for transparency, users see raw AI output'",
-  "relatedFindings": ["AI-001"],
-  "recommendation": "Not a bug - document in security overview as accepted risk"
-}
-```
-
-These findings will be EXCLUDED from the main report and moved to "Design Decisions" section.
-
----
-
-### AGENT 18: Context-Aware Validator (ID prefix: CTX)
-
-Scan {{PROJECT_PATH}} to understand the CONTEXT of each potential finding.
-
-**GOAL: Reduce false positives by understanding deployment context**
-
-FOR EACH FINDING FROM OTHER AGENTS, determine:
-
-**DEPLOYMENT CONTEXT:**
-- Is this code running in a container with network isolation?
-- Is this behind an API gateway that handles auth?
-- Is this internal-only service behind VPN?
-- Is there a WAF/CDN in front that mitigates this?
-
-**RUNTIME CONTEXT:**
-- Is this code path actually reachable in production?
-- Is this only used in development/testing?
-- Is this dead code or deprecated?
-- Is this protected by feature flag that's disabled?
-
-**DATA FLOW CONTEXT:**
-- Is the input already validated upstream?
-- Is the output sanitized downstream?
-- Is there middleware that applies to this route?
-
-**OUTPUT:**
-```json
-{
-  "findingId": "SEC-001",
-  "contextAnalysis": {
-    "deploymentContext": "Runs in K8s with NetworkPolicy restricting access",
-    "runtimeContext": "Only reachable from internal services",
-    "dataFlowContext": "Input validated by Zod at API gateway level",
-    "verdict": "false_positive|confirmed|needs_review",
-    "reason": "Protected by network policy - not externally accessible"
-  }
-}
-```
-
----
-
-### AGENT 19: Enclave & Trusted Compute Scanner (ID prefix: ENC)
-
-**CONDITIONAL AGENT** - First detect if this project uses enclaves/TEE:
-
-```bash
-# Search for enclave/TEE indicators
-grep -r -l "enclave\|nitro\|sgx\|tee\|attestation\|trusted.compute\|confidential.computing\|vsock" --include="*.ts" --include="*.js" --include="*.py" --include="*.yaml" --include="*.yml" .
-```
-
-**IF NO ENCLAVE CODE FOUND**: Output and skip:
-```json
-{"skipped": true, "reason": "No enclave/TEE code detected in project", "findings": []}
-```
-
-**IF ENCLAVE CODE FOUND**: Scan {{PROJECT_PATH}} for enclave/TEE/trusted compute specific patterns.
-
-CHECK FOR:
-
-**ENCLAVE REGISTRATION:**
-- Enclave-to-backend registration without attestation
-- IP-based trust without cryptographic verification
-- Missing remote attestation flow
-- Enclave secrets transmitted without encryption
-
-**TRUST MODEL:**
-- What is the trust boundary between enclave and host?
-- Is the communication channel authenticated?
-- Are enclave outputs verified?
-
-**SPECIFIC PATTERNS:**
-- /register endpoints for enclave → backend (common pattern)
-- Heartbeat/health endpoints from enclave
-- Configuration push to enclave
-
-**FOR ENCLAVE ENDPOINTS, determine:**
-- Is this MEANT to be protected by network only? → Note in finding
-- Is attestation planned but not implemented? → Check TODOs/roadmap
-- Is this MVP/temporary solution? → Check for documentation
-
-Output findings with proper fixOwner:
-- Network protection needed → fixOwner: "devops"
-- Attestation needed → fixOwner: "architect" (design change)
-- Code validation needed → fixOwner: "developer"
-
----
-
-### AGENT 20: Executive Summary Generator (ID prefix: EXEC)
-
-After all other agents complete, generate an executive summary **written for leadership** — technically precise but accessible.
-
-**WRITING GUIDELINES:**
-- The `overview` field should read like a professional security consultant's opening paragraph
-- Start with 1 sentence describing what the project IS (architecture, purpose)
-- Then state the overall security posture clearly
-- Then list the most significant remaining issues in one sentence
-- Use specific numbers and technical details, not vague language
-
-**EXAMPLE of professional executive summary overview:**
-"Express-AI Officely is a confidential AI platform built on a three-tier encrypted architecture: a Next.js frontend with BFF pattern, an Express.js API gateway on EKS, and backend enclaves running inside AMD SEV-SNP encrypted VMs. No critical vulnerabilities remain. The most significant remaining issues are: unauthenticated enclave registration endpoints that could allow enclave impersonation (mitigated by network-level whitelisting), hardcoded secrets in Helm values, a monolithic 1000+ line chat handler creating maintenance risk, 3,200 lines of dead or duplicated code (5.3% of the codebase), and zero test coverage across all components."
-
-**TOP RISKS writing quality:**
-Each risk must be a specific, actionable description — not a generic category.
-- BAD: "SQL injection vulnerability"
-- GOOD: "Unauthenticated enclave registration endpoints could allow impersonation (mitigated by network whitelisting)"
-- GOOD: "160 lines of Redis metrics tracking duplicated verbatim between streaming/non-streaming paths"
-
-**OUTPUT FORMAT:**
-```json
-{
-  "executiveSummary": {
-    "headline": "0 Critical + 7 High findings — platform hardened but key gaps remain",
-    "riskLevel": "HIGH",
-    "overview": "Professional 2-3 sentence summary as described above.",
-    "topRisks": [
-      "Specific risk description with technical detail and context",
-      "Another risk with file reference and impact quantification",
-      "Third risk with mitigation status noted if partial"
-    ],
-    "positives": [
-      "Specific strength with technical evidence — not generic praise",
-      "Another strength citing specific libraries/patterns/algorithms"
-    ],
-    "recommendedActions": [
-      {
-        "priority": 1,
-        "action": "Remove hardcoded secrets from Helm values. Move to Secrets Manager. Rotate keys immediately.",
-        "owner": "devops",
-        "effort": "2-4 hours"
-      },
-      {
-        "priority": 2,
-        "action": "Add shared-secret or mTLS auth to enclave status/register endpoints",
-        "owner": "architect",
-        "effort": "1-2 days"
-      }
-    ],
-    "byOwner": {
-      "developer": 5,
-      "devops": 3,
-      "architect": 1
-    },
-    "priorityRoadmap": {
-      "P0_immediate": {
-        "description": "Fix this sprint - security critical",
-        "findings": ["SEC-001", "AUTH-003"],
-        "effort": "1-2 days"
-      },
-      "P1_short_term": {
-        "description": "Fix within 2 weeks - high priority",
-        "findings": ["API-002", "INFRA-005"],
-        "effort": "3-5 days"
-      },
-      "P2_medium_term": {
-        "description": "Fix within month - important",
-        "findings": ["QUAL-001", "DEAD-003"],
-        "effort": "1 week"
-      },
-      "P3_backlog": {
-        "description": "Address when capacity allows",
-        "findings": ["TEST-001"],
-        "effort": "ongoing"
-      }
-    }
-  }
-}
-```
-
-**Priority Assignment Rules:**
-- **P0 (Immediate)**: CRITICAL severity, actively exploitable, data breach risk
-- **P1 (Short-term)**: HIGH severity, requires auth to exploit, compliance risk
-- **P2 (Medium-term)**: MEDIUM severity, defense-in-depth, code quality
-- **P3 (Backlog)**: LOW/INFO severity, nice-to-have improvements
-
----
-
-### AGENT 22: Runtime Verification Scanner (ID prefix: RUNTIME)
-
-**CONDITIONAL AGENT** - Only runs if SSH is configured in Phase 0.
-
-Check if runtime.json was found in Phase 0:
-- If NO runtime.json → Skip this agent entirely
-- If runtime.json exists → Proceed with runtime verification
-
-**PURPOSE**: Find dangerous mismatches between code configuration and actual runtime environment.
-
-**Example of what this catches:**
-> The code says `USER appuser` in Dockerfile, but the container actually runs as `root`.
-> This is why a DuckDB file read vulnerability could access /etc/passwd!
-
----
-
-**STEP 1: Gather Code Expectations**
-
-Analyze configuration files to understand EXPECTED runtime state:
+### Step 1: Understand the Project
 
 ```bash
-# Dockerfile
-grep -E "^USER|^EXPOSE|^ENV" Dockerfile 2>/dev/null
+mkdir -p .coverme
 
-# Docker Compose
-grep -E "user:|ports:|environment:" docker-compose*.yml 2>/dev/null
-
-# Kubernetes
-grep -E "runAsUser|runAsNonRoot|readOnlyRootFilesystem|securityContext" k8s/*.yaml helm/**/values.yaml 2>/dev/null
-
-# PM2
-grep -E "user|uid|cwd" ecosystem.config.js pm2.config.js 2>/dev/null
+# Project structure
+ls -la
+find . -maxdepth 2 -type d -not -path "*/node_modules/*" -not -path "*/.git/*" -not -path "*/dist/*" 2>/dev/null | head -40
 
-# Systemd
-grep -E "^User=|^Group=" *.service 2>/dev/null
-```
+# Count files
+find . -type f \( -name "*.ts" -o -name "*.js" -o -name "*.tsx" -o -name "*.py" -o -name "*.go" \) -not -path "*/node_modules/*" -not -path "*/.git/*" 2>/dev/null | wc -l
 
-Build expected state:
-```json
-{
-  "expected": {
-    "user": "appuser",
-    "uid": 1000,
-    "runAsRoot": false,
-    "readOnlyFs": true,
-    "ports": [3000],
-    "source": "Dockerfile:15 - USER appuser"
-  }
-}
+# Tech stack
+cat package.json 2>/dev/null | head -40
 ```
 
----
-
-**STEP 2: SSH and Check Actual Runtime**
-
-Use the SSH configuration from runtime.json:
+### Step 2: Find Critical Files
 
 ```bash
-# Build SSH command (from runtime.json)
-# host: user@server.com, port: 22, keyPath: ~/.ssh/id_rsa
-
-# Check who is running the process
-ssh user@server.com "ps -eo user,pid,cmd | grep -E 'node|python|java|pm2' | head -5"
-
-# Check Docker container user
-ssh user@server.com "docker ps -q | head -1 | xargs -I {} docker exec {} id"
-
-# Check Kubernetes pod user
-ssh user@server.com "kubectl get pods -o name | head -1 | xargs -I {} kubectl exec {} -- id"
-
-# Check file permissions
-ssh user@server.com "ls -la /app/ 2>/dev/null | head -10"
-
-# Check listening ports
-ssh user@server.com "ss -tlnp | grep -E ':3000|:8080|:6379'"
-```
-
-Build actual state:
-```json
-{
-  "actual": {
-    "user": "root",
-    "uid": 0,
-    "runAsRoot": true,
-    "readOnlyFs": false,
-    "ports": [3000, 6379],
-    "evidence": "uid=0(root) gid=0(root)"
-  }
-}
-```
-
----
-
-**STEP 3: Compare and Generate Findings**
-
-| Mismatch | Severity | ID |
-|----------|----------|-----|
-| Code says non-root, runs as root | CRITICAL | RUNTIME-001 |
-| Dockerfile USER ignored | CRITICAL | RUNTIME-002 |
-| K8s runAsNonRoot:true but runs as root | HIGH | RUNTIME-003 |
-| ReadOnlyRootFilesystem not enforced | HIGH | RUNTIME-004 |
-| Unexpected ports exposed | MEDIUM | RUNTIME-005 |
-| File permissions too open (777) | MEDIUM | RUNTIME-006 |
-| Environment variables mismatch | LOW | RUNTIME-007 |
-
-**Output Format:**
-```json
-{
-  "id": "RUNTIME-001",
-  "title": "Container running as root despite USER directive",
-  "severity": "critical",
-  "category": "runtime-mismatch",
-  "fixOwner": "devops",
-  "fixType": "infrastructure",
-
-  "expected": {
-    "value": "appuser (uid 1000)",
-    "source": "Dockerfile:15",
-    "code": "USER appuser"
-  },
-
-  "actual": {
-    "value": "root (uid 0)",
-    "command": "docker exec container id",
-    "evidence": "uid=0(root) gid=0(root)"
-  },
-
-  "description": "The Dockerfile specifies USER appuser, but the container runs as root. This likely means docker-compose or K8s overrides the user.",
-
-  "impact": "Running as root means any code vulnerability can access ALL system files. The DuckDB read_text() issue could read /etc/shadow, SSH keys, or any file on the system.",
-
-  "recommendation": "1. Remove user: root from docker-compose.yml\n2. Add securityContext.runAsNonRoot: true to K8s deployment\n3. Verify no --user root in docker run commands",
-
-  "verification": {
-    "codeFile": "Dockerfile:15",
-    "sshCommand": "docker exec container_name id",
-    "sshOutput": "uid=0(root) gid=0(root)"
-  }
-}
-```
-
----
-
-## PHASE 2: DUPLICATE & EXISTING SOLUTIONS CHECK
-
-### AGENT 21: Duplicate & Existing Solutions Scanner (ID prefix: DUP)
-
-CRITICAL: Before recommending ANY fix, check if a solution ALREADY EXISTS in the codebase.
-
-For EVERY finding from Phase 1, search the codebase for:
-
-1. **Existing utilities/helpers that solve this**:
-   - Search for similar function names (sanitize, validate, escape, hash, encrypt)
-   - Check utils/, helpers/, lib/, common/ folders
-   - Look for imported libraries that handle this
-
-2. **Existing patterns in the codebase**:
-   - How do OTHER files handle the same issue?
-   - Is there a project-wide convention?
-   - Are there shared middleware/decorators?
-
-3. **Configuration that already exists**:
-   - Check if there's a config for this (CSP headers, CORS, rate limits)
-   - Look in config/, .env files, infrastructure code
-
-4. **Duplicate findings & Cross-References**:
-   - Is this the same issue reported multiple times?
-   - Are multiple findings actually ONE root cause?
-   - **Create CR-xx IDs** when same issue found by multiple agents
-
-**Cross-Reference (CR-xx) Rules:**
-When two or more agents find the SAME underlying issue from different perspectives:
-1. Create a cross-reference ID: `CR-01`, `CR-02`, etc.
-2. Merge into single finding with dual ID: `"CR-02 / T-EKS-3"`
-3. Use the most descriptive title
-4. Combine descriptions from both perspectives
-5. Use the higher DREAD score
-6. Add both original IDs to `crossReferences` array
-
-**Examples of cross-references:**
-- SEC finds "hardcoded API key" + INFRA finds same key in Helm → `CR-01 / SEC-005 / INFRA-003`
-- AUTH finds "missing MFA" + BIZ finds "MFA bypass flow" → Keep separate but add crossReferences
-- QUAL finds "DRY violation" + PERF finds same duplicated code → Merge as `CR-02`
-
-For EACH finding, add to the checkBefore field:
-- "EXISTING: Found sanitizeHtml() in src/utils/security.ts - use this instead of creating new"
-- "PATTERN: Other files use zod.string().email() for validation - follow same pattern"
-- "DUPLICATE: This is same root cause as SEC-003, fix once in middleware"
-- "CONFIG: Rate limiting already configured in src/middleware/rateLimit.ts line 15"
-
-If NO existing solution found, state: "VERIFIED: No existing solution found, new implementation needed"
-
-Output for each finding:
-```json
-{
-  "findingId": "SEC-001",
-  "existingSolution": "Found: src/utils/sanitize.ts exports sanitizeUserInput()",
-  "duplicateOf": null,
-  "crossReferenceId": null,
-  "relatedFindings": ["INFRA-003"],
-  "suggestedApproach": "Import and use existing sanitizeUserInput() instead of creating new function",
-  "checkBefore": "1. Verify sanitizeUserInput() handles this case 2. Check if it's already imported"
-}
-```
-
-**Cross-Reference output when merging:**
-```json
-{
-  "crossReference": {
-    "id": "CR-02",
-    "mergedFindings": ["SEC-005", "INFRA-003"],
-    "title": "Hardcoded Tracker API Keys in Helm Values and Backend Code",
-    "reason": "Same hardcoded key found in both application code and infrastructure config"
-  }
-}
-```
-
----
-
-## PHASE 3: MITIGATION VALIDATION (CRITICAL)
-
-**This phase determines if findings are ACTUALLY exploitable or if other code prevents the attack.**
-
-### Validator M: Mitigation Hunter
-
-For EVERY finding from Phase 1+2, actively search the codebase for mitigations:
-
-#### Search Checklist:
-1. **Input Validation** - Is input sanitized before reaching the vulnerable sink?
-   ```bash
-   grep -r "validate|sanitize|escape|Zod|Joi|yup" src/
-   ```
-
-2. **Middleware Protection** - Is there middleware that protects this route?
-   ```bash
-   grep -r "app.use|helmet|csrf|rateLimit" src/
-   ```
-
-3. **Framework Auto-Protection** - Does the framework handle this automatically?
-   - React JSX auto-escapes (unless dangerouslySetInnerHTML)
-   - Prisma/TypeORM parameterize queries automatically
-   - Next.js API routes have built-in protections
-
-4. **Route Protection** - Is the endpoint protected by auth/authorization?
-   ```bash
-   grep -r "requireAuth|isAdmin|authorize" src/
-   ```
-
-5. **Configuration** - Is there security config that applies?
-   - CSP headers blocking XSS
-   - CORS restricting origins
-   - Rate limiting preventing abuse
-
-#### Output Per Finding:
-```json
-{
-  "findingId": "SEC-001",
-  "verdict": "mitigated|partial|confirmed|false_positive",
-  "mitigationType": "input_validation|middleware|framework|config|none",
-  "evidence": [
-    "Found Zod validation at src/routes/user.ts:23",
-    "Schema restricts input to alphanumeric only",
-    "XSS payload would fail validation"
-  ],
-  "adjustedSeverity": "low",
-  "codeReferences": [
-    {"file": "src/middleware/validate.ts", "line": 45}
-  ]
-}
-```
-
-**Verdicts:**
-- `mitigated` - Another control fully prevents the attack → Remove from report or mark as INFO
-- `partial` - Some protection but can be bypassed → Keep but may downgrade severity
-- `confirmed` - No mitigation found → Keep original severity
-- `false_positive` - Finding is incorrect (test file, dead code, etc.) → Remove
-
----
-
-## PHASE 4: CROSS-VALIDATION
-
-Launch 3 validators IN PARALLEL after Phase 3 completes:
-
-### Validator A: False Positive & Duplicate Hunter
-
-Review ALL findings that passed Phase 3 (not mitigated).
-For each finding determine if it's FALSE POSITIVE or DUPLICATE:
-- Is the code actually reachable?
-- Is the context misunderstood?
-- Is this a DUPLICATE of another finding? (same root cause)
-- Does an EXISTING SOLUTION already exist in the codebase?
-
-If existing solution found, mark as "use_existing" not "fix_new".
+# Auth files
+find . -type f \( -name "*auth*" -o -name "*session*" -o -name "*jwt*" -o -name "*login*" \) -not -path "*/node_modules/*" 2>/dev/null | head -15
 
-Output:
-```json
-{
-  "confirmed": ["SEC-001", "AUTH-002"],
-  "useExisting": [
-    {"id": "SEC-005", "existingSolution": "src/utils/sanitize.ts", "reason": "sanitizeHtml() already exists"}
-  ],
-  "duplicates": [
-    {"id": "SEC-007", "duplicateOf": "SEC-003", "reason": "Same XSS issue, fix once in shared component"}
-  ],
-  "falsePositives": [
-    {"id": "API-003", "reason": "Input is validated by Zod schema at line 45"}
-  ]
-}
-```
-
-### Validator B: Evidence Challenger
-
-For every HIGH and CRITICAL finding:
-- Read the actual code files
-- Trace complete data flow
-- Verify exploit scenario is realistic
-- Check if exploitable in production context
-
-Output same format as Validator A.
-
-### Validator C: Missing Issues Hunter
-
-Look for issues Phase 1 agents MISSED:
-- Edge cases
-- Combination attacks
-- Business logic flaws specific to this codebase
-- Configuration issues
-- Integration points
-
-Output:
-```json
-{
-  "missedIssues": [{"full finding object"}]
-}
-```
+# API routes
+find . -type f \( -name "*route*" -o -name "*controller*" -o -name "*api*" -o -name "*endpoint*" \) -not -path "*/node_modules/*" 2>/dev/null | head -15
 
----
-
-## PHASE 5: CROSS-REFERENCE MERGE
-
-Before generating final output, identify findings that describe the same issue from different agent perspectives.
-
-**Merge Process:**
-1. Compare all findings from Phase 1-4
-2. If two findings reference the same file+line range OR describe the same root cause:
-   - Create a SINGLE finding with dual ID: "CR-02 / T-EKS-3"
-   - Use the most descriptive title from either finding
-   - Combine description details from both perspectives
-   - Use the higher DREAD score
-   - Populate `crossReferences` with both original IDs
-3. If findings are RELATED but NOT identical:
-   - Keep as separate findings
-   - Add each other's ID to `crossReferences` array
-
-**Examples of cross-referenced findings:**
-- Security agent finds hardcoded key + Infrastructure agent finds same key in Helm values → MERGE
-- Auth agent finds missing MFA + Business logic agent finds MFA bypass → ADD crossReferences
-- Quality agent finds DRY violation in metrics code + Security agent finds same code → MERGE
-
----
-
-## PHASE 6: POSITIVE OBSERVATIONS
+# Security middleware
+find . -type f \( -name "*middleware*" -o -name "*guard*" -o -name "*interceptor*" \) -not -path "*/node_modules/*" 2>/dev/null | head -10
 
-Scan for good practices to include in the report. Each positive observation must include **specific technical evidence** — not generic praise.
+# Config and secrets
+find . -type f \( -name "*.env*" -o -name "*secret*" -o -name "*config*" -o -name "*credential*" \) -not -path "*/node_modules/*" 2>/dev/null | head -15
 
-**FORMAT for each observation:**
-```json
-{
-  "title": "Descriptive Title — 3-5 words",
-  "description": "2-3 sentences of specific technical evidence. Name the specific functions, libraries, patterns, or configurations that demonstrate this strength. Include file references where relevant."
-}
+# Infrastructure
+find . -type f \( -name "Dockerfile*" -o -name "docker-compose*" -o -name "*.yaml" -o -name "*.yml" \) -not -path "*/node_modules/*" 2>/dev/null | head -20
 ```
 
-**BAD (generic, no evidence):**
-- "Good authentication implementation"
-- "Proper input validation"
-- "Secure coding practices"
-
-**GOOD (specific, with evidence):**
-- {"title": "Zero-Knowledge Architecture", "description": "EKS gateway genuinely never sees plaintext. Encrypted payloads flow through without decryption. Well-enforced across all components."}
-- {"title": "Atomic Credit Operations", "description": "Lua scripts for token burning and balance deduction prevent cross-pod race conditions. Check-and-deduct is atomic."}
-- {"title": "Post-Quantum Cryptography", "description": "XWing (ML-KEM-768 + X25519) hybrid KEM, Ed25519 signing, AES-256-GCM. Key derivation: Argon2id + HKDF with proper alignment across browser/Node.js."}
-- {"title": "Secure File Handling", "description": "MIME + magic number validation, memory-only storage, size limits. secureDeleteFile() overwrites with random data before deletion."}
-
-**CHECK FOR:**
-- Security controls that work well (name the specific middleware, library, or pattern)
-- Authentication/authorization strengths (name the provider, flow, and protections)
-- Input validation patterns (name the library and coverage)
-- Cryptographic implementations (name algorithms, key sizes, modes)
-- Architecture strengths (name the pattern and why it's secure)
-- Operational security (logging, monitoring, incident response)
-
-Output as array of objects with `title` and `description` fields.
-
----
-
-## PHASE 7: CONSOLIDATE AGENT RESULTS
-
-**After all batches complete, read findings from agent output files:**
+### Step 3: Check Previous Scan
 
 ```bash
-# List all agent output files
-ls -la .coverme/agents/*.json 2>/dev/null
-
-# Combine all findings into one array (using jq if available, or read each file)
-cat .coverme/agents/*.json 2>/dev/null | head -100
+cat .coverme/scan.json 2>/dev/null | head -50 || echo "NO_PREVIOUS_SCAN"
 ```
 
-**For each agent file that exists:**
-1. Read the JSON file
-2. Extract the `findings` array
-3. Merge into the master findings list
-4. Track which agents completed vs skipped
-
-**Memory-efficient consolidation:**
-- Read ONE agent file at a time
-- Extract only the findings array
-- Do NOT keep the full file content in memory
-- Build the final `scan.json` incrementally
-
 ---
 
-## PHASE 8: BUILD CONSENSUS & GENERATE OUTPUT
-
-### CRITICAL: Actually Remove False Positives!
+## PHASE 2: DEEP ANALYSIS
 
-The final report should ONLY contain findings that are:
-1. **Confirmed** by mitigation validation (no existing protection found)
-2. **Partial** mitigations (some protection but incomplete)
+**Read the critical files you found.** For each file, look for:
 
-**DO NOT INCLUDE** findings that are:
-- `mitigated` - full protection exists elsewhere
-- `false_positive` - not actually a vulnerability
-- Intentional design decisions with documented comments
-- Race conditions protected by atomic operations (Lua, transactions)
+### Security (SEC)
+- SQL/NoSQL Injection - string concatenation in queries
+- XSS - unsanitized output
+- Command Injection - user input in shell commands
+- Path Traversal - user input in file paths
+- SSRF - user-controlled URLs
+- Hardcoded Secrets - API keys, passwords in code
+- Weak Crypto - MD5, SHA1 for passwords, weak random
 
-### Step-by-Step Process:
+### Authentication (AUTH)
+- JWT issues - algorithm confusion, missing validation
+- Session fixation
+- Password storage - plaintext, weak hashing
+- Missing MFA
+- OAuth misconfigurations
 
-1. **Start with all Phase 1 findings**
+### API Security (API)
+- Missing input validation
+- No rate limiting
+- CORS misconfigurations
+- Missing authentication on endpoints
+- Mass assignment
 
-2. **Apply Mitigation Validator results (Phase 3):**
-   - `mitigated` → REMOVE from findings, add to `mitigatedFindings` array
-   - `false_positive` → REMOVE from findings, add to `falsePositives` array
-   - `partial` → KEEP but downgrade severity if specified
-   - `confirmed` → KEEP with original severity
+### Infrastructure (INFRA)
+- Docker running as root
+- Secrets in docker-compose
+- Missing securityContext in K8s
+- No NetworkPolicy
+- Secrets in git history
+- CI/CD security issues
 
-3. **Apply Cross-Validator results (Phase 4):**
-   - Additional false positives → REMOVE from findings
-   - Duplicates → Merge into single finding
+### Business Logic (BIZ)
+- Race conditions (TOCTOU)
+- Authorization bypass
+- Quota/credit manipulation
+- Workflow bypass
 
-4. **Calculate final counts AFTER removals:**
-   - Only count findings that remain in the `findings` array
-   - Do NOT count mitigated or false positive findings
+### Code Quality (QUAL)
+- No tests for security code
+- Dead code
+- Missing error handling
 
-5. **Add missed issues from Validator C**
+---
 
-6. **Sort remaining findings:** severity DESC, confidence DESC
+## PHASE 3: GENERATE REPORT
 
-### Final JSON Structure
+Create `.coverme/scan.json` with this structure:
 
 ```json
 {
   "projectName": "project-name",
-  "scanDate": "{{SCAN_DATE}}",
-  "filesScanned": 45,
-  "linesOfCode": 4850,
-  "projectTree": "project-name/\n├── src/\n│   ├── api/\n│   ├── services/\n│   └── utils/\n├── tests/\n└── package.json",
-
+  "scanDate": "2026-02-18T12:00:00Z",
+  "filesScanned": 100,
+  "linesOfCode": 15000,
+  "projectTree": "project/\n├── src/\n│   ├── routes/\n│   ├── services/\n│   └── middleware/\n├── tests/\n└── package.json",
   "projectOverview": {
-    "name": "project-name",
-    "type": "Backend API | Full-stack | etc",
-    "stack": ["Node.js", "TypeScript", "React", "PostgreSQL"],
-    "purpose": "Brief description of what this project does",
+    "name": "Project Name",
+    "type": "Backend API",
+    "stack": ["Node.js", "TypeScript", "PostgreSQL"],
+    "purpose": "What this project does in 1-2 sentences",
     "architecture": "Monolith | Microservices | Serverless",
-    "keyComponents": ["auth service", "payment processing", "AI chat"]
+    "keyComponents": ["src/routes/", "src/services/"]
   },
-
   "executiveSummary": {
-    "headline": "3 Critical + 5 High findings require immediate attention",
+    "headline": "X Critical + Y High findings - brief assessment",
     "riskLevel": "CRITICAL | HIGH | MEDIUM | LOW",
-    "overview": "A 2-3 sentence executive summary of the project architecture AND the overall security posture, written for leadership. Example: 'Express-AI Officely is a confidential AI platform built on a three-tier encrypted architecture. No critical vulnerabilities remain. The most significant remaining issues are: unauthenticated registration endpoints, hardcoded secrets in Helm values, and zero test coverage.'",
+    "overview": "2-3 sentence professional summary. Describe the architecture, then the security posture, then the main concerns.",
     "topRisks": [
-      "Unauthenticated enclave registration endpoints could allow impersonation (mitigated by network whitelisting)",
-      "Hardcoded API keys and hash salts in Helm values committed to version control",
-      "160 lines of Redis metrics tracking duplicated verbatim between streaming/non-streaming paths"
+      "Specific risk with file:line reference",
+      "Another risk with quantified impact"
     ],
     "positives": [
-      "Zero-knowledge architecture — gateway never sees plaintext",
-      "Atomic credit operations via Lua scripts prevent race conditions",
-      "Post-quantum cryptography with XWing hybrid KEM"
+      "Good practice with specific evidence",
+      "Another strength with file reference"
     ],
     "recommendedActions": [
       {
         "priority": 1,
-        "action": "Remove hardcoded secrets from Helm values. Move to Secrets Manager. Rotate keys.",
-        "owner": "devops",
-        "effort": "2-4 hours"
-      }
-    ],
-    "byOwner": {
-      "developer": 5,
-      "devops": 3,
-      "architect": 1
-    }
-  },
-
-  "architectureOverview": {
-    "components": [
-      {
-        "name": "API Server",
-        "type": "service",
-        "description": "Express.js REST API handling all client requests",
-        "trustLevel": "semi-trusted"
-      },
-      {
-        "name": "PostgreSQL",
-        "type": "database",
-        "description": "Primary data store for user and application data",
-        "trustLevel": "trusted"
-      },
-      {
-        "name": "Redis",
-        "type": "cache",
-        "description": "Session storage and rate limiting",
-        "trustLevel": "trusted"
-      },
-      {
-        "name": "External Payment API",
-        "type": "external",
-        "description": "Third-party payment processor",
-        "trustLevel": "untrusted"
-      }
-    ],
-    "trustBoundaries": [
-      {
-        "name": "Client to API",
-        "from": "Browser/Mobile",
-        "to": "API Server",
-        "protocol": "HTTPS"
-      },
-      {
-        "name": "API to Database",
-        "from": "API Server",
-        "to": "PostgreSQL",
-        "protocol": "TLS"
-      }
-    ],
-    "criticalAssets": [
-      {
-        "name": "User Credentials",
-        "type": "credential",
-        "location": "PostgreSQL users table",
-        "protection": "bcrypt hashed"
-      },
-      {
-        "name": "API Keys",
-        "type": "key",
-        "location": "Environment variables",
-        "protection": "Encrypted at rest"
-      },
-      {
-        "name": "Session Tokens",
-        "type": "token",
-        "location": "Redis",
-        "protection": "HMAC signed"
+        "action": "Specific action to take",
+        "owner": "developer",
+        "effort": "2-3 days"
       }
-    ],
-    "dataFlows": [
-      "User Authentication Flow",
-      "Payment Processing Flow",
-      "Data Export Flow"
     ]
   },
-
-  "threatModel": [
-    {
-      "id": "T-001",
-      "threat": "SQL Injection via user input",
-      "category": "STRIDE",
-      "strideType": "T",
-      "status": "open",
-      "relatedFindings": ["SEC-001", "DB-002"],
-      "mitigation": "Use parameterized queries",
-      "dreadScore": 8.5
-    },
-    {
-      "id": "T-002",
-      "threat": "Session hijacking via XSS",
-      "category": "STRIDE",
-      "strideType": "S",
-      "status": "partial",
-      "relatedFindings": ["SEC-003"],
-      "mitigation": "CSP headers implemented but not comprehensive",
-      "dreadScore": 7.2
-    },
-    {
-      "id": "T-003",
-      "threat": "Unauthorized data access",
-      "category": "LINDDUN",
-      "status": "mitigated",
-      "relatedFindings": [],
-      "mitigation": "Row-level security implemented",
-      "dreadScore": 3.0
-    }
-  ],
-
-  "qualityReview": {
-    "deleteItems": [
-      {
-        "type": "delete",
-        "file": "src/utils/oldHelpers.ts",
-        "lines": 250,
-        "title": "Dead utility functions — no callers in codebase",
-        "description": "Entire file is dead code — functions never called. No imports found anywhere.",
-        "reason": "No imports found in codebase",
-        "roi": "~250 lines"
-      },
-      {
-        "type": "delete",
-        "file": "src/legacy/auth.js",
-        "lines": 180,
-        "title": "Legacy auth replaced by Clerk integration",
-        "description": "Legacy auth implementation replaced by Clerk. Migration completed 6 months ago.",
-        "reason": "Migration completed 6 months ago",
-        "roi": "~180 lines"
-      }
-    ],
-    "mergeItems": [
-      {
-        "type": "merge",
-        "file": "src/utils/validate.ts, src/helpers/validation.ts",
-        "title": "Duplicate validation modules",
-        "description": "Two files with overlapping validation functions — same Zod schema patterns duplicated",
-        "reason": "DRY violation — consolidate into single module",
-        "roi": "~120 lines"
-      }
-    ],
-    "simplifyItems": [
-      {
-        "type": "simplify",
-        "file": "src/services/payment.ts",
-        "lines": 450,
-        "title": "Overly complex payment handler — 450 lines",
-        "description": "Single function handles parsing, validation, processing, and error recovery with deeply nested try/catch blocks",
-        "reason": "Split into paymentValidator, paymentProcessor, paymentErrorHandler — reduce to ~200 lines",
-        "roi": "~250 lines reducible"
-      }
-    ],
-    "totalLinesRemovable": 680,
-    "percentageOfCodebase": 4.2
-  },
-
-  "actionItems": [
-    {
-      "id": "A-001",
-      "title": "Fix SQL injection in user search",
-      "priority": "immediate",
-      "relatedFindings": ["SEC-001"],
-      "effort": "low",
-      "description": "Replace string concatenation with parameterized query"
-    },
-    {
-      "id": "A-002",
-      "title": "Implement rate limiting on auth endpoints",
-      "priority": "immediate",
-      "relatedFindings": ["AUTH-003"],
-      "effort": "medium",
-      "description": "Add Redis-based rate limiter to /login and /register"
-    },
-    {
-      "id": "A-003",
-      "title": "Add CSP headers",
-      "priority": "high",
-      "relatedFindings": ["SEC-005"],
-      "effort": "low",
-      "description": "Configure helmet with strict CSP policy"
-    },
-    {
-      "id": "A-004",
-      "title": "Clean up dead code",
-      "priority": "medium",
-      "relatedFindings": ["DEAD-001", "DEAD-002"],
-      "effort": "medium",
-      "description": "Remove 680 lines of unused code identified in quality review"
-    },
-    {
-      "id": "A-005",
-      "title": "Implement audit logging",
-      "priority": "long-term",
-      "relatedFindings": ["DATA-002"],
-      "effort": "high",
-      "description": "Add comprehensive audit trail for sensitive operations"
-    }
-  ],
-
-  "summary": {
-    "total": 10,
-    "critical": 1,
-    "high": 3,
-    "medium": 4,
-    "low": 2,
-    "info": 0,
-    "mitigatedCount": 5,
-    "falsePositiveCount": 3,
-    "avgConfidence": 0.85
-  },
-
   "findings": [
     {
       "id": "SEC-001",
-      "title": "SQL Injection in User Search",
+      "title": "Specific title describing the exact vulnerability",
       "severity": "critical",
       "category": "security",
-      "file": "src/routes/users.ts",
+      "file": "src/routes/user.ts",
       "line": 45,
-      "code": "db.query(`SELECT * FROM users WHERE name LIKE '%${searchTerm}%'`)",
-      "description": "User search parameter is directly concatenated into SQL query without sanitization",
-      "impact": "Attacker can extract entire database contents, modify data, or execute system commands",
+      "endLine": 52,
+      "code": "const query = `SELECT * FROM users WHERE id = ${userId}`",
+      "description": "The userId parameter is concatenated directly into the SQL query without sanitization. This allows an attacker to inject arbitrary SQL commands.",
+      "impact": "Full database access. Attacker can read all user data, modify records, or delete tables.",
       "attackChain": [
-        {"step": 1, "action": "Send malicious search term: ' OR '1'='1' --", "result": "Query returns all users"},
-        {"step": 2, "action": "Use UNION SELECT to extract data from other tables", "result": "Database schema exposed"},
-        {"step": 3, "action": "Extract password hashes and sensitive data", "result": "Full data breach"}
+        {"step": 1, "action": "Send userId = '1 OR 1=1'", "result": "Query returns all users"},
+        {"step": 2, "action": "Use UNION SELECT to read other tables", "result": "Extract passwords, tokens"},
+        {"step": 3, "action": "Use INTO OUTFILE to write webshell", "result": "Remote code execution"}
       ],
-      "recommendation": "Use parameterized queries: db.query('SELECT * FROM users WHERE name LIKE $1', [`%${searchTerm}%`])",
-      "cwe": "CWE-89",
-      "owasp": "A03:2021",
-      "dreadScore": {
+      "recommendation": "Use parameterized queries: `db.query('SELECT * FROM users WHERE id = $1', [userId])`",
+      "dread": {
         "damage": 10,
         "reproducibility": 10,
         "exploitability": 9,
         "affectedUsers": 10,
         "discoverability": 8,
-        "total": 9.4
+        "score": 9.4
       },
-      "status": "open",
-      "crossReferences": ["T-001"],
-      "confidence": 95,
-      "fixOwner": "developer",
-      "fixType": "code"
-    }
-  ],
-
-  "designDecisions": [
-    {
-      "id": "DESIGN-001",
-      "title": "Content filtering disabled for transparency",
-      "file": "src/ai/chat.ts",
-      "reason": "Documented decision - users see raw AI output",
-      "acceptedRisk": "Users may see inappropriate content"
-    }
-  ],
-
-  "mitigatedFindings": [
-    {
-      "id": "SEC-005",
-      "title": "Original finding title",
-      "originalSeverity": "high",
-      "reason": "Protected by Zod schema validation at src/routes/user.ts:23",
-      "mitigationType": "input_validation"
-    }
-  ],
-
-  "falsePositives": [
-    {
-      "id": "BIZ-004",
-      "title": "TOCTOU Race Condition",
-      "reason": "Redis Lua script provides atomic operation - no race condition possible",
-      "evidence": ["Lua script at src/services/rate-limit.js:95-113"]
+      "cwe": "CWE-89",
+      "fixOwner": "developer"
     }
   ],
-
   "positiveObservations": [
     {
-      "title": "Strong Authentication Implementation",
-      "description": "Clerk integration with proper session management, MFA support, and secure cookie settings. All tokens kept server-side. httpOnly + secure cookies with SameSite=strict."
-    },
-    {
-      "title": "Comprehensive Input Validation",
-      "description": "Zod schemas used consistently across 15+ API endpoints with proper error handling. Schema-first validation prevents malformed input from reaching business logic."
-    },
-    {
-      "title": "Secure Database Access",
-      "description": "Prisma ORM with parameterized queries throughout. Zero raw SQL queries found. Prevents SQL injection across all database operations."
-    },
-    {
-      "title": "Good Error Handling Patterns",
-      "description": "Custom AppError class with error codes. Internal details logged server-side only. Generic messages returned to clients. Consistent format across routes."
-    }
-  ],
-
-  "previouslyResolved": [
-    {
-      "id": "PREV-001",
-      "title": "SQL Injection in search endpoint",
-      "originalSeverity": "critical",
-      "resolution": "Parameterized queries implemented using Prisma ORM. Verified no raw SQL remains.",
-      "resolvedDate": "2026-01-15"
+      "title": "Proper Password Hashing",
+      "description": "Uses bcrypt with cost factor 12 in auth/password.ts:23. Passwords never stored in plaintext."
     }
   ],
-
-  "validationSummary": {
-    "totalInitialFindings": 18,
-    "mitigated": 5,
-    "falsePositives": 3,
-    "confirmed": 8,
-    "partial": 2,
-    "accuracy": "Only 56% of initial findings were actual issues"
+  "qualityReview": {
+    "deleteItems": [
+      {"file": "src/old/legacy.ts", "lines": 250, "description": "Unused legacy code - no imports found"}
+    ],
+    "mergeItems": [
+      {"file": "src/utils/validate.ts + src/helpers/validator.ts", "description": "Duplicate validation logic"}
+    ],
+    "totalLinesRemovable": 400,
+    "percentageOfCodebase": 2.5
   },
-
-  "agentsUsed": ["Security Core", "Auth & Session", "Mitigation Validator", "Network & Architecture", "Design Decision Detector"],
-  "scanDuration": 0
+  "summary": {
+    "critical": 1,
+    "high": 3,
+    "medium": 5,
+    "low": 2,
+    "total": 11
+  }
 }
 ```
 
-### Sanity Check Before Saving
+### DREAD Scoring (REQUIRED for critical/high):
+
+| Score | Meaning |
+|-------|---------|
+| 10 | Worst case |
+| 7-9 | Severe |
+| 4-6 | Moderate |
+| 1-3 | Minor |
+
+- **Damage**: Impact if exploited
+- **Reproducibility**: How consistently exploitable
+- **Exploitability**: Skill level needed
+- **Affected Users**: Scope of impact
+- **Discoverability**: How easy to find
+- **Score**: Average of all five
 
-Before saving, verify:
-1. `findings` array does NOT contain any item from `mitigatedFindings` or `falsePositives`
-2. `summary.total` equals `findings.length`
-3. Severity counts match actual findings in array
-4. No duplicate IDs across findings/mitigated/falsePositives
+### Attack Chain (REQUIRED for critical/high):
 
-Save as: .coverme/scan.json
+Show step-by-step exploitation:
+```json
+[
+  {"step": 1, "action": "What attacker does", "result": "What happens"},
+  {"step": 2, "action": "Next action", "result": "Escalation"},
+  {"step": 3, "action": "Final action", "result": "Full compromise"}
+]
+```
 
 ---
 
-## PHASE 8: GENERATE HTML REPORT (MANDATORY)
+## PHASE 4: SAVE AND OPEN REPORT
 
-**After saving scan.json, you MUST generate and open the HTML report.**
+After creating the JSON, save it and generate HTML:
 
-Run this command:
 ```bash
-coverme report .coverme/scan.json
+# Save scan.json (you just wrote it)
+# Generate and open HTML report
+coverme report
 ```
 
-This will:
-1. Generate `.coverme/report_YYYY-MM-DD_HH-MM-SS.html`
-2. Automatically open the report in the default browser
+The `coverme report` command will:
+1. Read `.coverme/scan.json`
+2. Generate `.coverme/report_YYYY-MM-DD_HH-MM-SS.html`
+3. Open the report in your browser
 
-**If `coverme` command is not available:**
+---
 
-Generate the HTML manually using this template structure, then open it:
-```bash
-# Save HTML report
-cat > .coverme/report_$(date +%Y-%m-%d_%H-%M-%S).html << 'HTMLEOF'
-<!DOCTYPE html>
-<html>
-<head>
-  <title>CoverMe Security Report</title>
-  <style>
-    body { font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif; max-width: 1200px; margin: 0 auto; padding: 20px; }
-    .critical { color: #dc2626; } .high { color: #ea580c; } .medium { color: #ca8a04; } .low { color: #16a34a; }
-    .finding { border: 1px solid #e5e7eb; border-radius: 8px; padding: 16px; margin: 16px 0; }
-    .finding-header { display: flex; justify-content: space-between; align-items: center; }
-    pre { background: #f3f4f6; padding: 12px; border-radius: 4px; overflow-x: auto; }
-    .summary-card { background: #f9fafb; padding: 20px; border-radius: 8px; margin: 20px 0; }
-  </style>
-</head>
-<body>
-  <h1>Security Scan Report</h1>
-  <!-- Insert findings from scan.json -->
-</body>
-</html>
-HTMLEOF
+## QUALITY CHECKLIST
 
-# Open in browser
-open .coverme/report_*.html 2>/dev/null || xdg-open .coverme/report_*.html 2>/dev/null || echo "Report saved to .coverme/"
-```
+Before finishing, verify:
 
-**CRITICAL**: Do not end the scan without generating and opening the HTML report. The user expects to see the report in their browser.
+- [ ] Read actual code files, not just file names
+- [ ] Every finding has file + line number
+- [ ] Critical/High findings have DREAD scores
+- [ ] Critical/High findings have attack chains
+- [ ] No duplicate findings
+- [ ] Positive observations have specific evidence
+- [ ] Executive summary is professional and specific
+- [ ] `coverme report` was run to generate HTML
 
 ---
 
-## FINAL STEP - MANDATORY
+## EXAMPLES
 
-After saving `.coverme/scan.json`, you MUST run this command:
+### Good Finding:
+```json
+{
+  "id": "AUTH-001",
+  "title": "JWT accepts 'none' algorithm allowing authentication bypass",
+  "severity": "critical",
+  "file": "src/middleware/auth.ts",
+  "line": 34,
+  "code": "jwt.verify(token, secret, { algorithms: ['HS256', 'none'] })",
+  "description": "JWT verification accepts the 'none' algorithm. An attacker can forge tokens by removing the signature and setting alg=none.",
+  "attackChain": [
+    {"step": 1, "action": "Capture valid JWT", "result": "Obtain token structure"},
+    {"step": 2, "action": "Decode, modify claims, set alg=none, remove signature", "result": "Forged admin token"},
+    {"step": 3, "action": "Send forged token", "result": "Authenticated as any user"}
+  ],
+  "dread": {"damage": 10, "reproducibility": 10, "exploitability": 9, "affectedUsers": 10, "discoverability": 7, "score": 9.2}
+}
+```
 
-```bash
-coverme report
+### Bad Finding (don't do this):
+```json
+{
+  "id": "SEC-001",
+  "title": "SQL Injection",
+  "severity": "high",
+  "description": "There might be SQL injection somewhere"
+}
 ```
 
-This generates the HTML report and opens it in the browser automatically.
+---
 
-**If you skip this step, the scan is incomplete!**
+## REMEMBER
 
-The scan is only finished when:
-1. ✅ scan.json is saved
-2. ✅ HTML report is generated
-3. ✅ Browser opens with the report
+1. **Read code before reporting** - Don't guess
+2. **Be specific** - File names, line numbers, actual code
+3. **DREAD + Attack Chain** - Required for critical/high
+4. **Run `coverme report`** - Opens HTML in browser
+5. **Quality over quantity** - 10 good findings > 50 vague ones