# 📊 Benchmarks & Competitive Positioning > **Reading this document:** > `▲` = controlled micro-benchmark (unit/integration test) > `◆` = live authorized scan on a real target > `◇` = projection based on architecture + module counts — verify before quoting > > Every number has a caveat. "Methodology" at the bottom tells you where the error bars are. > > For a reproducible end-to-end head-to-head, see **[BENCHMARK-SCANME.md](BENCHMARK-SCANME.md)** — same tool, same target, real output, three bugs fixed mid-test. --- ## TL;DR God's Eye v2 is an **all-in-one offensive recon + vulnerability + AI-analysis tool**. If you want pure subdomain enumeration speed, `subfinder` or `assetfinder` will beat it. If you want full attack-surface mapping + vulnerability triage + agentic AI reasoning in a single binary, nothing open-source does it all today. This document shows what the trade-off looks like in numbers. | Dimension | Winner | God's Eye v2 | |-------------------------------------------|---------------------------------------|--------------------| | Pure passive subdomain speed | `assetfinder` | 2nd (comparable) | | Subdomain coverage (passive + active) | **God's Eye v2** *(20 → 60+ sources)* | ★ | | DNS brute-force throughput | `massdns` (single-purpose) | 3rd | | Vulnerability triage breadth | **God's Eye v2 + Nuclei compat** | ★ | | AI-assisted analysis | **God's Eye v2** *(only option OSS)* | ★ | | TLS appliance fingerprinting | **God's Eye v2** | ★ | | One-binary workflow | **God's Eye v2** / `bbot` | ★ (tie) | | Small-team asset-change monitoring (ASM) | **God's Eye v2** *(diff + scheduler)* | ★ | --- ## Competitive comparison — feature matrix Rows are capabilities. Cells are `✅` (first-class), `◐` (partial / via plugin), `❌` (absent). | Capability | God's Eye v2 | Subfinder | Amass | Assetfinder | Findomain | BBOT | Nuclei | |----------------------------------------------|:------------:|:---------:|:---------:|:-----------:|:---------:|:---------:|:---------:| | **Discovery** | | | | | | | | | Passive sources (count) | 26 (→60+ planned) | 30+ | 20+ | 8 | 15 | 40+ | — | | DNS brute-force | ✅ | ❌ | ✅ | ❌ | ✅ | ✅ | — | | Recursive pattern learning | ✅ | ❌ | ✅ | ❌ | ❌ | ✅ | — | | DNS permutation (alterx-style) | ✅ (opt-in) | ❌ | ❌ | ❌ | ❌ | ✅ | — | | AXFR zone transfer | ✅ | ❌ | ✅ | ❌ | ❌ | ✅ | — | | Reverse DNS CIDR sweep | ✅ (opt-in) | ❌ | ✅ | ❌ | ❌ | ✅ | — | | Virtual host discovery | ✅ (opt-in) | ❌ | ❌ | ❌ | ❌ | ✅ | — | | ASN/CIDR expansion | ✅ (opt-in) | ❌ | ✅ | ❌ | ❌ | ✅ | — | | Certificate Transparency live stream | ✅ (opt-in) | ❌ | ❌ | ❌ | ❌ | ◐ (poll) | — | | GitHub code dorks | ✅ | ❌ | ❌ | ❌ | ❌ | ✅ | — | | Supply-chain (npm / PyPI) discovery | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | — | | **Enrichment** | | | | | | | | | HTTP probe + tech fingerprint | ✅ | ❌ | ❌ | ❌ | ❌ | ✅ | ◐ | | TLS appliance fingerprint (25+ vendors) | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | | Port scan | ✅ | ❌ | ❌ | ❌ | ❌ | ✅ | ❌ | | **Vulnerability detection** | | | | | | | | | Security headers audit | ✅ | ❌ | ❌ | ❌ | ❌ | ◐ | ✅ (templates) | | Open redirect / CORS / dangerous methods | ✅ | ❌ | ❌ | ❌ | ❌ | ◐ | ✅ (templates) | | Git/SVN / backup / admin exposure | ✅ | ❌ | ❌ | ❌ | ❌ | ✅ | ✅ | | Subdomain takeover (110+ signatures) | ✅ | ❌ | ❌ | ❌ | ❌ | ✅ | ✅ (templates) | | GraphQL introspection + mutation detection | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ (templates) | | JWT analyzer + weak-secret crack | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | | HTTP request smuggling (CL.TE / TE.CL) | ✅ (opt-in) | ❌ | ❌ | ❌ | ❌ | ❌ | ◐ (templates) | | Cloud asset discovery (S3/GCS/Azure) | ✅ | ❌ | ❌ | ❌ | ❌ | ✅ | ❌ | | Secret extraction from JS | ✅ | ❌ | ❌ | ❌ | ❌ | ✅ | ✅ (templates) | | CVE matching (live NVD + offline KEV) | ✅ | ❌ | ❌ | ❌ | ❌ | ◐ | ❌ | | **AI / Agentic** | | | | | | | | | Local LLM analysis (Ollama) | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | | Multi-agent orchestration (8 agents) | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | | AI profiles (lean/balanced/heavy) | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | | Auto-pull missing models | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | | **Operations** | | | | | | | | | Interactive setup wizard | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | | Stealth profiles (4 levels) | ✅ | ❌ | ❌ | ❌ | ❌ | ✅ | ❌ | | Continuous monitoring + diff engine | ✅ | ❌ | ❌ | ❌ | ❌ | ◐ | ❌ | | Webhook alerting on change | ✅ | ❌ | ❌ | ❌ | ❌ | ✅ | ❌ | | Event-driven plugin architecture | ✅ | ❌ | ❌ | ❌ | ❌ | ✅ | ❌ | **What each competitor is best at:** - **[subfinder](https://github.com/projectdiscovery/subfinder)** — Fastest pure passive subdomain enumeration. Massive source list, huge community. - **[amass](https://github.com/owasp-amass/amass)** — Academic-grade subdomain + ASN graph analysis. Unmatched historical coverage. - **[assetfinder](https://github.com/tomnomnom/assetfinder)** — Minimal, composable, Unix-philosophy. Great as a Bash pipe stage. - **[findomain](https://github.com/Findomain/Findomain)** — Very fast, ergonomic, good free tier without API keys. - **[BBOT](https://github.com/blacklanternsecurity/bbot)** — Python framework with 100+ modules. Closest competitor to v2. - **[nuclei](https://github.com/projectdiscovery/nuclei)** — Template-driven vulnerability scanner. Not a discovery tool but the reference for finding known CVEs. God's Eye v2 is designed to replace the **"chain 4 tools with Bash + jq"** workflow with a single binary + an interactive wizard. --- ## Micro-benchmarks (▲ unit-level) Measured on an Apple M1 Pro, 16GB RAM, Go 1.21. Run with `go test -race`. | Benchmark | v2 | |------------------------------------------------------------------------|---------------------------------------------------------| | Event bus publish throughput (1 producer / 1 sub) | ~1.8M events/sec | | Event bus publish + drop rate (20 publishers / 1 slow sub / 4k buffer) | 100% delivered up to ~5k bursts, then graceful drop | | Store.Upsert serialized (same host, 50 writers) | ~28k ops/sec | | Store.Upsert parallel (200 hosts, 1 writer each) | ~65k ops/sec | | Diff.Compute on 500-host snapshots | ~2ms | | Wizard prompter round-trip (scripted input) | <1ms per prompt | All numbers are **architectural**: they measure the pipeline scaffolding, not network-bound work. Real-world scan times are dominated by DNS and HTTP latency. --- ## Real-world scan scenarios (◆ measured, ◇ projected) > These numbers come from authorized testing. Times vary ±30% depending on target responsiveness, network RTT, and Ollama hardware. ### Scenario A — Passive-only triage (no brute, no AI) ```bash ./god-eye -d target.com --pipeline --no-brute --silent ``` | Target size | v2 | subfinder | assetfinder | |-----------------|-------|-----------|-------------| | ~50 subdomains | ~25s | ~8s | ~4s | | ~500 subdomains | ~40s | ~12s | ~7s | | ~5k subdomains | ~75s | ~18s | ~12s | God's Eye passive is slower per-source because it also runs enrichment scaffolding for downstream modules. When you only want a subdomain list, use `--no-probe --no-ports --no-takeover` too — that drops the delta to ~2×. ### Scenario B — Full recon (brute + probe + security + cloud + JS) ```bash ./god-eye -d target.com --pipeline --profile bugbounty ``` | Target size | v2 | "subfinder + httpx + nuclei + katana" pipeline | |-----------------|---------|-------------------------------------------------| | ~50 subdomains | ~2m | ~3–4m (manual piping) | | ~500 subdomains | ~8m | ~12–15m | | ~5k subdomains | ~55m ◇ | ~75m+ ◇ | v2 pulls ahead here because it pipelines phases via the event bus — DNS resolution kicks off HTTP probing on each host as soon as the first IP resolves, rather than waiting for the full discovery phase. ### Scenario C — AI-assisted (lean cascade) ```bash ./god-eye -d target.com --pipeline --enable-ai --ai-profile lean ``` | Scenario | Scan time | AI findings | RAM (both models loaded) | |--------------------------------------|------------|-------------|--------------------------| | 50 hosts, lean cascade | ~3m30s ◆ | 15–25 | ~10–11GB | | 50 hosts, balanced (MoE 30B) | ~4m ◇ | 25–35 | ~18GB | | 50 hosts, heavy (qwen3:8b + MoE 30B) | ~5m30s ◇ | 30–40 | ~22GB | AI overhead ~20–30% vs non-AI in lean tier. The **MoE balanced tier** is the sweet spot: a 30B-total / 3.3B-active-per-token model delivers ~2–3× the inference speed of a dense 32B at similar quality. ### Scenario D — Continuous ASM monitoring ```bash ./god-eye -d target.com --pipeline --profile asm-continuous --monitor-interval 24h ``` Over a 7-day run on a test target: | Metric | Value | |------------------------------------------|--------| | Scans executed | 7 | | Hosts first-seen per scan (avg) | 3.4 | | Hosts vanished per scan (avg) | 0.9 | | New vulnerabilities surfaced | 2 | | Cert-change events | 1 | | Total webhook fires | 11 | | Total bytes downloaded (passive sources) | ~480MB | The diff engine makes day-over-day changes visible without re-reviewing the full scan report each time. --- ## AI tier comparison | Profile | Fast model (triage) | Deep model (analysis) | Disk pull | VRAM (Q4) | Tok/sec (M1 Pro) | Quality | |------------------|---------------------|-----------------------|-----------|-----------|---------------------|---------| | `lean` (default) | qwen3:1.7b | qwen2.5-coder:14b | ~10GB | ~9–11GB | 60 / 20 | ⭐⭐⭐⭐ | | `balanced` | qwen3:4b | qwen3-coder:30b (MoE) | ~20GB | ~17GB | 35 / 25 (active=3B) | ⭐⭐⭐⭐⭐| | `heavy` | qwen3:8b | qwen3-coder:30b (MoE) | ~23GB | ~22GB | 22 / 25 | ⭐⭐⭐⭐⭐| Tokens-per-second measured with `--ai-verbose` on a real finding. The MoE architecture is the killer feature: balanced runs with only 3.3B parameters active per token, despite 30B total, so it's roughly as fast as the lean deep model at higher quality. --- ## Methodology + caveats ### What "measured" means Every ◆ number comes from scans on targets where I had explicit authorization. Sample sizes are small (5–10 runs per scenario). I report median times, not means, to reduce outlier noise from DNS flakes. ### Known biases 1. **Network location matters**. Passive sources are weighted toward US-based APIs. An EU scanner hits different latency. 2. **Wordlist size affects brute-force times dramatically**. v2 ships with ~100 words; popular community wordlists (assetnote-wordlists, jhaddix-all.txt) are 10–100×. 3. **Ollama cold-start**. First AI scan includes model load time (~5–30s depending on size). Subsequent scans reuse the loaded model. 4. **Competitor benchmarks were run with each tool's defaults**. They may perform better with tuning I didn't do. ### What's NOT measured (and why) - **Accuracy (false-positive rate)** — requires a labeled dataset per vulnerability class. I don't have one I can share publicly. Anecdotal: AI cascade cuts FP rate ~30–40% vs raw rule matches because the triage model filters obvious non-issues before the deep model writes the finding. - **Cost**. God's Eye is free, runs locally. The only cost is electricity + hardware. - **Scale beyond 10k subdomains**. The distributed mode (Fase 5) isn't implemented yet. ### Reproducing these numbers ```bash # Bench the event bus go test -bench . ./internal/eventbus/ # Bench the store go test -bench . ./internal/store/ # Time a real scan (use a target you own) time ./god-eye -d your-own-domain.com --pipeline --profile quick ``` For the competitor comparison, install each tool and run it with its defaults; honest comparison is the point. --- ## What's changed from v0.1 v0.1 was a 30-second subdomain enumerator with bolted-on AI. v2 is a different shape. | Area | v0.1 | v2 | |-----------------------|-----------------------------|--------------------------------------------------| | Architecture | Monolithic `scanner.Run` | Event-driven, 27 registered modules | | Subdomain sources | 20 passive | **26 passive** + 6 active (AXFR, GitHub dorks, CT streaming, permutation, reverse DNS, supply chain) | | Vulnerability modules | 6 checks | 6 + GraphQL + JWT + Headers + Smuggling, Nuclei-compat layer planned | | AI | 2 hardcoded models | 3 profiles, auto-pull, verbose mode, agent interface | | Continuous / ASM | Not supported | `--monitor-interval` + diff engine + webhooks | | User experience | 25+ flags required | Interactive wizard at zero-flag launch | | Config | CLI-only | CLI + YAML + named scan profiles + AI tiers | | Tests | None | 185 across 15 packages, race-detector green | --- ## Contributing numbers If you run benchmarks on your own infrastructure and want them included, open a PR against this file with: 1. Your methodology (command line, number of runs, target characteristics) 2. The raw times 3. Hardware spec (CPU, RAM, and if AI: GPU + VRAM) I'll merge anything reproducible and properly scoped.