A lead becomes useful when it can survive an attempt to prove it wrong. That starts by making the claim narrow enough to test.
State the claim.
Describe the input, the security boundary it might cross, and the outcome you expect to observe. “This function looks unsafe” is too broad; a claim should identify the condition under which a specific behavior would matter.
Record the affected version and the assumptions the claim depends on. If the behavior requires a setting, a particular file format, or a privileged caller, those conditions belong beside the claim from the start.
“The evidence should be strong enough to narrow the claim, not just support it.”
Build a small test.
Reduce the path to the smallest input that can exercise it. Preserve the exact bytes, environment, and observed output. Repeat the test after changing one variable at a time so that a surprising result can be tied to a cause rather than an accidental difference in setup.
Static evidence can establish reachability and risky operations, but it does not automatically establish runtime impact. If execution is unavailable, say what the code shows and what remains unverified.
Test the alternative.
Look for the strongest benign explanation. A length may be checked earlier, a caller may enforce permissions, or the apparent sink may receive a transformed value. Follow those possibilities with the same care used to build the original case.
When a counterexample succeeds, revise the claim. A narrower finding with a clear boundary is more valuable than a dramatic claim that the evidence cannot carry.
Report the limit.
Keep the proof, affected conditions, impact, and missing evidence together. Separate confirmed behavior from suspected consequences. A reader should be able to see exactly where observation ends and inference begins.
That discipline makes a finding easier to reproduce, easier to review, and easier to fix. It also leaves a useful record when the lead does not become a vulnerability.