I built KageSec.
What’s wrong with existing DAST tools
Nuclei is great — ProjectDiscovery built something genuinely impressive. But it’s a template-matching engine, not a DAST scanner. It hits the root URL, matches YAML patterns and reports findings. It does not crawl your app, discover parameters, or inject payloads into forms. The companies charging enterprise pricing for “Nuclei as a service” are essentially charging you for a UI on top of a YAML runner.
ZAP is the other go-to. It crawls. It injects. But it generates a lot of noise, misses logic-layer vulnerabilities, and has no AI filtering step to tell you which findings are actually exploitable.
The gap is: something that crawls like ZAP, runs templates like Nuclei, and uses AI to cut the noise.
The benchmark
I tested against ginandjuice.shop —
Here’s what each tool found:
| KageSec | ZAP | Nuclei (standalone) | |
|---|---|---|---|
| Total findings | 21 | 7 | 12 |
| Critical | 4 | 0 | 0 |
| High | 4 | 4 | 0 |
| Medium | 5 | 3 | 0 |
| Low / Info | 8 | 0 | 12 |
| Scan time | 10m 22s | ~25 min | 6m |
Nuclei’s 12 findings were all INFO — missing HTTP headers on the root URL. It found zero actual vulnerabilities because it never crawled the app or injected anything. That’s not a criticism of Nuclei. It’s just not what it’s for.
Vulnerability breakdown
| Vulnerability | KageSec | ZAP | Nuclei |
|---|---|---|---|
| OS Command Injection | ✅ CRITICAL | ✗ | ✗ |
| XML External Entity (XXE) | ✅ CRITICAL | ✗ | ✗ |
| AngularJS CSTI | ✅ CRITICAL | ✗ | ✗ |
| DOM-Based XSS | ✅ HIGH | ✅ HIGH | ✗ |
| Reflected XSS | ✅ HIGH | ✅ HIGH | ✗ |
| SSI Injection | ✅ HIGH | ✗ | ✗ |
| SQL Injection | ✗ | ✅ HIGH | ✗ |
| Missing CSRF Protection | ✅ MEDIUM | ✅ MEDIUM | ✗ |
| Business Logic | ✅ MEDIUM | ✗ | ✗ |
KageSec missed SQL injection. ZAP missed OS command injection and XXE. Neither tool is complete — that’s an honest benchmark.
How it works
1. Crawl first, scan everything found
KageSec uses Playwright to crawl the app like a real browser. JavaScript rendered, SPAs handled, forms discovered. Every page found becomes a scan target. Nuclei never does this.
2. 61 exploitation modules per page
For each page, KageSec runs 61 vulnerability modules concurrently — XSS, SQLi, SSRF, SSTI, XXE, deserialization, request smuggling, prototype pollution, JWT attacks and more. Each module is an active exploit attempt, not a passive header check.
3. A Go template engine that isn’t Nuclei
I built kagesec-engine — a purpose-built Go binary that runs 7,417 HTTP-compatible Nuclei templates. It is not a Nuclei wrapper. The key differences:
- Confidence scoring — every finding gets a 0.0–1.0 score, not a binary match/no-match
- Stack fingerprinting — identifies your tech stack first, runs relevant templates first
- Real-time streaming — JSON Lines streamed as findings arrive, Python reads them live
- Auth-aware — inherits all session cookies, bearer tokens, and headers from the main scan
- 7,417 templates in ~2 minutes with 50 goroutines
4. AI verification
With an AI provider configured (Claude, GPT-4o, Gemini, Mistral, or Ollama locally), KageSec sends findings to the model with full request/response context and asks: is this actually exploitable? False positives get filtered. Real findings get an exploitability verdict.
Without AI verification, you’re relying on heuristics. With it, you’re relying on a model that has read every CVE write-up on the internet.
5. Canary-based false positive elimination for parameters
The classic DAST noise problem: you inject into a parameter, get a reflection, call it XSS. But the app reflects everything. It’s just echoing input. KageSec uses a canary baseline (the same approach as Burp Param Miner and Arjun): inject a known-safe random
value first, establish what “normal” looks like, then compare attack payloads against that baseline. If your XSS payload reflects but so does kagesec-canary-a3f9, it’s not a finding.
Getting started
…