Platform Overview


The Fuzzbuzz workflow is very similar to other CI/CD testing workflows.

However, unlike other testing workflows, fuzz testing requires multiple jobs to run simultaneously, which results in a few extra steps. Here's a high level overview of what that looks like.

In short:

  1. Push code to your Fuzzbuzz-integrated Git repository or CI/CD.
  2. Code is built and instrumented by Fuzzbuzz as soon as a change is detected
  3. Instrumented application is distributed across the available VMs and fuzz testing begins.
  4. Bugs & fuzzing stats are aggregated and processed.
  5. Data is categorized, deduplicated and saved to the Fuzzbuzz DB.
  6. Notifications are sent if any bugs are detected.
  7. Developer is alerted with bug details, and a reproducible test case.

Feature breakdown

GitHub Integration

Fuzzbuzz integrates with GitHub for source code and git access. Any changes that are made to your repository on GitHub are synced with Fuzzbuzz.

Once connected, GitHub will notify Fuzzbuzz of any updates (ie, new commits or Pull Requests), which will trigger a new job to start on your latest changes.

Continuous Jobs

Continuous jobs are run on your main or master branch. This allows the fuzzer to make meaningful progress in understanding your application's input structure.

Depending on the complexity of the code you're fuzzing, it may take a couple hours or days for the fuzzer to find bugs, which is why we encourage running at least 1 continuous job.

There are only 2 ways a continuous job is stopped:

  • a user manually stops it
  • Fuzzbuzz has determined that the job is unlikely to find any more bugs, and will stop the job until a new commit is merged

Pull Request Jobs

Pull Request Jobs run for a preconfigured amount of time (default 15 minutes) on every Pull Request as a way to check code for regressions and catch low hanging bugs.

A GitHub Check will also appear on the PR being tested. Any detected bugs will block merging until they are fixed.

Bug Viewer

All bugs that have been detected will show up here.

Fuzzbuzz stores a variety of data in order to make it trivial to reproduce and fix bugs. When bugs are found, you are presented with:

  • the stacktrace
  • the file and line it occurred on
  • a reproducible test case
  • the number of times Fuzzbuzz was able to reproduce it

Corpus Viewer

As your fuzz test generates corpus inputs, they will be viewable in Hex or JSON format. You can also download corpus inputs as reproducible tests that you can run in your local developer environment.

Code Coverage Viewer

When fuzzing, it can be difficult to know how effective your test is, where it's getting stuck or if it's doing anything at all.

Fuzzbuzz has a built-in coverage explorer that overlays coverage generated by your corpus directly on top of your source code, so you can dig into your fuzz test's progress.