We offer a cutting-edge combination of fuzzing engines with static code analysis, symbolic and concolic execution to create the most usable and powerful dynamic application testing tool out there. The resulting feedback-based fuzzing framework seamlessly integrates into development processes and helps catch vulnerabilities before they are shipped.
Feedback-based fuzzing is a modern fuzzing technique used for security and stability testing of the codebase. The software under test is fed with a series of inputs, which are purposefully mutated in the testing process. The testing tool gets feedback about the code covered during the execution of inputs. Unlike traditional or black-box fuzzing, feedback-based fuzzing explores the program state efficiently and discovers bugs hidden deeply in the code.
CI Fuzz utilizes several state-of-the-art fuzzing engines: libFuzzer with Sanitizers, AFL++, and honggfuzz, as well as other modern bug detection techniques, such as concolic execution. Additionally to the instrumentation, we use static code analysis to learn the used data types. This allows us to provide enhanced fuzzing guidance, e.g. by producing inputs with expected structures.
The configuration is done via an IDE plugin guiding the user through setting up the fuzzer. The user can interactively see which parts of the code were already covered by our software, supply additional input grammars for fuzzing structured data and browse the issues found by the fuzz tests in the debugging mode.
CI Fuzz easily integrates into a standard CI/CD workflow such as Jenkins. The fuzz tests are run automatically with each new code change and incidents are reported promptly. Fuzzing tests can be scaled on-demand on a Kubernetes cluster.
Unit and integration tests are essential parts of the software development process. However, they have several limitations:
This all may become extremely difficult if you consider the time pressure and changing requirements that are common in most software development projects.
Fuzzing as an alternative testing technique originated in the 1980s. The basic idea behind fuzzing is simple: provide random input to the program and report any crash. If the software does not crash, repeat with a new random input, possibly derived from the last one. A fuzzer that does the input generation part really well is radamsa.
In 2016, american fuzzy lop (AFL) improved fuzzing by considering the coverage, i.e. the share of traversed code paths in the generation of new inputs. AFL and other coverage-based fuzzers could discover far more paths of a program than “dumb” fuzzers.
The next major improvement in the world of fuzzing came in the form of Sanitizers that detect more types of errors than just crashes. The AddressSanitizer, for example, monitors memory access akin to valgrind (but a lot faster), while the ThreadSanitizer watches for race conditions between multiple threads. Using Sanitizers for fuzzing was made even more practical with the advent of libFuzzer, a fuzzing engine baked into LLVM, due to smart handing of the large virtual memory requirements of the AddressSanitizer.
In short, the combination of coverage information with sanitizers is what we call modern fuzzing.
Our testing suite simplifies the setup and enables any company to benefit from these modern, sophisticated fuzzing technologies.
Get a live demo of how feedback-based fuzzing works
