Fuzz testing is a dynamic technique that bombards a target application with crafted input to force the execution of unanticipated paths, leading to potentially exploitable crashes. Recently, new, groundbreaking “smart” fuzzers such as AFL and libFuzzer have proven very effective and have found many security vulnerabilities (such as buffer overflows and use-after-frees) in C and C++ applications.
Fuzz testing has traditionally been done by outside security consultants as part of a occasional “point-in-time” security audit or pentest. The problem with this is that the vulnerable software may have already been released to customers — or more code has been developed which depends on the buggy part of the application.
Software companies and development organizations are beginning to add a fuzz run as a routine part of the build and test (or continuous integration) cycle to find memory corruption bugs as early as possible and prior to release of the code. These companies save significant amounts of money by finding bugs early when they are much cheaper to fix.
Continuous Fuzzing is constantly having a fuzz test running and only restarting it periodically or when code is modified or new code is added. Depending on how often code is changed, this might mean restarting the fuzz run:
- On every push to a source code control server.
- Or, if this is too frequent, restarting the run every 24 hours targeting the latest build.
At Fuzz Stati0n, we use the term Continuous Fuzzing to describe how our cloud based fuzzing infrastructure is leveraged by our customers.
For information on Fuzz Stati0n’s scalable, cloud based continuous fuzz testing solution (and our new training offering), please see our website.
