AeonDave jazzer
JVM-native fuzzing engine with @FuzzTest workflow and built-in security bug detectors.
Quick Start
<!-- pom.xml -->
<dependency>
<groupId>com.code-intelligence</groupId>
<artifactId>jazzer-junit</artifactId>
<version>LATEST</version>
</dependency>
@FuzzTest
void fuzzDecode(String input) {
assertEquals(input, decode(encode(input)));
}
# Fuzzing mode
JAZZER_FUZZ=1 mvn test
Operator Flow
- Start with JUnit
@FuzzTestin a narrow API surface. - Seed meaningful examples (parameter sources + existing regression inputs).
- Run fuzz mode to discover, then store crash inputs under test resources.
- Keep regression mode in CI to prevent bug reintroduction.
- Expand instrumentation scope only when throughput remains acceptable.
Key Points
- Regression mode by default; fuzz mode via env var.
- Stores generated corpus and crashing inputs in predictable directories.
- Includes bug detectors (e.g., SSRF / path traversal / command injection classes).
Practical Tricks
- Use annotations (
@WithUtf8Length,@InRange, etc.) to constrain data and improve signal density. - Tune run duration with
maxDuration/max_total_timestyle controls. - Configure instrumentation includes/excludes to avoid useless classpath overhead.
- Explicitly manage detector hooks if false positives appear in complex multi-thread setups.
Common Pitfalls
- One giant fuzz test that mixes unrelated APIs reduces triage quality.
- Ignoring corpus path conventions causes lost regressions.
- Treating finder output as final root cause without replaying and minimizing reproducer.
Configuration Notes
- Option precedence matters: defaults < env vars < system properties < JUnit params < CLI.
- For standalone mode, verify classpath and target class/method wiring first.