onefuzz

Learning how to is half the fun! There's a bunch of good tutorials out there on [dumb] fuzzing (presumably where you'll start). One starting point I'd recommend is taking a binary that accepts input from stdin and making some proof-of-concepts with AFL (https://lcamtuf.coredump.cx/afl/). If you'd rather start from a code/library perspective (and not CLI), I'd recommend libfuzzer (https://github.com/Dor1s/libfuzzer-workshop/). There's a lot of other fuzzers, techniques, and depth to the field, but I'd recommend inch worming through (speed up as you gain more comfort). The Fuzzing Book is good to help you understand the logic behind techniques and strategies (https://www.fuzzingbook.org/) As for some management, there's a few decent "monitoring" systems out there; personally I just SSH in and check the fuzzer manually (I leave it running in

Microsoft’s OneFuzz is tackling some of these issues https://github.com/microsoft/onefuzz The biggest problem with fuzzing when it comes to “developer friendliness” isn’t just how to setup the fuzzer and the fact that you need to often write quite a bit of additional code to support fuzzing but that the results aren’t easily consumable. Getting a fuzzer to cause a crash or some unhandled exception isn’t particularly difficult understanding the actual implication of such crash is where these tools “fail”. SAST / DAST tools with all their issues such as false positives and relatively limited coverage at least provide actionable results. Fuzzing not only requires a much higher understanding of the code itself and of its execution to get it working in the first place but the results are often useless for many if not most developers. Basically

https://github.com/microsoft/onefuzz "Our source code will drop in sync with our public presentation at CppCon 2020 on September 18th, 2020."