The last time I tried to compile an executable using all the afl fuzzer magic-compile-time stuff, I gave up, so I have the impression that CPU time isn't the bottleneck here.

It took me a day to understand the tooling required to get AFL working. Now I can spin up a new test case for a library within a couple hours. Once you have the test case, then it is CPU bound. I had on one series of tests, of the baresip sip library libre, running across 4 machines(24 cores each) for a day before it was 100% sure it had tested every code path looking for a SIP protocol decoding error through fuzzing.

How did you split up the work across the machines?

AFL has documentation on how to setup that up. eg:

  https://github.com/mcarpenter/afl/blob/master/docs/parallel_fuzzing.txt

This is part of my problem. The other part is that I just don't know where to look. I'd much rather have some board choose submitted areas of open source projects, have the submitter/community create a harness, and then run something like Folding@home in a Docker container.

Computing power isn't the bottleneck of fuzzing. It's being smart about choosing your targets, tools and seeds.

My rule of thumb: It's very rare that I see any results beyond running a fuzzing job on an average machine for a day.