Omvia GraphWalker

Run the attack. See what your monitoring missed. Immunise the gap. Run it again.

GraphWalker executes real techniques against the scope you grant and reports findings with the evidence that confirmed them. For every technique it ran it tells you whether anything in your estate saw it — and where nothing did, it can generate the detection, apply the fix with its rollback, and run the same technique again to show the gap is closed.

list bucket anonymous access key assume role · prod AccessDenied assume role · dev snapshot → volume proof goal backtrack
A node that fails its condition does not end the walk. It retreats to the last node that worked and tries another branch — and the refusal stays in the record.

What a run gives you

Four things, and the fourth is what turns the other three into a loop rather than a report you file.

  1. Findings that carry their proof

    A working credential, a file we read, a published check that matched — not a version number compared against a range. Ranked by what is actually exploitable and reachable, with actively-exploited issues tested first.

  2. Your detection gap

    For every technique the run exercised: whether your monitoring saw it, whether anything watches it at all, or whether we could not get a usable answer. Those are three different problems and we keep them apart.

  3. A fix that can be undone

    Where we can propose a concrete change, it ships with its rollback — a change that cannot be reversed is refused before anyone is offered it. Nothing is applied without a second, separate grant from you.

  4. The same attack, run again

    After you fix something we re-run the technique that found it and report FIXED, STILL_OPEN or INCONCLUSIVE — the third because a technique that never ran cannot be reported as a fix.

Where the techniques come from

Every technique in our graph was written from something that actually happened: a bug bounty finding, a penetration test, a published writeup, or a capture-the-flag problem somebody solved end to end. None of it is generated from a vulnerability feed.

And each node is a technique rather than a target — read the metadata service, reuse the credential you just found, pivot on the trust you just proved. That is why one library reaches a cloud account, a Kubernetes cluster, an identity tenant and a Windows domain, and why a technique proven in one engagement composes into the next.

How the graph is built, and how it learns

Your SOAR can drive the whole loop

Resolve a fired detection to its remediation. Apply a mitigation, or roll it back. Generate a detection for a technique nothing was watching. Arm the hunt the graph says the attacker moves to next. Start an assessment. Measure immunity. All of it from a playbook, in the console your analysts already have open.

It works because the graph already knows. For the attack paths in our library, every technique carries the detections that watch it and the controls that stop it. A response is looked up and applied with its rollback — not improvised for your engagement, and not a generic playbook somebody wrote once and never re-tested.

9 actions a SOAR playbook can call against our API, from resolving a detection to measuring immunity measured 2026-09-09

You do not need a SOAR to be immunised. It is a channel, not the mechanism — the same API serves anyone, and detection content is exported vendor-neutral. We have run the loop against more than one monitoring product precisely so this is not a Splunk story.

The bound worth knowing: this is end to end for attack paths we already hold. A technique the library has never seen still produces a finding with the evidence that confirmed it — it simply does not arrive with a detection and a fix already attached to it.

Two questions, answered separately

Whether the attack still works and whether anyone noticed are independent facts. Most tools merge them into one score. We measure them on separate axes and report both, because the pair is what tells you where to spend.

The shape of a result. A technique can be stopped and invisible, or caught and still working — and those need different work from different teams.
Does the attack still work Did anything see it Verdict What it means
No fired blocked_and_detected Stopped, and you would have known. The only complete outcome.
No silent blocked Stopped, but nothing told you. The next variant is invisible.
Yes fired open Working, and you can see it. A response problem, not a visibility one.
Yes unmonitored open Working, and nothing watches this technique at all.
Unproven unknown INCONCLUSIVE We could not get a usable answer. This is not a finding and we will not round it into one.

How the detection gap is measured

What we have measured so far

Every figure on this site carries the date it was last re-derived. Numbers go stale while the sentences around them stand still, and that is how a vendor ends up believing its own summary.

706 findings recorded across every chain we have run, each carrying the evidence that confirmed it measured 2026-09-09
19 estate-and-technique slots where we proved a detection fired measured 2026-09-09

Find out what your controls actually catch

An engagement starts with a manifest you approve: the scope, what we are allowed to do, a time window, and a switch that stops everything. Nothing runs outside it.

Start an engagement See how it is deployed