|
| 1 | +name: go-fuzzing |
| 2 | +description: | |
| 3 | + ## Go Fuzzing Vulnerability Discovery |
| 4 | +
|
| 5 | + Goal: Find memory safety bugs, panics, and logic errors in a Go project |
| 6 | + using native Go fuzzing (go test -fuzz). |
| 7 | +
|
| 8 | + ### Pipeline |
| 9 | +
|
| 10 | + 1. **Analyze the Go project** to understand its attack surface. |
| 11 | + Use `go_analyze` to scan the codebase and identify: |
| 12 | + - Fuzzable entry points: functions accepting `[]byte`, `string`, |
| 13 | + `io.Reader`, or other parser-like signatures (`Parse*`, `Decode*`, |
| 14 | + `Unmarshal*`, `Read*`, `Open*`) |
| 15 | + - Existing `Fuzz*` test functions already in `*_test.go` files |
| 16 | + - Unsafe/cgo usage that increases the severity of any bugs found |
| 17 | + - Known CVEs via govulncheck (enable with `run_vulncheck: true`) |
| 18 | +
|
| 19 | + If there are **no existing Fuzz targets**, stop here and report |
| 20 | + that the project needs fuzz harnesses written first, listing the |
| 21 | + recommended entry points from the analysis. |
| 22 | +
|
| 23 | + 2. **Test harness quality** before committing to a long fuzzing campaign. |
| 24 | + Use `go_harness_test` to evaluate each Fuzz* function: |
| 25 | + - Compilation check — does `go test -c` succeed? |
| 26 | + - Seed execution — do the seed corpus entries pass without panics? |
| 27 | + - Short fuzzing trial — does the harness sustain fuzzing for 15-30s? |
| 28 | + - Quality score (0-100): ≥80 = production-ready, ≥50 = needs work, <50 = broken |
| 29 | +
|
| 30 | + **Decision point:** |
| 31 | + - If all harnesses are **broken** (score < 50): stop and report issues. |
| 32 | + The user needs to fix them before fuzzing is useful. |
| 33 | + - If some are **production-ready** or **needs-improvement** (score ≥ 50): |
| 34 | + proceed with those targets to step 3. |
| 35 | + - Skip broken harnesses — do not waste fuzzing time on them. |
| 36 | +
|
| 37 | + 3. **Run fuzzing** on the viable targets. |
| 38 | + Use `go_fuzz_run` for a bounded campaign: |
| 39 | + - Set `duration` based on project size: 60-120s for quick scan, |
| 40 | + 300-600s for thorough analysis. |
| 41 | + - Pass only the targets that scored ≥ 50 in step 2 via the `targets` |
| 42 | + parameter — do not fuzz broken harnesses. |
| 43 | + - The fuzzer collects crash inputs to `/app/output/crashes/{FuzzName}/`. |
| 44 | +
|
| 45 | + **Alternative — continuous mode** for deeper exploration: |
| 46 | + - Use `go_fuzz_start` to begin background fuzzing. |
| 47 | + - Periodically check `go_fuzz_status` to monitor progress. |
| 48 | + - Use `go_fuzz_stop` when satisfied or when crashes are found. |
| 49 | +
|
| 50 | + If **no crashes** are found after a reasonable duration, report that |
| 51 | + the fuzzing campaign completed cleanly with the execution metrics. |
| 52 | +
|
| 53 | + 4. **Analyze crashes** found during fuzzing. |
| 54 | + Use `go_crash_analyze` to process the crash inputs: |
| 55 | + - Reproduction: re-run each crash input to confirm it's real |
| 56 | + - Classification: categorize by type (nil-dereference, index-out-of-range, |
| 57 | + slice-bounds, divide-by-zero, stack-overflow, data-race, panic, etc.) |
| 58 | + - Severity assignment: critical / high / medium / low |
| 59 | + - Deduplication: group crashes by signature (target + type + top 3 frames) |
| 60 | +
|
| 61 | + Skip this step if no crashes were found in step 3. |
| 62 | +
|
| 63 | + 5. **Compile the vulnerability report** with findings organized by severity: |
| 64 | + - **CRITICAL**: nil-dereference, segfault, data-race, stack-overflow |
| 65 | + - **HIGH**: index/slice out of bounds, allocation overflow |
| 66 | + - **MEDIUM**: integer overflow, divide by zero, explicit panics |
| 67 | + - **LOW**: timeout, unclassified crashes |
| 68 | +
|
| 69 | + For each unique crash, include: |
| 70 | + - The fuzz target that triggered it |
| 71 | + - The crash type and root cause function + file + line |
| 72 | + - Whether it was reproducible |
| 73 | + - The crash input file path for manual investigation |
| 74 | +
|
| 75 | + ### What the user's project needs |
| 76 | + - A `go.mod` file (any Go module) |
| 77 | + - At least one `*_test.go` file with `func FuzzXxx(f *testing.F)` functions |
| 78 | + - Seed corpus entries added via `f.Add(...)` in the Fuzz functions |
| 79 | +
|
| 80 | + ### Interpretation guide |
| 81 | + - **govulncheck CVEs** (step 1) are known dependency vulnerabilities — report separately |
| 82 | + - **Fuzzer crashes** (steps 3-4) are new bugs found by fuzzing the project's own code |
| 83 | + - High execution counts with zero crashes = good sign (code is robust to that input space) |
| 84 | + - Low quality scores in step 2 usually mean the harness needs better seed corpus or input handling |
| 85 | +
|
| 86 | +servers: |
| 87 | + - go-analyzer-mcp |
| 88 | + - go-harness-tester-mcp |
| 89 | + - go-fuzzer-mcp |
| 90 | + - go-crash-analyzer-mcp |
0 commit comments