CI Fuzz Integration with DefectDojo
CI Fuzz Integration with DefectDojo
CI Fuzz is a fuzz testing tool from Code Intelligence. Developers write fuzz tests for their code, and CI Fuzz runs them, feeding generated inputs to the code while it executes to find bugs and vulnerabilities. Its documentation lists support for C and C++ (CMake, Bazel, and other build systems such as Make), Java (Maven and Gradle), and JavaScript or TypeScript on Node.js. Each finding points to the line of code involved and includes the input that triggered it. DefectDojo Pro reads CI Fuzz findings through an Upstream Connector that calls the Code Intelligence platform.
CI Fuzz Integration with DefectDojo
We added CI Fuzz to our pipeline for the parsers and protocol handlers that static analysis kept giving us mixed signals on, and we connected it to DefectDojo so its results would not live only in the fuzzing platform. The DefectDojo Pro connector creates a Record for each CI Fuzz project and syncs that project's findings into the Asset it maps to. A crash found overnight becomes a Finding with a severity, an owner, and an SLA, right next to the SAST and SCA results for the same code.
Why CI Fuzz Matters
Fuzzing finds a different class of problem from pattern-based scanning, because it exercises real code paths with inputs nobody thought to write tests for.
- It analyzes code while it runs, so each reported issue corresponds to behavior that actually happened during a test.
- Findings come with the input that triggered them, which gives developers a reproducer instead of a hypothesis.
- It targets the code that handles untrusted input, such as parsers, decoders, and request handlers, where memory safety and logic bugs tend to hide.
- Fuzzing runs continuously or on a schedule and keeps producing results, which is exactly the kind of output that needs tracking over time.
Advantages of This Integration
What the CI Fuzz connector adds to DefectDojo Pro:
- Fuzzing results as tracked work. Each CI Fuzz finding becomes a DefectDojo Finding that can be assigned, commented on, risk-accepted, or pushed to Jira or another Downstream Connector.
- One Record per project. Discover finds each CI Fuzz project, and Auto-Map can create a matching Asset, or you can map the project to the Asset that already holds that codebase's other findings.
- Lifecycle across runs. Each Sync runs a reimport against the existing Test, so new findings are added and findings that are no longer reported are marked inactive.
- Consistent SLAs. Fuzzing findings fall under the same severity-based SLA rules as every other tool feeding the Asset.
- Severity control. A Minimum Severity setting lets you keep lower-severity results out of DefectDojo.
- Visibility beyond the fuzzing team. Security leads see fuzzing results in the same metrics and reports as everything else, without a separate login.
How This Integration Works
The CI Fuzz connector is a DefectDojo Pro feature, configured under Connect > Upstream.
1. Get an API token. Create a CI Fuzz API token in the Code Intelligence platform. DefectDojo sends it as a bearer token and never logs it.
2. Configure the connector. Enter https://app.code-intelligence.com in the Location field and the token in the API Token field. Optionally set a Minimum Severity to limit which findings are imported.
3. Discover. DefectDojo creates a Record for each CI Fuzz project the token can see. If the connector reports that it is connected but nothing is visible, the token's account is most likely missing access to projects in CI Fuzz.
4. Map and Sync. Map each Record to an Asset, or enable Auto-Map to have DefectDojo create an Asset per project. Sync then imports that project's fuzzing findings into a Test inside the Global Connectors Engagement on the mapped Asset, and repeats on a schedule. You can also run Discover and Sync manually from the connector's Manage Records & Operations page.
Data Granularity: What Gets Imported
The connector documentation describes the import at the project level. This table summarizes what it states and how connector data is stored in DefectDojo.
| DefectDojo Object | Source in CI Fuzz | Notes |
|---|---|---|
| Record | CI Fuzz project | One Record per project |
| Asset | Mapped from the Record | Manual mapping or Auto-Map |
| Findings | The project's fuzzing findings | Carried on the project's Record |
| Engagement | Global Connectors | Created under the mapped Asset |
| Test | One per connector on the Asset | Updated by each Sync |
| Severity filter | Minimum Severity setting | Findings below it are not imported |
| Lifecycle | Each Sync | New findings added; findings no longer reported marked inactive |
If a value lands in the wrong DefectDojo field for your workflow, Connector Field Mappings let you rearrange, combine, or normalize what the connector sends for its scan type.
Use Cases
Fuzzing in CI: A team runs CI Fuzz on every merge to main for its C++ networking library. The connector syncs findings into the library's Asset, so new crashes show up as new Findings with an SLA, and fixed ones drop to inactive on a later sync.
Combining fuzzing with static results: Mapping the CI Fuzz project to the same Asset that receives SAST results means a reviewer can compare static warnings and fuzzing findings for the same code in one place, which helps judge which static findings are reachable in practice.
Routing to developers: Findings above a chosen severity are pushed to Jira or another Downstream Connector for the owning team. Developers can follow the finding back to CI Fuzz for the triggering input and code location they need to reproduce it.
Reporting on testing coverage: Security leads can show which codebases have fuzzing in place by looking at which Assets have a CI Fuzz Test in their Global Connectors Engagement.
Operational Tips
- Map each CI Fuzz project to the Asset that already holds the same codebase's findings, rather than letting Auto-Map create a separate Asset, if you want fuzzing and static results side by side.
- Use a dedicated token for the connector so it can be rotated without affecting developers' own access.
- Turn on the Connector Health Warning notification so an expired token shows up as a message instead of as a quiet gap in findings.
- Set Minimum Severity conservatively at first. It is easier to lower the threshold later than to clean up a flood of low-severity results.
- Remember that a finding marked inactive after a Sync means CI Fuzz no longer reports it. Pair that with a fix in your tracker before treating it as resolved for audit purposes.
- Tag the mapped Asset with the language or component so fuzzing findings can be filtered alongside other results in metrics.