Research
Implemented10 minRAVEN: proving exploitability, not guessing it
RAVEN reports only what it can re-derive from an observed, unforgeable server-side state change. Its governing line: an attack sent is not the same as a target compromised.
Attack sent is not pwned
Scanners tell you a parameter "looks injectable" and bury teams under false positives. RAVEN takes the opposite stance: a finding exists only when a benign, controlled action produces a server-side effect that cannot be faked, re-derived from the actual request and response. If it cannot prove the effect, it does not report a finding — it records an honest "unverifiable" and moves on.
RAVEN is not a new engine. It is a profile of the shared autonomous agent — observe, hypothesize, select an action, attack, observe the result, validate — with the deterministic verifier as its oracle. It never authors a finding itself: a confirmed validator result becomes a promotable verifier result, and the membrane decides.
Proof by unforgeable postcondition
Each vulnerability class has a validator that confirms only on a postcondition that cannot be faked:
- ▸OS command injection: a bare echo of a one-time nonce appears in the response while the literal payload does not — evidence the command executed — followed by a benign identity command whose output confirms it.
- ▸Server-side template injection: a boundary-anchored arithmetic result appears that is absent from the baseline and is not simply the payload reflected back.
- ▸SQL injection: an engine error on a lone quote that the benign baseline never produced, then a controlled extraction of the database version.
- ▸Server-side request forgery: an ephemeral loopback collaborator receives the nonce path, proving server-side egress. If the channel is blind, the result is honestly unverifiable.
- ▸Path traversal: the unmistakable first line of a system password file appears in the response. Open redirect: a 3xx redirect to a controlled origin.
The honest exception: reflected cross-site scripting proves unescaped reflection into an HTML sink, but RAVEN does not run a browser, so script execution is inferred, not demonstrated — and it is labelled as inference. Everywhere else, no unforgeable proof means no finding.
How a run is structured
- 1Network discovery: a connect scan and service fingerprinting.
- 2Per-service adapters shape the attack surface (web is the most mature).
- 3The agent loop proposes and tests, ordered by information gain.
- 4The action space moves from prove, to weaponize, to post-exploit, to fuzz.
- 5The evidence authority — membrane plus exploit verifier — settles each claim.
- 6Confirmed accesses compose into a chain of achieved-access states.
A frontier reasoner may widen or reorder the probe set, but it is unioned with a heuristic seed so coverage never shrinks, and it never asserts a verdict. The reasoning can only add questions; the deterministic layer answers them.
Safety and scope
RAVEN operates against live targets, so it is gated by Rules of Engagement at several layers: it requires an active-assessment profile and an authorization reference, the runner refuses out-of-scope hosts, and the one genuinely destructive probe is off unless explicitly enabled. Authorization is deny-by-default and bound to a specific, time-boxed grant.
Honest status: web, REST and several vulnerability classes are mature; GraphQL, SOAP and WebSocket adapters today prove only a subset; one protocol is deliberately not implemented rather than stubbed, "because a fake stub would violate never-faked". And "zero false positives" is a design property — no proof means no finding — not a measured rate. Validation against a broad set of real deployed applications is still pending, and we do not quote precision numbers.
References
- [1]OWASP Web Security Testing Guide
- [2]OWASP Top Ten
- [3]MITRE CWE (CWE-78, CWE-89, CWE-22, CWE-79, CWE-918, CWE-1336…)
- [4]MITRE ATT&CK — Initial Access / Execution
References point to public, well-known technical sources for further study.
Related articles
