Skip to content

Back to the catalog

Frieren DAST-AI
github.comrepo

Frieren DAST-AI

Frieren DAST-AI is an open-source dynamic application security testing tool combining an HTTPS MITM proxy with a real-time dashboard and LLM-driven multi-agent active scanner. A YAML-based passive rule engine (62 rules covering headers, cookies, CORS, secrets, error pages, LLM endpoint detection, and Blazor-specific checks) flags issues on every intercepted response, while an LLM planner dispatches parallel VulnAgents (xss, sqli, ssrf, file_read, auth_bypass, secrets, discovery, llm_injection, business_logic, blazor) per endpoint, with an LLM validator confirming findings and adaptive WAF-bypass payload mutation.

TL;DR Open-source LLM-orchestrated DAST proxy that auto-discovers and validates web vulnerabilities (XSS, SQLi, SSRF, auth bypass, secrets, LLM injection) in real time.
Open original ↗
Document

What it is

Frieren DAST-AI is KnowBe4's open-source DAST tool. Beyond the proxy/dashboard/multi-agent scanner the summary describes, the repo page gives the concrete operational shape: how you stand it up, an unusual AWS-SSO dependency, a cross-host token-sharing feature, and where sensitive material lands on disk.

How it works

Traffic flows through the MITM proxy (port 8080), into an in-memory session store, then forks: a passive YAML scanner fires zero-request checks on every response, while in-scope entries queue for active scanning by an LLM coordinator (planner → parallel VulnAgents → LLM validator), pushed to the dashboard (port 8088) over WebSocket.

One capability not in the summary: it auto-detects that multiple hosts belong to the same microservice app via shared JWTs, common parent domain, correlation headers (X-Trace-ID, traceparent), and shared session cookie name+value. It then shares tokens across hosts — the auth agent reuses tokens on sibling hosts, and SSRF probes are aimed at discovered internal services. Merge/split is manual-overridable.

Preconditions / Affected

  • An LLM backend is mandatory for the coordinator, agents, and validator — pick a provider via AI_PROVIDER in .env.
  • Setup assumes AWS SSO: make sso-configure once, then make sso per session/when the token expires. make proxy and the desktop launcher inherit AWS_PROFILE/AWS_ACCESS_KEY_ID from your shell.
  • You must install the tool's CA cert into the browser/OS trust store for TLS interception to work.
  • Desktop launcher needs Node.js + npm.

What to do

Standard bring-up, in order (SSO steps precede the proxy):

make setup
make sso-configure   # first time only
make sso             # once per session / on token expiry
make proxy

Then set the browser HTTP proxy to 127.0.0.1:8080, install the CA cert from http://127.0.0.1:8088/ca.crt (one-time), and open the dashboard at http://127.0.0.1:8088.

Optional native window (spawns the same backend):

make desktop-install   # first run, ~200MB
make desktop
make desktop PROXY_PORT=9090 DASHBOARD_PORT=9099

Passive checks are YAML in dast/passive_rules/ — adding a rule is a new file, no code. Payloads live in dast/payloads/*.yaml. Scan-engine toggles (workers, concurrency, passive/active, planner/validator) are in AI > Settings, applied at runtime without restart.

Caveats

  • The desktop bundles produced by make desktop-dist-* are launcher-only (Phase 1): the packaged app still assumes uv and the checked-out repo are present at runtime — it does not bundle the Python backend.
  • The CA private key is written to ~/.dast-ai/ca.key, alongside session JSON in ~/.dast-ai/sessions/ — treat that directory as sensitive.
  • Rule-count is inconsistent on the page (diagram says 47, text says "62 rules loaded at startup"); 62 is the startup figure.

Technologies named here

  • Frieren DAST-AI
  • HTTPS MITM Proxy
  • Passive Scanner
  • Coordinator
  • VulnAgents
  • Dashboard
  • Electron desktop launcher
  • Playwright
  • electron-builder
  • Electron
  • AWS SSO

Techniques named here

  • Passive vulnerability scanning
  • Active vulnerability scanning via parallel agents
  • LLM-based WAF bypass payload mutation
  • Multi-host application correlation
  • Security header checks
  • Information disclosure detection
  • Cache control checks
  • Cookie flag checks
  • CORS misconfiguration detection
  • Secrets detection
  • Error page / injection artifact detection
  • LLM endpoint detection and prompt injection/leak checks
  • Blazor framework-specific checks
  • HTTP/2 CONTINUATION flood probe
  • Discovery checks
  • Pre-authenticated session scanning

Related in AppSec