What makes a good seed corpus for a fuzzing campaign, and what does corpus minimisation preserve?

### The corpus is the fuzzer's memory A **seed corpus** is the set of starting inputs a campaign begins from, and the **working corpus** is the evolving set the fuzzer retains during the run because each entry reached something new. Together they are the most valuable artefact a fuzzing programme produces: a run that starts from a good corpus reaches interesting code in minutes, and a run that starts from an empty corpus may spend hours rediscovering the format's header. ### What makes a seed good - **Real, not synthetic.** Captured production inputs encode the shapes the format actually takes, including the vendor quirks nobody documented. In a hotel booking channel manager, that means real partner availability-and-rate messages, not hand-written examples of the specification. - **Diverse in features, not in volume.** One message per distinct feature beats a thousand near-identical ones: each optional block, each encoding, each rare record type, each locale-dependent numeric or date format. Coverage of *variants* is what buys reach. - **Small.** Fuzzers mutate what they are given, and the cost of an execution scales with input size. A 47 KB message and a 900 byte message may reach the same code; the small one is worth far more per second. - **Fast and valid.** A seed that already fails the schema check teaches the fuzzer nothing about the interior. - **Scrubbed.** Production captures carry credentials, personal data and customer identifiers. Corpora get committed, shared and shipped to shared infrastructure, so treat scrubbing as a precondition, not a cleanup step. - **Including past failures.** Every input that once caused a failure goes back in as a seed. It is both a regression check and a known-interesting starting point. ### Two different things are called minimisation This is the term to disambiguate out loud in an interview, because the two operations solve different problems. **Corpus minimisation (distillation)** operates on the *set*. It selects the smallest subset of the corpus that preserves the coverage the whole set achieved, discarding entries whose reach is already covered by others. A campaign in the channel manager that had accumulated 1,240 captured partner messages might distil to 388 files with no loss of reached edges. The benefit is direct: the fuzzer cycles through the corpus, so a corpus three times larger than necessary means each genuinely interesting entry is mutated a third as often, and the memory and start-up cost rise for nothing. **Test-case reduction (input minimisation)** operates on a *single input*, and usually on a single failing one. It repeatedly removes or simplifies parts of the input while checking that the same failure still occurs, until nothing more can be removed. This is what turns a 47 KB message that crashes the parser into a 31 byte reproducer a human can read and a developer can debug. Notice that the check being preserved here is "the same failure signature still happens" — it is a property of the *failure*, not of coverage. Both are automated and both should be routine. Confusing them in an interview is a common stumble; naming which one you mean is a cheap way to sound like you have run a campaign. ### Operating the corpus over time A corpus is a living asset and needs the same care as any other: - **Persist it between runs.** A campaign that starts cold every night throws away the search progress of every previous night. Store the working corpus and restore it at start-up. - **Version it, and treat additions as reviewable.** New entries arriving from a run are fine; new entries arriving from an unknown source are inputs you are about to execute. - **Re-distil periodically**, not on every run — distillation itself costs a full pass over the corpus. - **Re-seed after a format change.** When the message format gains a new record type, no existing seed exercises it, and the fuzzer has no way to invent a valid one from nothing. Add examples deliberately. - **Watch the coverage curve after distillation.** If reached edges drop after a distil, the distillation criterion was too coarse for the target. ### Why interviewers ask this Seeding is where fuzzing stops being "point the tool at it" and becomes engineering judgement. A candidate who says "I would collect real inputs, cut them down to one per feature, scrub them, distil the set against coverage, and keep every past crasher as a permanent seed" has clearly run something. A candidate who treats the corpus as a folder of random files, or who cannot say what minimisation is preserving, has not.