Skip to main content

CVE-bin-tool

Overview​

The CVE-Bin-Tool module integrates intel/cve-bin-tool into Firmware-Vault to identify known CVEs in firmware contents. The current implementation supports two modes:

  1. SBOM → CVE: If a CycloneDX/JSON (sbom formats) SBOM exists (e.g., produced by sbom-gen.py), CVE-Bin-Tool consumes it (--sbom-file) and writes CVE findings to JSON + log.
  2. Raw scan: If no SBOM is present, it scans the extracted firmware filesystem directly.

Both paths write human-readable logs to the job’s output.txt and store results in the database.

Components​

Located under /jobs

  • cve-bin-tool.py: Worker that runs CVE-Bin-Tool against an SBOM or a directory and writes results to DB
  • sbom-gen.py: Worker that generates a CycloneDX SBOM (JSON) from the extracted firmware tree and stores SBOM components in DB
  • Dockerfile_cve-bin-tool: Container image for both workers
  • start-cve-components.sh: Small wrapper to launch both workers in one container (parallel)

Before reading the rest of this page, a general understanding of SBOM, their usage and formats is recommended.
CVE-bin-tool is able to implement two SBOM formats: CycloneDX and SPDX. The firmware fault is using the SBOM type --sbom-type cyclonedx and outputs results into a JSON --sbom-format json.
More information on the topic can be found in CVE-bin-tools' documentation on GitHub.

Components Details​

cve-bin-tool.py (CVE scanning worker)​

Role

  • Pops tasks from Redis (queue_cve-bin-tool)
  • If <firmware_dir>/sbom-cve-output.json exists -> runs: cve-bin-tool --sbom-file <sbom> --offline -f json -o <cve-output.json>
  • Otherwise -> runs a direct scan against the firmware target path (should be the extracted directory)
  • Appends stdout/stderr into <output_path>/output.txt
  • Imports CVE findings into the DB (deduplicating per image_id)

Inputs

  • image_id (int)
  • image_path (str) – original firmware file path; extracted files are expected at <image_path>/../extracted
  • output_path (str) – directory for logs and results
  • job, task, tool (routing/metadata)

Outputs

  • <output_path>/cve-output.json – machine-readable findings for the task
  • <output_path>/output.txt – append-only log with CVE-Bin-Tool output and errors
  • DB rows via DBConnector.insert_result(...)

sbom-gen.py​

Role

  • Pops tasks from Redis (queue_sbom-gen).
  • Validates the extracted firmware directory.
  • Generates CycloneDX JSON SBOM into <image_path>/../sbom-cve-output.json via: cve-bin-tool <extracted_dir> --offline --sbom-type cyclonedx --sbom-format json --sbom-output <sbom>
  • Appends stdout/stderr into <output_path>/output.txt

Upserts SBOM components into DB (components + image-component relations).

Inputs

  • Same payload shape as the CVE worker.

Outputs

  • <image_path>/../sbom-cve-output.json
  • <output_path>/output.txt
  • DB component rows and relations

start-cve-components.sh​

Responsible for running both workers in the same container.

python3 /app/cve-bin-tool.py &
python3 /app/sbom-gen.py &
wait
note

The shell script was created because the Dockerfile can only be given on source script that should execute.
This might be unnecessary, but if the cve-bin-tool receives more use-cases this structure might be helpful.