/fuzzing-harness

name: fuzzing-harness
description: "Write and run a fuzzer, fuzz harnesses and property-based tests for the code that handles untrusted bytes (file and packet parsers in C, C++, Rust, Go, Python or JS, decoders, serializers, deserializers, token and header parsing, protocol state machines), then minimize, dedupe and triage the crashes into verified findings with regression tests. Covers libFuzzer, cargo-fuzz, Go native fuzzing, Atheris, Jazzer.js and Jazzer, Hypothesis, fast-check and proptest, seed corpora and dictionaries, sanitizer builds, and CI fuzzing with ClusterFuzzLite or OSS-Fuzz. Use when the user mentions 'fuzzing,' 'fuzz harness,' 'fuzz target,' 'libFuzzer,' 'cargo fuzz,' 'go test -fuzz,' 'Atheris,' 'Jazzer,' 'property-based testing,' 'Hypothesis property test,' 'fast-check,' 'proptest,' 'seed corpus,' 'fuzzing dictionary,' 'AddressSanitizer report,' 'fuzzer crash files,' 'minimize a crash input,' 'ClusterFuzzLite,' 'OSS-Fuzz,' or wants to fuzz their parser."
allowed-tools: Read, Grep, Glob, Write, WebSearch

Fuzzing Harness — Fuzz Targets, Property Tests and Crash Triage

Find the functions that turn untrusted bytes into structure, write a harness or property test for each one, run them with sanitizers on the user's say-so, and turn what falls out into deduplicated, verified findings that each come with a regression test. The main output is code in the user's repo: harnesses, property tests, seed corpora, dictionaries, CI jobs. That is why this skill pre-approves `Write`. Building and running them is not pre-approved: it executes the user's code and toolchain, so it always asks.

Cross-references: `owasp-audit` (source review that points at the parsers worth fuzzing, and takes over when a crash turns out to be an injection or access-control bug), `web-pentest` (fuzzing a live HTTP app with Burp or ZAP; this skill never sends traffic to a running service), `mobile-audit` (Android intent and IPC testing on a device), `crypto-audit` (crypto implementations, where test vectors beat random input), `threat-modeling` (which inputs cross a trust boundary, used to rank targets), `vuln-research` and `dependency-audit` (a crash inside a third-party library), `scanner-pipeline` (the rest of the CI security jobs), `finding-triage` (dispositions after the report). For a manual memory-safety review of C, C++ or Rust code around a crash, hand off to `native-code-review`.

When to use

• "Write a fuzzer for our packet parser / image decoder / config loader"
• "Add property tests to this serializer" or "is `decode(encode(x)) == x` actually true?"
• "Our fuzzer found 40 crashes, which ones matter?"
• "Set up fuzzing in CI" or "can we get into OSS-Fuzz?"
• A source review flagged a hand-rolled parser and the user wants it exercised instead of read
• Input: a repo (or one package in it) the user owns, and permission to build and run code locally

**Not for:** sending payloads to a running web app or API (`web-pentest`, or `api-audit` for the code review); Android intent fuzzing on a device (`mobile-audit`); a line-by-line OWASP review with no harness (`owasp-audit`); "is this CVE in our fuzzing library relevant?" (`vuln-research`); triaging a SAST or scanner alert (`finding-triage`); load or performance testing (not a security skill).

Authorization

• Only code the user owns or is authorized to test. A third-party library they depend on is fine to fuzz locally

through their own build; report what you find to that project through its security policy, not in a public issue.

• **Pre-approved:** reading the code, ranking targets, and writing harness, test, corpus, dictionary and CI files.

Say which files you're adding and where before you write them. Put them in test locations (`fuzz/`, `tests/`, `*_test.go`, `testdata/`), never in production source.

• **Always asks first:** installing a toolchain or fuzzing package, compiling with sanitizers, running a fuzzer or a

property test suite, and editing build files (`Cargo.toml`, `CMakeLists.txt`, `package.json`, `go.mod`). Each of those runs or changes the user's code. Get a yes, with the time budget, per session.

• **Keep runs local and contained.** A harness must not reach the network, a real database, a payment or email

provider, or files outside a temp directory. Stub those seams. Prefer a container or VM with no network and memory and CPU limits for native targets.

• **Stop at triage.** Classify the crash and decide whether it is security-relevant. Don't build a working exploit

from a crash, and don't run harnesses or crash inputs against systems the user doesn't control.

Workflow

Inventory → rank targets → write harnesses and property tests → seeds and dictionaries → run (after a yes) → minimize, dedupe, triage → verify and record → regression tests and CI.

Step 1 — Inventory

Don't write a second harness for a target that already has one. Search for existing harnesses, property tests and CI fuzzing:

rg -n -e 'LLVMFuzzerTestOneInput' -e 'fuzz_target!' -e 'func Fuzz[A-Z]\w*\(f \*testing\.F\)' \
   -e 'atheris\.(Setup|Fuzz)' -e '@jazzer\.js|it\.fuzz\(' -e '@FuzzTest' \
   -e '@given\(' -e 'fc\.(assert|property)\(' -e 'proptest!' .
ls -d fuzz .clusterfuzzlite testdata/fuzz proptest-regressions .hypothesis 2>/dev/null
# portable fallback
grep -rnE 'LLVMFuzzerTestOneInput|fuzz_target!|func Fuzz[A-Z][A-Za-z0-9_]*\(f \*testing\.F\)|atheris\.Setup|@FuzzTest|@given\(|fc\.assert\(|proptest!' . \
  --exclude-dir=node_modules --exclude-dir=.git --exclude-dir=vendor --exclude-dir=target

Check whether the project is already on OSS-Fuzz (search `google/oss-fuzz` for `projects/<name>/`). If it is, new harnesses go upstream there, and crashes may already be filed.

Step 2 — Pick and rank targets

Good targets take bytes or strings from outside the trust boundary and build structure from them:

| Target shape | Why it pays | Look for | |---|---|---| | Binary format parsers and decoders (images, archives,