knowbe4/frieren-dast-ai

Purpose and Entry Points

Frieren DAST-AI is a Python dynamic application security testing system: an HTTPS MITM proxy captures traffic, runs passive analysis, queues in-scope targets for active AI-guided testing, and presents findings through a local dashboard. Primary CLI entry is dast/cli.py; runtime composition is centered on dast/proxy/runner.py and dast/orchestrator.py. An optional Electron launcher starts the same backend from desktop/main.js.

Proxy, Capture, and Dashboard Boundary

The proxy terminates/intercepts HTTPS using a local CA, applies scope/bypass policy, and captures request/response history. The dashboard server exposes the UI and API/WebSocket-facing control plane; the browser UI is static JavaScript rather than a separate application backend.

• dast/proxy/proxy_server.py

• dast/proxy/cert_authority.py

• dast/proxy/dashboard_server.py

Captured traffic and scan state are held by proxy/session-layer stores, creating the boundary between live interception, manual tools (Repeater/Intruder), saved sessions, and scan execution.

• dast/proxy/intercept_store.py

• dast/proxy/session_store.py

• dast/proxy/scan_queue_state.py

Scan Pipeline and Orchestration

The main control flow is: intercepted in-scope traffic → passive scan and queue → orchestration/coordinator → selected active agents → validated findings → dashboard/report consumers. The attack engine executes requests/probes with concurrency and host safety controls, while the orchestrator coordinates lifecycle and result handling.

• dast/orchestrator.py

• dast/attack/engine.py

• dast/ai/coordinator.py

Passive checks are data-driven YAML rules, allowing security coverage additions without scanner-code changes. Active payload seeds and vulnerability knowledge are similarly separated from agent logic.

• dast/plugins/passive_scanner.py

• dast/passive_rules/

• dast/payloads/loader.py

AI Decision and Safety Layer

The coordinator uses a provider abstraction to plan agent selection, generate/adapt payloads, classify probes, analyze responses, and filter false positives. Provider support includes AWS Bedrock, Anthropic, and OpenAI-compatible APIs. Prompt safety and red-team validation are explicit gates around model-driven actions/findings.

• dast/ai/providers.py

• dast/ai/bedrock_client.py

• dast/ai/red_team.py

Vulnerability Agents

Specialized agents implement vulnerability-class probing, generally operating in parallel for an endpoint under coordinator selection. Coverage spans injection, authorization/session flaws, SSRF/file access, secrets, LLM endpoints, GraphQL, and framework-specific testing. Shared payload filtering and response-difference logic support consistent evidence decisions.

• dast/agents/xss_agent.py

• dast/agents/sqli_agent.py

• dast/agents/ssrf_agent.py

Discovery, Browser, and Application Context

Discovery expands the target model through crawling, JavaScript analysis, fingerprinting, OpenAPI probing, and traffic graph construction. Playwright-backed browser contexts support authenticated/manual browsing and browser-required confirmations. The resulting application/threat/service context feeds planning and cross-host testing.

• dast/discovery/engine.py

• dast/discovery/traffic_graph.py

• dast/browser/context_pool.py

External Interaction, Persistence, and Outputs

OOB testing integrates Interactsh; HackerOne material can be parsed, safety-checked, validated, and turned into evidence. Sessions persist locally under the user home directory, while findings can be exported, including SARIF. Runtime dependencies include Python, Playwright/Chromium, optional Electron/Node.js, and configured LLM/cloud credentials.

• dast/utils/interactsh.py

• dast/hackerone/validator.py

• dast/report/sarif.py