The right approach to start fuzzing with AFL, to me, is to recycle existing unit tests or integration tests. In fact if you already have tests that create a rec

The right approach to start fuzzing with AFL, to me, is to recycle existing unit tests or integration tests. In fact if you already have tests that create a record (sorry, struct or class instance), inject them in your part of your application, you're almost. Read your input data from a file and 'there' you go... Paralellizing or distributing an AFL session on dozens of machines is a matter of rsyncing some files. Sanitizers are also very useful there in C/C++ languages because they're mostly runtime checks. In Ada you had them already for a long time, and you can be very through with your checks (see for example validity checks https://gcc.gnu.org/onlinedocs/gnat_ugn/Validity-Checking.html https://gcc.gnu.org/onlinedocs/gnat_ugn/Validity-Checking.ht... , runtime stack size checks https://gcc.gnu.org/onlinedocs/gnat_ugn/Stack-Overflow-Checking.html#f4 https://gcc.gnu.org/onlinedocs/gnat_ugn/Stack-Overflow-Check... , and the very very powerful Initialize_Scalars that has saved me many times https://www.adacore.com/papers/exposing-uninitialized-variables-strengthening-and-extending-run-time-check https://www.adacore.com/papers/exposing-uninitialized-variab... ). Shameless plug, but if anyone is interested in an introduction to fuzzing (in Ada) I wrote something some time ago that could be useful : https://blog.adacore.com/running-american-fuzzy-lop-on-your-ada-code https://blog.adacore.com/running-american-fuzzy-lop-on-your-... . Fuzzing is fun !