cwe_checker Integration with DefectDojo

cwe_checker Integration with DefectDojo

cwe_checker is an open source binary analysis tool developed by Fraunhofer FKIE. It disassembles compiled executables with Ghidra into a common intermediate representation, then runs checks for common weakness classes such as buffer overflows, use after free, double free, NULL pointer dereference, integer overflow, and externally controlled format strings. Its main focus is ELF binaries for Linux and Unix across architectures including x86, ARM, MIPS, and PPC, which makes it useful for firmware analysis. With --json it writes its warnings as a JSON array that DefectDojo imports.

cwe_checker Integration with DefectDojo

We use cwe_checker on the binaries we ship but don't have full source for, and on firmware images from suppliers, and we import its JSON into DefectDojo so the results are tracked rather than reread. Each warning becomes a Finding on the Asset for that binary, with the CWE set, the check name recorded, and the affected symbols and addresses written into the description in both decimal and hexadecimal. That gives a reverse engineer a list to work through and gives the security lead a count of open memory-safety warnings per product.

Why cwe_checker Matters

Source code scanners stop where the source does. Compiled third-party components, vendor firmware, and legacy binaries still run in production.

• It works on the compiled binary, so it applies to code you received rather than wrote.
• Ghidra-based lifting lets one set of checks run across many CPU architectures, which suits embedded and firmware work.
• Its checks are named after the CWE they look for, so results map directly to a weakness taxonomy.
• It is open source and distributed as a Docker image, which makes it easy to add to a build or analysis pipeline.
• Its output is a flat list of warnings with no record across runs, and no severity, so it needs somewhere to be triaged.

Advantages of This Integration

What we get from running cwe_checker through DefectDojo:

• CWE-based triage. The check name (for example CWE416) becomes the CWE number and the vulnerability ID from the tool, so findings can be filtered and reported by weakness class.
• Addresses ready for a disassembler. cwe_checker reports addresses as decimal strings. The description shows each one in hexadecimal alongside the original, so it can be matched in Ghidra without conversion.
• A clear severity baseline. cwe_checker has no severity, score, or confidence. Every finding imports as Medium, and you raise or lower it per CWE as part of triage instead of trusting an invented ranking.
• A record of review. False positives can be marked, and accepted warnings can be risk-accepted with an expiration date, so a reviewed binary does not need to be reviewed from scratch.
• Shared reporting. Binary findings sit on the same Asset as SCA and SAST results, and follow the same SLA, assignment, and Jira workflow.

How This Integration Works

DefectDojo imports cwe_checker output with the cwe_checker Scan scan type, which expects the JSON array produced by --json.

1. Produce a JSON report. Using the official Docker image:

docker run --rm -v "$(pwd):/work" ghcr.io/fkie-cad/cwe_checker:stable --json --quiet --out /work/cwe-report.json /work/myapp

Use --quiet and --out. Without them, log messages can be written to stdout with the report and make the file invalid JSON.

2. Import it. In the UI, open the Engagement, choose Import Scan Results, select cwe_checker Scan, and upload the file. To automate it, use the import API, available in Community Edition and DefectDojo Pro:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" 
  -H "Authorization: Token $DD_API_TOKEN" 
  -F "scan_type=cwe_checker Scan" 
  -F "file=@cwe-report.json" 
  -F "product_name=router-firmware" 
  -F "engagement_name=Binary 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 "cwe_checker Scan" 
  --report-path "./cwe-report.json" 
  --product-name "router-firmware" 
  --engagement-name "Binary Analysis" 
  --auto-create-context

3. Decide on a reimport strategy. Reimport later reports of the same binary into the same Test with /api/v2/reimport-scan/. Be aware that recompiling shifts addresses, and addresses are part of the description that DefectDojo hashes, so a rebuilt binary can produce new findings for the same underlying issue (see Operational Tips).

Data Granularity: What Gets Imported

Whole-file warnings, such as CWE215 for retained debug symbols, have no addresses or symbols. Those sections are left out of the description rather than shown empty.

Use Cases

Supplier firmware intake: A product security team runs cwe_checker on each firmware image a supplier delivers and imports the results into an Asset per device. Memory-safety warnings become tracked questions for the supplier, and the next delivery's import shows what changed.

Release checks for compiled products: A team that ships C or C++ binaries scans each release build and imports into a Test per release. Reviewers mark false positives once, and the Test records which warnings were reviewed before release.

Prioritizing reverse engineering effort: Filtering by CWE separates double free and use after free warnings from advisory ones like retained debug symbols, so analysts spend their time where defects are most likely.

Reporting on binary risk: Because cwe_checker results share an Asset with SCA and SAST findings, leadership can see open weakness counts for a product without reading separate tool reports.

Operational Tips

• Plan for address churn. Recompiling changes addresses, and the description (which holds the addresses) is part of the legacy dedupe hash, so findings from a rebuilt binary may not match the previous scan. Import each build as its own Test if you need clean per-build history.
• Triage by CWE early. Raise severity for use after free and double free warnings, and consider lowering or risk-accepting CWE215 debug symbol warnings on debug builds.
• Scan the binaries you actually ship. A binary built with -g always triggers CWE215, and stripped binaries report Ghidra-generated function names instead of source names.
• Calls to strcpy, strncpy, and strlen are on the dangerous function list, so a rewrite that still calls them will not scan clean.
• Pin the Docker image to a stable tag in pipelines so check behavior does not change between runs without notice.
• Tag imports with the build or firmware version (for example tags=fw-2.4.1) to compare results across releases.