Go software can exhibit a variety of denial-of-service bugs such as slice out-of-bounds access (since there is no try/catch mechanism, this leads to a panic), excessive allocations, excessive computation/timeout (consider "for i := 0; i < N; i++" where N is untrusted), stack overflow due to unbounded recursion (rare because Go has a custom, large stack).

My bignum-fuzzer project [1] runs on oss-fuzz and tries to find mismatches between bignum computations across different libraries (OpenSSL, Go, Rust, etc). This is one example of how fuzzing can be useful even if the underlying language is "safe".

With some small hacks you can also have Go code coverage instrumentation as a libFuzzer counter.

[1] https://github.com/guidovranken/bignum-fuzzer/blob/master/mo...

And Go isn't memory safe given race conditions.

If you're using goroutines you may want to consider fuzzing with the race detector.

That's a nice explanation, thank you. I'll take a look at implementing it in some small piece of software :)

There are tools for fuzzing go: https://github.com/dvyukov/go-fuzz

But I think the kinds of bugs found by fuzzing aren't generally security issues in go (I don't know much about go) as they are in C/C++.

EDIT: See guidovranken's excellent sibling comment for how fuzzing can still be useful for go.

Awesome, I will check that out. Thank you!