Methodology & Disclaimer

How Omenwave models plausible chaining potential

Omenwave reasons about how one vulnerability's capabilities could, in principle, satisfy the preconditions of another — drawn entirely from public metadata. This page explains what the tool does, exactly how it decides, how to read its scores, and where its limits are. It is written for defenders.

01What Omenwave is — and is not

Real, comprehensive CVE-A → CVE-B chain data does not exist as a public dataset. Rather than hardcode a handful of famous chains, Omenwave derives an abstract capability profile for every CVE from its published metadata, then reasons about which profiles could fit together. The result is a map of modelled potential: capability logic, not observed activity.

Everything Omenwave produces describes attacker position and kill-chain stage in the abstract — “what a step yields” and “what the next step needs” — never technique, payload or procedure.

02Data sources & attribution

Omenwave ingests three public feeds on your own server and stores only their metadata. It transforms that metadata; it does not redistribute the feeds.

Where exact licence wording matters for your deployment, treat the official source pages above as authoritative — the descriptions here are factual summaries, not licence terms. Omenwave is an independent research tool and is not affiliated with, sponsored by, or endorsed by NIST, CISA or FIRST.org.

03The capability model

For each CVE, the classification engine (classification.py, rule version v0.1.1) reads the CVSS base vector as its primary signal and uses CWE as an enrichment/override. A CVE with a missing or uninformative CWE still classifies — at lower confidence. The output is a profile with a precondition, a postcondition and a stage.

Which CVSS score is used

A CVE record can carry several CVSS scores. The engine uses one, chosen by a published source policy: CVSS 3.1, then 3.0, then 4.0, then 2.0, preferring NVD’s Primary score within a version. CVSS 3.x comes first because the model’s rules are written in its terms. When only CVSS 4.0 is available it is mapped onto those terms: confidentiality, integrity and availability take the higher of the vulnerable-system and subsequent-system impacts; any subsequent-system impact counts as a scope change; and passive or active user interaction counts as user interaction required.

Machine-readable form: cvss_source_policy in GET /methodology.

Rule versions in the stored corpus

Classification runs when a CVE is ingested, and the result is stored with the rule version that produced it. When the rule changes, every stored classification is recomputed from its stored CVSS and CWE inputs before the next update. That recomputation is a model update, not a change to the CVE, so it never appears in the Newly-Discovered feed. The share of the corpus classified by the current rule is published live at the top of this page and in GET /methodology. An automated behavioural fingerprint of the classifier fails the build whenever classification output changes without a new rule version, so the version label always describes what is served.

Kill-chain stage

Every CVE is placed at one coarse, research-oriented stage. Chaining generally moves forward through them, though the precondition logic — not a rigid stage order — is what actually gates a hop.

Access level (attacker position)

An attacker holds a position. A CVE requires a minimum position to be used, and grants a (usually higher) position on success. These sit on a three-rung lattice:

NONE

No prior access — network-reachable, unauthenticated.

USER

User-level / low-privilege authenticated access.

PRIV

Privileged / administrative access.

The requirement (req_access) is derived from CVSS Privileges Required; the requirement's reach (req_vector) from Attack Vector (NETWORK / ADJACENT / LOCAL / PHYSICAL). A step never grants less than it required — it keeps at least the position it started with.

Capability tags

From CVSS impact metrics (confidentiality / integrity / availability), scope change, and CWE, each CVE is tagged with the capabilities it yields:

CODE_EXEC

Can run code in some context (classic full C/I/A impact, or a code-exec CWE).

PRIV_GAIN

Raises the attacker's privilege level (signalled by CVSS scope change crossing a boundary).

AUTH_BYPASS

Bypasses authentication or authorization — becomes at least USER.

CRED_ACCESS

Obtains credential material.

INFO_DISCLOSURE

Reads data it should not (confidentiality impact short of full RCE).

LATERAL

Enables reaching other hosts or services.

TAMPER

Modifies data / integrity without full control.

DOS

Availability impact only.

The granted position follows from the tags: PRIV_GAIN lifts to PRIV; CODE_EXEC yields at least USER, or PRIV when the CVSS scope changed; AUTH_BYPASS yields at least USER. Disclosure tags do not raise the position by themselves — but the material they produce can satisfy a downstream requirement (handled as a credential bridge, below).

Terminal

A CVE is terminal when its capabilities are only DOS and/or TAMPER and it grants nothing beyond what it required. A terminal CVE is an end-state (for example, a pure denial-of-service): it yields nothing to chain forward, so the engine returns no next hops from it.

Classification confidence

How well-supported a profile is, surfaced rather than hidden:

• high — a CVSS vector and at least one usable CWE are present.
• medium — a CVSS vector, but no usable CWE (classified from CVSS alone).
• low — no CVSS vector available.

04How a plausible next hop is decided

The chaining engine (chaining.py) proposes a hop A → B under one governing principle:

The four bridges

When a source's postcondition satisfies a candidate's precondition, the engine labels why with one of four bridges:

Why front-door → front-door links are excluded

