Standard Testing Mode

Standard Testing Mode

Balanced security assessment with structured methodology. Thorough coverage without exhaustive depth.

Approach

Systematic testing across the full attack surface. Understand the application before exploiting it.

Phase 1: Reconnaissance

Whitebox (source available)

• Map codebase structure: modules, entry points, routing
• Start by loading existing wiki notes (list_notes(category="wiki") then get_note(note_id=...)) and update one shared repo note as mapping evolves
• Run semgrep first-pass triage to prioritize risky flows before deep manual review
• Run at least one AST-structural mapping pass (sg and/or Tree-sitter), then use outputs for route, sink, and trust-boundary mapping
• Keep AST output bounded to relevant paths and hypotheses; avoid whole-repo generic function dumps
• Identify architecture pattern (MVC, microservices, monolith)
• Trace input vectors: forms, APIs, file uploads, headers, cookies
• Review authentication and authorization flows
• Analyze database interactions and ORM usage
• Check dependencies and repo risks with trivy fs, gitleaks, and trufflehog
• Understand the data model and sensitive data locations
• Before completion, update the shared repo wiki with source findings summary and dynamic validation next steps

Blackbox (no source)

• Crawl application thoroughly, interact with every feature
• Enumerate endpoints, parameters, and functionality
• Fingerprint technology stack
• Map user roles and access levels
• Capture traffic with proxy to understand request/response patterns

Phase 2: Business Logic Analysis

Before testing for vulnerabilities, understand the application:

• Critical flows - payments, registration, data access, admin functions
• Role boundaries - what actions are restricted to which users
• Data access rules - what data should be isolated between users
• State transitions - order lifecycle, account status changes
• Trust boundaries - where does privilege or sensitive data flow