feature: Trustless continuous fuzzing platform

[odeke-em]

Preamble

Computer programs involve a series of functionality pooled with different moving parts to execute an algorithm/set-of-instructions that express ideas that execute some business logic of sorts. Written software needs to be robust, secure, deterministic and able to satisfy the initial business goals. To achieve the robustness and other good qualities mentioned, it needs to be effectively tested. Traditional testing involves writing tests that assert against certain expectations for the functionality of the software. The human mind can only conjure up a finite variation of tests that exorcise paths in software to guard against future failures: the permutation of states and combinations of inputs can be infinite and beyond the conjuring of a human mind. Fuzzing is a mechanism by which the power of computers to execute more mundane tasks is combined with human knowledge to mutate inputs and then try to exorcise the program much more, because the more code paths executed and observed, the more secure a program becomes!

Status Quo for Go, Gno and the industry

The Go programming language comes with native fuzzing https://go.dev/doc/security/fuzz/ but you've got to keep running the fuzzer for hours interrupted on a machine and then capture all the inputs that cause unexpected behavior, then restart the fuzzer. To handle that, Go relies on continuous fuzzing by oss-fuzz and you can follow with https://google.github.io/oss-fuzz/getting-started/new-project-guide/go-lang/#native-go-fuzzing-support. oss-fuzz is currently the most popular and free continuous fuzzing platform, run by Google.

Needs for Gno

The Gno ecosystem believes in trust-less, permission-less systems that aren't behind walled gardens or controlled by entities unknown or put behind paywalls in the future. A continuous fuzzing system would require building a couple of mechanisms to:

• Automatically discover fuzz targets in specified projects
• Schedule fuzzing on a pool of available machines
• Allow pooling of resources like machines from either a Cloud platform or physical machines
• Run an enriched fuzzing mechanism that improves coverage discover e.g. coverage guided fuzzing that use genetic algorithms or some Large Language Model (LLM)
• Records test failures and restart fuzz targets
• Alert respective authorities like the security team on failures or fixes
• For continually failing targets, record the history and when a fix was introduced to indicate when the crash was fixed or no longer appears
• Be inspected and save state that can be inspected
• Have an auditable chain of dependencies to ensure that malicious/nefarious interference is detected and reported: good supply chain security
• Provide an image/template that can be ran by anyone who would like to fuzz

[kristovatlas]

@jaekwon any thoughts?