Packages, modules and tooling · 3 MIN READ

Test unknown inputs and check reachable vulnerabilities

Combine fuzzing, regression seeds and govulncheck without treating one green tool as complete assurance.

Normal tests often cover the examples you already understand. Parsers and protocol boundaries also receive truncated, oversized and surprising inputs. Fuzzing explores input behavior, while vulnerability analysis asks whether known vulnerable code is reachable; the two tools answer different questions.

Packages and production tooling · A MAP OF THE IDEA

Boundary input
Fuzz property
Regression seed
Dependency finding

Useful when

Combine fuzzing, regression seeds and govulncheck without treating one green tool as complete assurance.

Watch out

A weak property can pass even when the parser is wrong; choose an oracle tied to the contract.

Implementation & operation cost: Fuzzing spends a bounded compute budget; vulnerability findings require a maintained database and a reachable-code interpretation.

Choose a property with a real oracle

A useful fuzz property can check round trips, bounded output, valid parsing or equivalent behavior between implementations. Avoid a property that merely repeats the implementation. Bound input size and work so one accidental huge allocation does not consume the entire test budget.

func FuzzIntegerRoundTrip(f *testing.F) {
    f.Add("12")
    f.Add("-1")
    f.Fuzz(func(t *testing.T, raw string) {
        if len(raw) > 128 { t.Skip() }
        n, err := strconv.Atoi(raw)
        if err != nil { return }
        again, err := strconv.Atoi(strconv.Itoa(n))
        if err != nil || again != n { t.Fatal("integer round trip") }
    })
}

Read the code

The fragment imports testing and strconv and asserts a defined parse/format/parse round trip for accepted integers. Rejected strings are allowed by the parser contract. For your own parser, choose an equally explicit invariant and retain meaningful failures as regression seeds.

Give exploration and regression separate jobs

Run a bounded fuzz campaign in a development environment and commit the small failing seed that explains a fixed bug. Ordinary go test reruns seed corpus inputs without launching an open-ended fuzz search. Vulnerability checks should use a reviewed current database and tool in connected CI.

bash

go test ./internal/parser -fuzz=FuzzIntegerRoundTrip -fuzztime=20s
go test ./...
govulncheck ./...

Read the code

The package path is illustrative and must contain the target. Fuzz time bounds the campaign; source-level vulnerability findings still need interpretation against the built artifact, call path and deployment configuration.

Keep the conclusion proportional to the evidence

A green scan only reports what the analyzer and its current vulnerability database know. It does not inspect every operational configuration or prove the absence of new vulnerabilities. A clean fuzz run means the explored inputs did not violate the asserted properties within that budget.

TAKE THIS WITH YOU

Use a meaningful bounded input property, retain regression seeds and analyze dependency findings in context. No single tool replaces behavior and deployment review.

Check your understanding

What does a passing bounded fuzz run establish?

Go to the source

Progress stays in this browser. No account needed.