From Suspicion to Reproducible Evidence

Claude-Red’s exploit-development and fuzzing skills are most useful when they are read as evidence workflows rather than as recipes for producing payloads. This chapter focuses on the gap between suspicious behavior and a defensible vulnerability claim. It explains how to separate a crash from its cause and impact, how fuzzing turns a large input space into a structured experiment, and why reproducibility, environment capture, cleanup, and regression testing matter to the repository’s model of authorized security research.

A crash is evidence of behavior, not impact

A crash tells a researcher that some input or sequence changed a program’s behavior. It does not, by itself, say why the change occurred, whether it can be repeated, whether an attacker controls the relevant state, or whether the result affects confidentiality, integrity, availability, or privilege. The same visible failure can come from a memory-safety error, an assertion that intentionally stops execution, an unavailable resource, a race, an environmental mismatch, or a flaw in the test harness.

Claude-Red’s exploit-development skill separates these questions into bug identification, root-cause analysis, trigger identification, impact assessment, mitigation interaction, reliability work, testing, and deployment. That sequence is a diagnosis model. The researcher starts from an observable symptom, eliminates alternative explanations, identifies the condition that triggers it, and then tests what control or consequence follows.

This separation protects both technical accuracy and operational safety. Calling every crash an exploit exaggerates risk and can lead to unnecessary changes. Treating a reliable security-relevant condition as a harmless crash understates risk. A finding should say which part has been observed, which part has been inferred, and which part remains provisional.

Root cause gives the symptom a mechanism. It may identify an out-of-bounds access, use-after-free, integer conversion error, type confusion, missing authorization check, or concurrency failure. The mechanism matters because it determines what inputs and environments are relevant, which mitigations might alter the result, and what remediation should address the underlying defect. A stack trace can locate a failure without explaining the ownership or boundary error that produced it.

Trigger conditions then narrow the claim. Does the issue require a particular protocol message, file structure, object state, timing relationship, privilege, platform, or build configuration? Can the researcher minimize the input while preserving the behavior? Does the result survive a clean target snapshot rather than only a contaminated debugging session? A trigger that depends on an unrecorded environmental accident is weaker than one whose preconditions are understood and repeatable.

Impact is a separate judgment. A crash may create denial of service, but it may also reveal data, corrupt state, cross a privilege boundary, or fail to produce any security consequence beyond termination. The repository’s methodology names categories such as information disclosure, privilege escalation, and code execution, but the presence of a category in a skill does not establish that a particular bug reaches it. Impact must follow from the observed mechanism and the controls in the tested environment.