What is Fuzzing?

Definition

Fuzzing (or fuzz testing) is a dynamic analysis technique that automatically generates large volumes of random, malformed, or unexpected inputs and feeds them to a program to discover crashes, security vulnerabilities, and edge-case bugs. A fuzzer observes how the program responds to these inputs, flagging any that produce crashes, hangs, assertion failures, or anomalous behavior.

Fuzzing finds bugs that human testers and static analyzers miss because it systematically explores the input space rather than relying on anticipated test cases. Inputs that no human would think to try — malformed binary structures, extremely long strings, unexpected encoding sequences — are exactly what fuzzers excel at generating.

Types of Fuzzing

Blackbox fuzzing

The fuzzer has no knowledge of the program's internals. It generates random inputs and observes outputs. Simple to set up, but coverage is limited — random inputs rarely reach deep code paths that require specific pre-conditions.

Greybox fuzzing (coverage-guided)

The fuzzer instruments the program to measure which code paths each input covers. Inputs that discover new coverage are mutated and re-tried; inputs that cover no new code are discarded. This focuses fuzzing effort on unexplored parts of the code. AFL (American Fuzzy Lop), libFuzzer, and Honggfuzz use this approach.

Whitebox fuzzing (symbolic execution)

The fuzzer analyzes the program's code to generate inputs that satisfy specific conditions — reaching a particular branch, passing a validation check. More sophisticated but significantly more expensive. Microsoft SAGE is the canonical example.

What Fuzzing Finds

• Buffer overflows — inputs that exceed expected size and overwrite adjacent memory
• Use-after-free — inputs that trigger memory management errors
• Integer overflows — inputs that cause arithmetic to wrap or overflow
• Null pointer dereferences — inputs that reach code paths where a null check is missing
• Assertion failures — inputs that violate programmer assumptions
• Infinite loops and hangs — inputs that cause the program to loop indefinitely
• Format string vulnerabilities — malicious format strings passed to printf-style functions

Fuzzing in Practice

Fuzzing is most effectively applied to:

• Parsers and protocol handlers — any code that processes structured input from external sources (file parsers, network protocols, API inputs)
• Cryptographic implementations
• Operating system components and device drivers
• Compilers and language runtimes
• Any security-critical code path

Fuzzing and Autonomous Code Governance

Fuzzing fits into autonomous code governance as a dynamic validation layer. When Hydra generates a fix for a vulnerability in code that processes external input, fuzzing the patched code provides confidence that the fix does not introduce new crash-class vulnerabilities and that the original input that triggered the vulnerability is now handled correctly.

Continuous fuzzing — running fuzz campaigns against the codebase as part of the CI/CD pipeline — surfaces new vulnerabilities as they are introduced, feeding them into the autonomous remediation pipeline before they reach production.