How to manage your code repository to integrate Mayhem

Welcome to Mayhem Tips and Tricks series! Our goal is to help you learn about the best features of Mayhem in small bite-size chunks. Today, we will explain how you can manage your code repository to integrate Mayhem.

So you’ve started fuzzing your code, you’ve got a few targets built out, and you’ve even found a couple of defects in your code - what’s next? How can you make sure that the work you and your team have done is scalable and well-maintained for the lifetime of the project?

Having a well-organized and easy-to-understand repository structure is key to keeping your code clean and ensuring new changes or features are easy to initiate and implement. Say that you have a code repository structure similar to the one below:

/src
/bin
/lib
/test
{Jenkinsfile}
{Config.tf}
{pipeline.yml}
(etc…)
README.md

Haphazardly building and scattering targets around this code base isn’t a sustainable solution - plus, it will look messy and confuse new team members assigned to the project. First, it’s a good idea to create a /fuzz directory - this will keep your fuzzing work organized, as well as indicated to passers-by that this repository uses fuzzing:

/src
/bin
/lib
/test
/fuzz
   - README.md
   - Dockerfile
   - Makefile
   - targets/
      - targetA
         - Mayhemfile
      - targetB
         - Mayhemfile
README.md

Within your /fuzz directory, you should store your fuzzing targets, with labels for each. In this example, each target has its own directory, but choose the hierarchical structure that works best for you, and most closely aligns with your existing code. Look to your /test directory for examples! The two directories should look very similar. Within each target, you should have the source for building your target, as well as your Mayhemfiles - these provide configuration and metadata to tell Mayhem what to fuzz, how to fuzz it, and for how long.

To make building your fuzzing targets easier, you should include some logic to build each target, either in the fuzz directory or in the top level directory of the repository. This can be a Makefile, or build.gradle, or whatever you use as your build tool for your repository - the common adage “The best tool is the one you use” applies here. Furthermore, this hardens the code against breaking changes: as you update your source code, you should build your test and fuzz targets as part of your build pipeline. This way, you can fix any breaking changes as they occur, to ensure that your fuzzing can proceed uninterrupted.

Finally, if you are containerizing your targets (which you should do!), then having a Dockerfile that builds and packages your fuzzing targets into a minimal image that you can upload to Mayhem is a great way to keep your targets up to date.

Don’t forget to document your code! Having a README goes a long way, especially when new developers start working on your code.

That’s it! Following the above methods should keep your code clean, organized and well-suited for fuzzing, both now and in the future.

We hope that you found this Tips and Tricks article helpful.