Binwalk Integration with DefectDojo

Binwalk Integration with DefectDojo

Binwalk is an open source firmware analysis tool maintained in the ReFirmLabs GitHub organization, with the current release (Binwalk v3) rewritten in Rust. It scans firmware images and other binaries for known file signatures, reporting where embedded filesystems, compressed archives, executables, cryptographic constants, and copyright or license text sit inside the blob. It can also extract what it finds, and it writes its analysis results to a JSON log file that DefectDojo imports.

Binwalk Integration with DefectDojo

Our product team ships firmware for a handful of device lines, and Binwalk is how we answer the first question anyone asks about a new image: what is actually inside it? Running Binwalk results through DefectDojo turns that answer into a record we can keep. Each signature match becomes an informational Finding on the Asset for that device, so we can compare one firmware release to the next, attach notes from the engineer who reviewed it, and hand the inventory to whoever runs the vulnerability tooling that judges the contents.

Why Binwalk Matters

Firmware is usually delivered as a single opaque file, and a vendor SBOM, if one exists, rarely tells you everything that was packed into it.

• Binwalk shows the structure of an image: a bootloader here, a SquashFS root filesystem there, a gzip-compressed kernel after that.
• Cryptographic constants such as AES tables show you where encryption code lives, which is a starting point for reviewing how keys are handled.
• Copyright and license strings expose third-party components that a supplier may not have disclosed.
• It works on images you did not build, which makes it a standard first step in supplier reviews and device assessments.

What Binwalk does not do is decide whether anything it found is vulnerable. It reports matches with a confidence value, not a severity, and the DefectDojo parser respects that.

Advantages of This Integration

• Firmware inventory kept per Asset. Every image you scan lands under the Asset for that product, with the Engagement and Test recording which release it came from.
• Release-to-release comparison. Reimporting a new build's report into the same Test mitigates signatures that disappeared and adds new ones, so a component quietly added to a firmware update shows up as a new Finding.
• Deduplication on title and file path. DefectDojo hashes Binwalk findings on title and file_path, so scanning the same image twice doesn't double the inventory.
• Review notes and ownership. Analysts can add notes, tags, and assignments to individual matches, which keeps reverse-engineering observations next to the evidence instead of in a separate document.
• Context next to real vulnerabilities. Binwalk inventory sits on the same Asset as findings from the SCA or binary analysis tools you use to judge the extracted contents, which helps a reviewer connect "this image contains a filesystem" to "that filesystem contains a vulnerable package."

How This Integration Works

DefectDojo imports Binwalk results with the Binwalk Scan scan type, which reads the JSON log Binwalk writes.

1. Analyze the image and write a JSON log.

binwalk -l binwalk.json firmware.bin

The log is a JSON array. Each entry carries an Analysis object with the scanned file_path and a file_map list of signature matches, and each match becomes one Finding.

2. Import the report. In the UI, open the Engagement for the firmware release, choose Import Scan Results, select Binwalk Scan, and upload binwalk.json. 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=Binwalk Scan" 
  -F "file=@binwalk.json" 
  -F "product_name=gateway-firmware" 
  -F "engagement_name=Release 4.2" 
  -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 "Binwalk Scan" 
  --report-path "./binwalk.json" 
  --product-name "gateway-firmware" 
  --engagement-name "Release 4.2" 
  --auto-create-context

3. Reimport for each build. If you track one firmware line in one Test, send later reports to /api/v2/reimport-scan/ so DefectDojo can show what changed between builds.

Data Granularity: What Gets Imported

Binwalk's confidence value is kept in the description rather than mapped to severity, so a reviewer can still see how sure Binwalk was about each match.

Use Cases

In supplier and third-party reviews: A procurement security team receives firmware for a network appliance it is evaluating. Importing the Binwalk report gives them a reviewable list of embedded filesystems and license strings on a dedicated Asset, with notes recording which items were followed up and by whom.

Across firmware releases: An embedded team reimports each release candidate's report into the same Test. A new compressed archive or crypto signature appearing between two builds becomes a new Finding, which prompts the question of who added it and why.

As a feeder for deeper analysis: Binwalk output tells an analyst where to extract and what to examine next. Keeping the inventory in DefectDojo means the follow-up findings from other tools land on the same Asset and the trail from "found a filesystem" to "found a vulnerable library" stays in one place.

For license and provenance questions: Copyright and license text detected inside an image can be filtered and exported from DefectDojo when legal or compliance teams ask what third-party code a product ships.

Operational Tips

• Treat these findings as inventory. Everything imports as Info, so if your SLA configuration applies to Info, consider excluding the Binwalk Engagement or tagging it so it doesn't skew remediation metrics.
• Because the title includes the byte offset, a rebuilt image where content shifts position will produce new Findings for the same signature. Reimport still mitigates the old offsets, so the history stays readable, but expect churn between builds.
• Tag each import with the firmware version (for example tags=fw-4.2.1) so you can filter inventory by release.
• Use test_title to name the Test after the image file when one Engagement covers several images.
• Don't set minimum_severity above Info for this scan type, or nothing will import.
• Add a note to expected signatures, such as a known bootloader, rather than deleting them. A deleted Finding comes back as new on the next reimport, while an annotated one keeps its context.