Fuzzers are extremely underused. Even in large, mature projects, a fuzzer being part of the source tree is much more an exception than the rule. Once you've don

Fuzzers are extremely underused. Even in large, mature projects, a fuzzer being part of the source tree is much more an exception than the rule. Once you've done it a few times, it takes only 5 minutes to write a basic fuzzer for a function that takes a binary blob or a string as an input, after which you can run it indefinitely. But chances are it will find a bug worthy of a fix within minutes. Various "safe" languages are just as vulnerable to denial-of-service vulnerabilities as C/C++. Since I started fuzzing Go projects I've come across numerous parsers of untrusted data that flat-out crash if a slice is accessed out-of-bounds. Deep recursions (A() calls B() calls A() etc) can crash both Go and Rust. And in probably every general programming language you can implement logic that leads to excessive resource allocation or computation, and unintended infinite loops. These kinds of bugs can obviously be problematic for network-facing components. A royal use of runtime assertions in debug builds for arbitrary invariants/conditions combined with fuzzing usually uncovers many more bugs.