Codechecker Integration with DefectDojo

Codechecker Integration with DefectDojo

CodeChecker is an open source static analysis toolchain developed by Ericsson and released under the Apache 2.0 license. It intercepts a project's build to record compilation commands, then runs analyzers such as the Clang Static Analyzer, Clang-Tidy, Cppcheck, the GCC Static Analyzer, and Facebook Infer against that compilation database, with C and C++ as its core use case. CodeChecker also has its own results server and viewer, and its parse command can export results as JSON, which is the format DefectDojo imports.

Codechecker Integration with DefectDojo

We use CodeChecker because it gives our C and C++ teams one way to run several analyzers off the same build, and DefectDojo is where those results meet everything else we track. Importing CodeChecker JSON into DefectDojo puts each reported bug on the Asset that owns the code, keeps review decisions made in CodeChecker, and measures fixes against the same SLAs as our dependency and container findings. When a nightly build reruns analysis, a reimport tells us what closed and what is new without anyone comparing two plist directories.

Why Codechecker Matters

Memory safety bugs, undefined behavior, and API misuse in native code tend to be expensive once they ship. Compilers catch some of it. Dedicated analyzers catch much more.

• It drives multiple analyzers from one build log, so teams don't maintain separate wrappers for Clang-Tidy and the Clang Static Analyzer.
• Results carry the analyzer, checker name, file, line, and column, which is enough for a developer to go straight to the code.
• Reviewers can mark reports as confirmed, false positive, intentional, or suppressed inside CodeChecker, and those decisions travel in the JSON export.
• On its own, a CodeChecker export is a list for one build. It doesn't connect C++ defects to the rest of an application's risk or give security leads a view across repositories.

Advantages of This Integration

What running CodeChecker through DefectDojo gave us:

• Review status carries over. A report marked confirmed arrives verified, intentional arrives risk-accepted, and false_positive or suppressed arrive as false positives. Triage done in CodeChecker isn't repeated.
• Deduplication on a tool-derived ID. DefectDojo deduplicates Codechecker findings with the unique ID algorithm, using an ID the parser builds from CodeChecker's report hash and the finding details.
• A lifecycle for native code defects. Reimporting into the same Test mitigates reports that disappeared after a fix and adds new ones, so each build's delta is visible.
• Filtering by analyzer. Every finding is tagged with its analyzer name (for example clang-tidy or clangsa), so teams can split metrics or SLAs by tool.
• One view of the application. Static analysis results for the C++ core sit next to SCA, container, and DAST findings for the same Asset, and can be assigned or pushed to Jira like anything else.

How This Integration Works

DefectDojo imports CodeChecker results with the Codechecker Report native scan type, which reads the JSON produced by CodeChecker parse.

1. Log the build, analyze, and export JSON. CodeChecker first records how your project compiles, then analyzes it, then converts the results to JSON:

CodeChecker log -b "make -j8" -o ./compile_commands.json
CodeChecker analyze ./compile_commands.json -o ./cc-results
CodeChecker parse ./cc-results -e json -o ./codechecker-report.json

The parser reads the top-level reports list. Each entry needs analyzer_name, category, checker_name, file, report_hash, and analyzer_result_file_path, all of which CodeChecker's native JSON export includes.

2. Import the report. In the UI, open the Engagement, choose Import Scan Results, select Codechecker Report native, and upload the file. To automate it, use the API in Community Edition or DefectDojo Pro:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" \
  -H "Authorization: Token $DD_API_TOKEN" \
  -F "scan_type=Codechecker Report native" \
  -F "file=@codechecker-report.json" \
  -F "product_name=firmware-core" \
  -F "engagement_name=Nightly Analysis" \
  -F "auto_create_context=true"

DefectDojo Pro users can run the same import with Universal Importer:

universal-importer import \
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" \
  --scan-type "Codechecker Report native" \
  --report-path "./codechecker-report.json" \
  --product-name "firmware-core" \
  --engagement-name "Nightly Analysis" \
  --auto-create-context

3. Reimport on every analysis run. Send later exports to /api/v2/reimport-scan/ for the same Test so fixed reports are mitigated and their history stays in one place.

Data Granularity: What Gets Imported

Within one report, entries that produce the same unique ID are imported once.

Use Cases

In a nightly C++ build: The build job logs compilation, runs CodeChecker, and reimports the JSON into a Test per repository. Developers start the day with a short list of new reports instead of the full backlog.

When adopting new checkers: A team enables an extra Clang-Tidy check group and the first run produces hundreds of style-level reports. Because STYLE maps to Info, setting minimum_severity=Low on import keeps them out of the security queue until someone decides they matter.

For embedded and firmware teams: Products built from large native codebases often have little SCA or DAST coverage. CodeChecker findings in DefectDojo give those Assets real metrics and SLA tracking alongside the rest of the portfolio.

During code review sign-off: Reviewers mark CodeChecker reports as intentional or false positive in the CodeChecker viewer, re-export, and reimport. DefectDojo reflects those decisions as risk acceptances and false positives, so audit reports show who triaged what.

Operational Tips

• Keep the analyzer output directory path stable between runs. The unique ID includes analyzer_result_file_path, so moving results to a different directory produces new IDs and new findings.
• Expect a finding to be treated as new when code above it shifts. The line and column are part of the description, which feeds the unique ID, so a reformatting commit can mitigate and recreate reports.
• Do review triage in CodeChecker and re-export rather than editing the same finding in both tools. The JSON review status is what DefectDojo reads on each import.
• Use the analyzer tags to set expectations. Clang Static Analyzer path-sensitive reports and Clang-Tidy style checks rarely deserve the same SLA.
• Set minimum_severity on import if STYLE and UNSPECIFIED reports, which arrive as Info, would bury actionable results.
• Tag imports with the branch or release (for example tags=main,release-4.2) so trends can be filtered by code line.