Integrating CI Fuzz into your CI/CD process
Architecture of CI Integration
When running a pipeline, your CI/CD platform triggers fuzzing on the CI Fuzz server. The fuzzing server checks out the source code, instruments it, builds and starts the configured fuzz tests. This begins with a regression test by checking previously generated inputs and crashes found in previous runs. When vulnerabilities or bugs are found, the pipeline is marked as failed and the detailed bug reports can be viewed and debugged in the dashboard. You can login to the dashboard using your single sign on from your Gitlab, Bitbucket or Github account. The CI Fuzz server can be either in cloud or deployed on-premise.
Example with Jenkins and Bitbucket:
How to generate the config script for your CI/CD server
To enable continuous fuzzing of your projects, use the CI configuration wizard in the UI which is accessible from the dashboard.
In the wizard you select the type of continuous integration you are using, the test collection that you want to fuzz continuously and whether you want to be notified on additional channels if bugs are found in the continuous integration. Then generate the CI/CD script.
Next, create an Access Token for your CI/CD platform by clicking on your picture in the upper right corner and the Generate button.
Your CI/CD platform will need read and execute scopes.
Next, store this token into your CI/CD platform. Example with GitHub Actions:
Example with GitLab CI/CD:
The "Key" field should be the same as "Token name" in CI Fuzz.
Trigger the pipeline (for example by creating a pull/merge request) to start fuzzing. If the fuzzer finds bugs, the pipeline will fail and you will see a link to findings in your CI/CD platform.
Example finding from a failing pipeline in Github Actions
Code Intelligence recommends running fuzz tests for 5 minutes (the TIMEOUT variable in your CI/CD script set to 300) every time new code is pushed to a branch, or every time a pull/merge request is created. Five minutes is usually enough to find regressions and easily discoverable bugs. This is possible, because CI Fuzz remembers bugs and code coverage information from previous runs.
Additionally, Code Intelligence recommends setting up fuzzing for a few hours every night. Given enough time, CI Fuzz will discover new inputs that cause the program under test to behave differently, and possibly find new bugs. Even if it does not discover new bugs or gain new code coverage during one such run, there is still a high chance it will find something next time, as inputs are generated randomly and are different every time.
To set up nightly fuzzing, set up a nightly build in your CI/CD, using a script generated as described above, and set the TIMEOUT variable accordingly.
CI Fuzz On-Prem special steps
You may need to change some URLs in the generated script to reflect the URLs of your On-Prem CI services.
Also, you will need to tell the "cictl" tool, which will be running on your CI/CD platform, to trust your On-Prem CI Fuzz API's server certificate, or the CA that signed it. Store the certificate so that it's accessible in the CI/CD script.
Example with GitLab CI/CD (the type "File" stores a path to the file in an environment variable):
Then add the following commands at the beginning of your CI/CD script:
head $CIFUZZ_CA_OR_SERVER_CERT #to see if it is reachable
cp $CIFUZZ_CA_OR_SERVER_CERT /usr/local/share/ca-certificates/ci/on-prem-ci.crt
Trigger the CI/CD pipeline and see if fuzzing starts. If there are any issues, please contact our support.