# One Research Loop, Evidence Matched to the Target

> Why vulnerability research needs target-specific harnesses and oracles, but one shared discipline for evidence, novelty, and impact.

Published: 2026-07-11

Canonical article: https://0.security/blog/one-research-loop-evidence-matched-to-the-target/

A protocol implementation, a native library, and an operating-system kernel do
not fail in the same way. Testing them with one generic prompt or one universal
scanner erases the details that determine whether a result is real.

The harness should match the target. The standard of evidence should not change.

That distinction is shaping pwnkit's research architecture inside 0sec. Its
specialized engines can preserve their native inputs, execution traces, and
oracles while moving through the same staged discipline:

```text
Discover → Reachability? → Harness? → Execute? → Verify → Novelty? → Impact?
```

Verification is mandatory before a hypothesis can be promoted. The other stages
are target-dependent. If a stage cannot run, it stays skipped or inconclusive;
it does not silently turn green.

## Different systems need different proof

For HTTP protocol conformance, a concrete request and response can be judged
against a deterministic rule. The model may propose where an implementation
diverges from the specification, but it does not decide whether its own theory
is correct.

For userspace memory safety, the useful evidence is a sanitizer or Miri
observation bound to the build and input that produced it. A bounded campaign
that finds no crash is not proof that the program is safe.

For Linux kernel work, a single crash can be boot-order luck or an ambient
sanitizer report. Stronger evidence requires the same signature across fresh VM
boots, tied to the kernel tree, configuration, reproducer, and captured dmesg.

For mobile applications, passive intake can identify backend targets and risky
configuration. Those indicators are not vulnerabilities by themselves. An
authorized backend can be handed to a web-testing engine; passive signals remain
hypotheses until dynamic verification exists.

For XNU and IOKit, deterministic selector modeling and input generation are
useful today. A panic log alone is not yet enough: attribution, minimization, and
repeated fresh-VM reproduction are still required before promotion.

## Proof strength is not novelty

We track proof strength as a monotone ladder:

```text
candidate → reachable → observed → reproduced → impact-proven
```

This answers: *How strongly did we demonstrate the behavior?*

Novelty answers a different question: *Has the same issue already been fixed,
reported, or queued elsewhere?* A reproduced bug can be a duplicate. A source
review that finds no matching advisory has not necessarily proved novelty.

That is why a novelty check with no successfully queried sources is recorded as
unchecked, never novel. Mailing lists, commits, pull requests, advisories, issue
trackers, and ecosystem databases provide different receipts depending on the
target.

Impact is separate again. A crash does not automatically imply data access,
authentication bypass, controlled memory corruption, or privilege escalation.
Those claims need their own evidence.

## Differential execution turns patches into experiments

Security patches are unusually valuable research inputs because they provide a
natural pair: vulnerable and fixed behavior.

Run the same input against the two revisions. If only one side exhibits the
behavior, the patch supplies a deterministic comparison point. The same method
works across versions, configurations, protocol implementations, and vendor
backports.

If either side fails to build or execute, the comparison is inconclusive. An
infrastructure failure must never become a vulnerability claim.

This approach also makes variant hunting more disciplined. A generated checker
should identify the vulnerable revision and stop identifying the fixed one
before it is trusted to sweep sibling code.

## What exists today

The shared research plane currently connects:

- deterministic HTTP conformance checking
- userspace sanitizer and fuzzing campaigns
- agentic best-of-N investigation with independent verification
- repeated-boot Linux kernel reproduction
- mobile static intake with explicitly scoped backend handoff
- XNU selector discovery and deterministic input generation
- the existing web, AI, source, package, and on-chain pipeline

Some paths intentionally stop at inconclusive because their stronger proof
machinery is not complete yet, XNU panic handling among them.

The goal is to make every claim auditable: what ran, against which build, what
the oracle observed, what did not run, what was checked for novelty, and which
security impact was actually demonstrated.

That is the difference between an interesting hypothesis and a finding an
engineer can trust.