What counts as proof depends on the target

An HTTP response can show that a server accepted an invalid request. A sanitizer report can show that a parser accessed memory outside an allocation. Neither observation, by itself, establishes the same security impact.

Research becomes easier to review when the record says exactly what each test demonstrated. The tools can differ across targets while the discipline stays consistent.

Give each target an appropriate test

For a protocol implementation, compare a concrete request and response with the rule the server should enforce. Preserve the bytes: a model’s summary may omit the detail that makes the behavior significant.

For a userspace library, keep the input, build configuration, and sanitizer output together. If the reproducer depends on an optional feature, record that dependency. A clean run without the feature doesn’t test the same path.

For a kernel, capture the source revision, configuration, reproducer, and complete relevant log. Repeating the test on fresh boots helps distinguish the intended failure from a previous run’s state or an unrelated warning.

Static mobile analysis has another boundary. An endpoint or risky configuration can be a lead, but its presence doesn’t establish an exploitable backend vulnerability. Dynamic testing needs its own authorization and evidence.

Keep progress and uncertainty visible

A useful investigation moves through questions:

What looks wrong?
Can the relevant caller reach it?
Can we exercise it in a controlled environment?
What behavior did we observe?
Can we reproduce that behavior?
What security impact did we demonstrate?

These questions aren’t interchangeable. Finding a path in source doesn’t mean a test reached it. A working harness doesn’t mean the candidate triggered. A reproduced crash doesn’t automatically establish a privilege escalation.

If a build fails or a required device isn’t available, record the limitation at that stage. It should remain visible when someone reads the eventual report.

Check novelty separately

A well-reproduced bug can already be known. Search the relevant commits, advisories, issue trackers, and patch queues before treating a candidate as new.

The search record matters too. If a source couldn’t be queried, an empty result says little. A different filename, driver hash, or package release can still contain a previously reported flaw.

Our driver investigation is one example of why proof and novelty need separate checks.

Use the patch as a comparison

When a fix is available, run the same input against vulnerable and fixed revisions. Keep the environment as similar as possible and check that both tests reach the relevant code.

A failure on one revision and its absence on the other is useful evidence. A build failure on one side is an incomplete experiment. If the proposed detector still reports the fixed code, understand why before using it to search for variants.

The resulting report should let another engineer reconstruct the investigation: what ran, what changed, what was observed, and what remains unknown. That record is more useful than a single confidence score.