This is a deliberate design choice made for credibility. If a candidate requires nothing to begin with — an unauthenticated, network-reachable vulnerability — then reaching it does not depend on the previous step. Linking two such “front doors” would inflate every graph with coincidences and imply causation where there is none. Omenwave only draws an edge when the earlier step genuinely lowers the bar for the next, so a pathway means something. For the same reason, a hop back to a pure RECON step is never treated as re-entry once a chain has moved past reconnaissance.

Edge confidence

Each proposed edge is scored for logic plausibility (distinct from the classification confidence of the endpoints). Points accrue from four factors, and the total maps to a level:

• Precondition-match quality — a strong bridge (local-presence, access-level) scores highest; credential less; credential-weak none.
• Stage adjacency — neighbouring kill-chain stages are most plausible; distant jumps score less.
• Environment proximity — same product adds weight (same vendor is neutral, since cross-product chains are legitimate).
• Endpoint classification confidence — a bonus when both ends classified at high confidence.

Ranking

Among all satisfied candidates, the engine ranks logic plausibility first, then real-world signal: edge confidence dominates, then CISA KEV membership, then EPSS probability, then CVSS base score, with a small nudge for same-product proximity. The highest-ranked hops surface first.

05Reading the scores

The explorer summarises a traced pathway with three headline figures. Each answers a different defender's question.

06Limitations & honest framing

Trust is the whole point of Omenwave: it aims to be a source people can check, not one they must take on faith. That obligates us to be explicit about what the model does not know. Treat every pathway as a hypothesis to investigate, not a finding.

The five points below are the honest framing that governs everything the tool outputs. They are surfaced verbatim, in machine-readable form, at GET /methodology.

Plausible pathways

Not confirmed chains. Every edge is modelled potential — that what one step yields could satisfy what the next step needs — never an assertion that a chain will work, is reachable, or has been observed. The correct reading of any pathway is “worth investigating,” not “this is how you’d be attacked.”

Evidence per edge

Each hop carries a structured, auditable justification: what the source provides, what the destination requires, the bridge that links them, and the confidence factors. The reasoning is shown so it can be checked, disputed, or overridden — not asserted.

Public metadata only

The engine reasons from CVSS, CWE and CPE. It never inspects source code, advisories or exploit behaviour, so it inherits every gap and error in that metadata. Older CVEs (pre-CVSS v3) and those tagged NVD-CWE-noinfo / NVD-CWE-Other classify at lower confidence; some CVEs lack a CVSS vector entirely.

CPE-matching noise

Vendor/product association comes from CPE, which is coarse and sometimes inconsistent across records; same-product proximity — which nudges ranking and edge confidence — can be over- or under-stated as a result. Beyond CPE the engine has no view of your topology, configuration, compensating controls, or whether two vulnerable components can actually reach each other, so a satisfied precondition is a logical fit, not proof of reachability, and not evidence that both CVEs even co-occur in a given environment.

No exploitation detail

The model describes attacker position and kill-chain stage in the abstract only. It contains no technique, payload or procedure, by design. A tidy, high-confidence edge can still be unrealistic in the real world; confidence reflects the model’s internal support, not ground truth. The very detail operational misuse would require is deliberately withheld.

06.5Validation against documented chains

An authority should show its accuracy, not ask for faith. Omenwave is tested against a curated set of documented, public multi-CVE attack chains (ProxyLogon, ProxyShell, ProxyNotShell, OMIGOD, Log4Shell→PwnKit, noPac and more). For each, the harness runs the same classification and chaining logic the live tool uses and asks: does the model reproduce the documented pathway, in the right kill-chain stage order? Full methodology, dataset citations and honest limitations are in the validation report (docs/VALIDATION-REPORT.md).

06.6Is confidence calibrated?

Confidence is only worth showing if it tracks reality. Using the same documented-chain benchmark, we ask a sharper question: do edges the model rates with a stronger bridge or higher confidence actually coincide with a documented real-world adjacency more often? A rate here is a calibration signal — how often a modelled edge lines up with a documented link — not a probability that a chain works or is exploited. Live from GET /confidence/calibration.

07Intended & responsible use

Omenwave exists to help defenders reason about consequences. Appropriate uses include:

• Prioritisation — deciding which CVEs to remediate first by their leverage, not their base score alone.
• Awareness — illustrating why a “low-severity” foothold vulnerability deserves attention.
• Patch-decision support — using break-the-chain counts to make the case for a specific fix.

08Disclaimer

Classification and chaining logic are versioned (RULE_VERSION 0.1.1) so that changes to the model are auditable over time. The authoritative rules live in backend/app/classification.py and backend/app/chaining.py, and this methodology is itself versioned (v1.3.1) and published at GET /methodology.

09Versioned changelog

Two version numbers move independently, and every material change is recorded here so the model can be checked against its own history:

Methodology version

This page and the model write-up — prose, framing, limitations, and the published summary.

Rule version

RULE_VERSION — the engine’s classification and chaining logic, the constant defined in classification.py.

The machine-readable form of this changelog — with both version numbers per entry — is served at GET /methodology. When the model or its framing changes, bump the appropriate version, prepend an entry above, and mirror it in the endpoint’s METHOD_CHANGELOG and in docs/METHODOLOGY.md.

← Back to explorer