god-eye/BENCHMARK.md

📊 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 — 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 — Fastest pure passive subdomain enumeration. Massive source list, huge community.
• amass — Academic-grade subdomain + ASN graph analysis. Unmatched historical coverage.
• assetfinder — Minimal, composable, Unix-philosophy. Great as a Bash pipe stage.
• findomain — Very fast, ergonomic, good free tier without API keys.
• BBOT — Python framework with 100+ modules. Closest competitor to v2.
• 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)

./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)

./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)

./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

./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

# 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.