ravage

Differentiation Roadmap

This page separates what Ravage already does from what still needs to be built. For the current system design, read Architecture. For code pointers and contribution rules, read Technical Guide.

Current Differentiators

Evidence-First Agent Loop

Ravage does not accept model-written claims as findings. The model selects JSON actions, the scoped runtime executes them, observations are recorded, and findings are accepted only after tool-backed evidence.

This matters because agent traces can be inspected after the run:

• model action;
• tool request;
• tool response or summarized observation;
• evidence decision;
• report output.

Shared Runtime For Agent And DAST

ravage attack and ravage scan share the same broad run shape:

• engagement brief;
• scope checks;
• tool capability preflight;
• audit database;
• workspace artifacts;
• report output;
• optional observer.

This lets deterministic scans and model-driven runs be compared without inventing different report formats.

Scoped Tool Runtime

Ravage is localhost-first in the active CLI. Public/DNS targets are rejected before scans or attacks start; authorized apps should be exposed on 127.0.0.1 or localhost. External tools can run on the host, in Docker, or in auto mode. Required capabilities fail closed unless degraded mode is explicitly allowed.

Source-Guided Dynamic Proof

Ravage can inspect source context when the selected mode permits it, extract routes/params/sinks, then run bounded dynamic workflows against the live target.

Implemented workflow areas include SQLi, XSS, SSTI, command injection, LFI, IDOR/authz, SSRF, XXE, JWT/session issues, auth bypass, GraphQL IDOR, uploads, deserialization, encrypted cookies, and selected source-secret pivots.

The important distinction is that source context guides candidates; it does not become proof by itself.

Benchmark Honesty

XBEN runs record the benchmark context mode:

• black-box;
• white-box;
• source-aware;
• compatibility source-aware alias for white-box.

This prevents mixing description-only black-box and white-box results as if they were the same benchmark.

Local Reviewed Memory

Memory is local SQLite, redacted, reviewable, and advisory. It can suggest lessons, but it cannot report findings, capture flags, override scope, or store raw secrets.

Inspectable Run Artifacts

Runs produce machine-readable and human-reviewable outputs:

• audit.db;
• workspace/events.jsonl;
• workspace/transcript.jsonl;
• workspace/artifacts/;
• report.json;
• rendered report artifacts when available.

Trace-quality and failure-taxonomy tooling make benchmark misses easier to debug without changing the benchmark result itself.

Current Limits

HTTP History And Replay UI

Ravage records observations and artifacts, but it does not yet provide a first-class Burp/Caido-style request history, diff, replay, and mutation UI.

Auth Workflow Authoring

Browser/session actions exist, including login and cookie synchronization, but Ravage still needs richer declarative auth workflow configuration:

• role profiles;
• success and expiry checks;
• MFA/TOTP hooks;
• avoid/focus rules;
• durable session review.

Multi-Agent Orchestration

The repository has early specialist packages and many workflow modules, but the main runtime is still centered on one ai-web loop. A mature planner/recon/ exploit/report specialist graph is still future work.

Proof Confidence Scoring

Ravage has evidence gates and optional proof-bundle verification, but confidence is not yet a consistently scored first-class report dimension across every finding class.

Source-Guided Breadth

Source-guided workflows are broad but uneven. Some vulnerability families have multiple tested patterns; others still need more frameworks, encodings, auth states, and negative tests.

Terminal Robustness

Named terminal sessions exist for approved tools, but prompt detection, stall recovery, long-running process health, and structured interactive workflows need more hardening.

Native Benchmark Infrastructure

XBEN can run locally, but Apple Silicon Docker emulation can distort target behavior for some amd64 images. Serious scoring should run on native amd64 Linux with stable Docker storage.

Build Order

1. Request history and replay Build a first-class captured request store with replay, mutation, diffing, and evidence links.

2. Auth workflow configuration Add declarative login/session plans, role profiles, validation checks, and safe credential handling.

3. Proof confidence Normalize confidence fields across finding classes and connect them to proof bundles, replay results, and report rendering.

4. Multi-agent graph Introduce scoped specialist contracts for recon, exploitation, source-guided analysis, browser workflows, and reporting without losing the audit trail.

5. Source-guided expansion Extend workflows with more framework coverage, more negative tests, and better failure classification.

6. Operator review surface Add a richer UI for reviewing runs, memory candidates, proof bundles, requests, and benchmark failures.

7. Benchmark infrastructure Standardize native amd64 benchmark runners, cost controls, artifact retention, and repeatable comparison reports.

Non-Goals

Ravage should not become:

• a stealth exploitation platform;
• an unsupervised public-internet scanner;
• a benchmark-specific script collection;
• a system that reports vulnerabilities from model text alone;
• a memory system that stores raw secrets or raw customer responses.

Keeping This Roadmap Honest

When adding roadmap claims:

• point to the implementing files or tests when a feature is marked current;
• distinguish source-guided and description-only black-box behavior;
• do not claim benchmark performance without run artifacts;
• keep old execution plans out of the primary docs path;
• update How To Use, Architecture, and Technical Guide when CLI or runtime behavior changes.

This site is open source. Improve this page.