BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News ClusterFuzzLite Brings ClusterFuzz to GitHub Actions and Other CI/CD Pipelines

ClusterFuzzLite Brings ClusterFuzz to GitHub Actions and Other CI/CD Pipelines

This item in japanese

ClusterFuzzLite, as implied by its name, is a light version of Google ClusterFuzz, a tool aimed to find security and stability issues in software systems through fuzz testing. ClusterFuzzLite is meant to be integrated in a CI pipeline with a few lines of code, says Google.

ClusterFuzz provides an automated end-to-end infrastructure for finding and triaging crashes, minimizing reproducers, bisecting, and verifying fixes.

ClusterFuzz is highly scalable and can run on clusters of any size. Google has been using ClusterFuzz since 2016 on up to 30,000 VMs, identifying over 25,000 bugs in Google software and other OSS-Fuzz based projects.

While extremely powerful, ClusterFuzz is tied to some Google Cloud Platform services when used in production and its setup requires quite some effort. It has two main components, an App Engine instance and a pool of fuzzing bots, which are machines responsible for running scheduled tasks, such as a fuzzing session or minimizing a test case.

ClusterFuzzLite takes instead a simplified approach to make it easier to integrate it with a build system and a CI pipeline. Once configured, ClusterFuzzLite supports two modes of fuzzing: code-change fuzzing and batch fuzzing.

Code-change fuzzing focuses on pull requests or commits and allows ClusterFuzzLite to find bugs before they make it into your baseline. Code-change fuzzing is meant to be quick, so it runs by default for 10 minutes and quits at the first crash. On the contrary, batch fuzzing is meant to be more exhaustive and runs for a preset, longer, amount of time, without exiting on the first discovered bug. Batch fuzzing is more appropriately run on a fixed scheduled rather than for each commit/PR, which will allow it to build a corpus of test inputs over time.

Batch fuzzing will end up introducing redundant testcases. To deal with this, ClusterFuzzLite supports a mode called corpus pruning, which will remove testcases (corpus files) that do not increase code coverage. Goggle suggests running corpus pruning once a day if using batch fuzzing. Additionally, ClusterFuzzLite also supports fuzzing in continuous build mode.

ClusterFuzzLite supports fuzzing through libFuzzer, an AddressSanitizer to find memory safety issues, a MemorySanitizer to find uninitialized memory, and an UndefinedBehaviorSanitizer to find undefined behavior.

Most interestingly, ClusterFuzzLite comes ready to run on GitHub Actions out of the box. You only need to provide a configuration file for each of the modes you want to run, for example, a .github/workflows/cflite_pr.yml file for PR fuzzing, or .github/workflows/cflite_batch.yml for batch fuzzing. Google provides default configuration files that will suit the most common scenarios, like fuzzing all PRs sent to a repo, or scheduled buzz fuzzing on the latest HEAD, and so on.

Similarly, ClusterFuzzLite can be just as easily integrated with Google Cloud Build and Prow, a kubernetes-based CI/CD system.

Rate this Article

Adoption
Style

BT