Fuzzers, analyzers, and other Gophers insecticides

The talk makes the case that Go's easy concurrency model and simple syntax can hide real bugs, and that Go code still shares many weaknesses seen in C and C++. Drawing on security audits of Go projects, the speaker walks through recurring patterns: unchecked or overwritten errors, typed nil interface values that never equal nil, integer truncation on string conversions, slices sharing one backing array, and loop variables captured by goroutines.

Concurrency bugs get their own section: data races, goroutine leaks from blocked channel sends that pile up memory, and missing unlocks on early-return paths that leave an endpoint hanging. For detection, dynamic tools include fuzzing, the race detector, deadlock checks and fault injection, though the race detector misses many concurrency bugs. Static analyzers split into AST-based linters such as gosec and staticcheck, which are quick but noisy, and SSA-based tools such as gcatch, which trace behavior across functions.

A key gap is that most tools ignore third-party libraries, so misuse of web frameworks and ORMs often goes unflagged. The takeaways: combine fuzzing with dynamic checks, run linters for common misuse, use SSA tools for cross-function concurrency bugs, and write custom rules for the libraries a project relies on. A preview of Gotico, an in-development tool for library-specific checks, closes the talk.