A weekend fuzzing campaign produced 4,117 failing inputs. How do you turn that into filed bugs?

### A pile of crashers is not a list of bugs A long campaign produces failing inputs, not defects. One real bug in a hot code path is hit again and again from different mutations, so the raw output of a weekend run on a hotel booking channel manager's rate-message parser might be 4,117 failing inputs standing for a couple of dozen actual problems. Triage is the pipeline that turns the first number into the second, and it is the part of fuzzing an interviewer can use to tell an operator from a tourist. ### Step 1 — deduplicate by crash signature A **crash signature** is a normalised fingerprint of *how* the program failed, computed so that two inputs hitting the same bug produce the same value. The usual ingredients: - the failure type (fatal fault, abort, assertion, timeout, detector report class); - the top *N* frames of the call stack, hashed after normalising away addresses, and after dropping frames that belong to the harness, the allocator, or the failure handler itself; - for an instrumented-build report, the reported location plus the site where the memory was allocated or freed, which separates two different lifetime bugs that fail at the same read. Both failure modes of this scheme should be stated out loud. **Over-splitting:** the same bug is reached through several call paths, so stack hashing yields a dozen signatures for one defect — mitigated by truncating to a small *N* and by normalising aggressively. **Over-merging:** two genuinely different bugs both fail inside one shared helper, so a shallow signature collapses them into one — mitigated by keeping a couple of frames of context and by re-checking after the bug is fixed to see whether the signature still appears. Deduplication is a heuristic; treat the signature count as a working estimate, not a truth. In the channel manager run, 4,117 inputs might collapse to 63 signatures, which after reduction and review turn out to be 11 distinct defects. ### Step 2 — reduce and confirm For each signature, take one representative input and reduce it: repeatedly strip and simplify while the same signature still reproduces, until you have something small enough to read. Then confirm reproducibility on a clean build. A crasher that does not reproduce is not a non-bug — it usually means the failure depends on state the input alone does not capture: address layout, hash-ordering randomisation, wall-clock or locale settings, an accumulated in-process state from the previous execution, or the run's own random seed. Record the seed and the environment with every finding, and re-run in the same configuration before declaring anything unreproducible. In this leaf's example, a rate field in a locale-dependent numeric format reproduced only on hosts whose default locale used a comma as the decimal separator — the input was fine, the environment was the missing variable. ### Step 3 — rank, and keep two rankings apart Two words get muddled here and an interviewer notices. **Severity** is the technical impact of the defect — what it corrupts, whether it terminates the process, whether it can be reached from untrusted input. **Priority** is business urgency — how soon it gets fixed, given who is exposed and what else is in flight. A hang in a parser reachable from a partner feed can be low severity and top priority; a memory fault deep in an internal tool can be the reverse. Whether a given crash also constitutes a security issue is a judgement owned by the security discipline, not by the fuzzing harness; the triage job is to route it there with a reproducer attached. ### Step 4 — file with everything the fixer needs A filed bug carries the reduced input, the signature, the exact build and instrumentation settings, the seed and environment needed to reproduce, and the reduced input added to the seed corpus as a permanent regression case. Without that last step the same defect is rediscovered next month. ### Continuous fuzzing as a regression asset Fuzzing pays off when it stops being a one-off exercise: - **Persist the working corpus** between runs so each night resumes the search instead of restarting it. - **Run a short, deterministic replay in the pipeline.** Every committed crasher is replayed on every change; this is fast, stable and is the part that belongs in a merge gate. - **Run the open-ended search out of band**, on a schedule or continuously, on its own hardware — an open-ended search has no fixed duration and must never gate a merge. - **Alert only on new signatures.** Re-reporting known findings is how teams learn to ignore the fuzzer. - **Track the coverage curve and the corpus size as health metrics.** A curve that has been flat for weeks means the campaign has converged and needs new seeds, a new harness, or structure knowledge — not more hours. Framed that way, the corpus and the committed crasher set become a durable regression asset that keeps paying long after the campaign that produced them.