It's much more common than you may think - especially at larger organizations where engineers go "off-script" frequently.
That being said, we wanted to highlight an example of how fuzzing can be applied to a typical (albeit, toy) API to find logic bugs, and figured SQL Injection would be something that resonated with most (all?) developers.
A lot of folks we talk to think fuzzing is only useful for finding memory leaks in C++ programs, so we wanted to show how adding a single fuzz test to your API can find SQL injection and other logic bugs.
Would love to hear others' experience with Go fuzzing now that it's been out for a few months.
> 2. What measures is Oven taking to proactively detect and mitigate vulnerabilities? (e.g.: fuzzing, audits, bug bounties)
We're huge fans of bun at Fuzzbuzz (waiting for it to get a bit more production-ready). If Jarred's interested, we'd be happy to donate some compute to support fuzzing Bun.
It does! Fuzzing actually started off as a tool built by security researchers to find vulnerabilities in parsers, and other complex codebases, usually written in C/C++ (looking for memory bugs). So anything that deals with untrusted binary data is a prime candidate for fuzz testing.
Go’s fuzzing framework supports `[]byte` arguments as well as all of the standard Go primitives, so you should be able to test netcode this way.
If you're looking for a C/C++ solution, my recommendation is libfuzzer [0]. We've also built our own C/C++ fuzzing engine at Fuzzbuzz [1].
[0]: https://twitter.com/nealagarwal/status/1747284257582506102