bomber Integration with DefectDojo

bomber Integration with DefectDojo

bomber is an open source command-line tool, maintained in the devops-kung-fu GitHub organization, that scans an existing Software Bill of Materials for known vulnerabilities. It reads CycloneDX, SPDX, and Syft SBOMs, looks each component up against a vulnerability provider (OSV by default, with GitHub Advisory Database, Sonatype OSS Index, and Snyk as alternatives), and reports which components have advisories. With --output=json it writes a JSON report, which is what DefectDojo imports.

bomber Integration with DefectDojo

We already generate SBOMs for every build, so bomber fits our pipeline without another dependency resolver: point it at the SBOM and it tells us which components have advisories. Sending those results to DefectDojo is what makes them actionable. Each advisory becomes a Finding against the component and version that carries it, deduplicated against the last scan, tied to the Asset that ships it, and measured against our SLAs. When an upgrade lands and the next SBOM no longer contains the vulnerable version, reimport closes the Finding.

Why bomber Matters

Many teams now receive SBOMs from suppliers or produce them for compliance, but an SBOM is a parts list, not a risk assessment.

• bomber works from the SBOM alone, so you can assess software you did not build and cannot rebuild, including vendor deliverables.
• It supports the common SBOM formats, so one tool covers CycloneDX from one team and SPDX from another.
• Provider choice matters. OSV needs no credentials, which makes it easy to run in CI, while teams with OSS Index or Snyk access can use those sources instead.
• Rescanning an old SBOM against current advisory data reveals vulnerabilities disclosed after the software shipped, which is exactly the question a long-lived release needs answered.

Advantages of This Integration

• Component-level deduplication. DefectDojo hashes bomber findings on vuln_id_from_tool, component_name, and component_version, so the same advisory on the same package version is one Finding no matter how often you rescan.
• Fix tracking through reimport. Reimporting a newer SBOM's results mitigates advisories for components you upgraded or removed, adds newly reported ones, and reactivates any that return.
• Severity mapped to a common scale. bomber's CRITICAL through UNSPECIFIED ratings map onto DefectDojo's Critical to Info scale, so SBOM findings follow the same SLA rules as findings from your other scanners.
• CVE filtering where it applies. CVE identifiers are attached as vulnerability IDs, so a CVE search across the instance includes bomber results alongside other SCA tools.
• Supplier risk in one place. Vendor SBOMs scanned with bomber can be imported into their own Assets, which gives security leads a per-supplier view of open component risk.

How This Integration Works

DefectDojo reads bomber's JSON output with the bomber Scan scan type.

1. Scan the SBOM and save JSON. bomber writes to standard output, so redirect it to a file:

bomber scan sbom.json --output=json > bomber.json

Choose a different provider with --provider if you have credentials for one; the provider name is recorded in each Finding's description.

2. Import the report. In the UI, open the Engagement, choose Import Scan Results, select bomber Scan, and upload the file. For automation, 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=bomber Scan" 
  -F "file=@bomber.json" 
  -F "product_name=billing-service" 
  -F "engagement_name=SBOM Scans" 
  -F "auto_create_context=true"

DefectDojo Pro users can use Universal Importer from the same pipeline step:

universal-importer import 
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" 
  --scan-type "bomber Scan" 
  --report-path "./bomber.json" 
  --product-name "billing-service" 
  --engagement-name "SBOM Scans" 
  --auto-create-context

3. Reimport on every build or SBOM refresh. Send later reports to /api/v2/reimport-scan/ against the same Test so upgrades close Findings and history stays in one record.

Data Granularity: What Gets Imported

bomber's report doesn't carry remediation text or reference links into the parsed Finding, so plan on reading the advisory itself for fix guidance.

Use Cases

In a CI/CD pipeline: The build generates a CycloneDX SBOM, bomber scans it, and the result is reimported into a Test for that service. A dependency bump that removes a vulnerable version closes its Finding on the next run, and a newly disclosed advisory appears as a new one.

For supplier software: A vendor delivers an SPDX SBOM with each release of an appliance. The security team scans it with bomber and imports it into an Asset for that vendor, which gives them a dated record of what was known at delivery and what has been disclosed since.

For long-lived releases: A team still supports two older product versions. Rescanning their archived SBOMs on a schedule surfaces new advisories against components that shipped years ago, without rebuilding anything.

During an audit: Because every advisory carries its discovery date and status in DefectDojo, an auditor can see when a component vulnerability was first reported for a given release and when the fix shipped.

Operational Tips

• Pin the provider per pipeline. Different providers can return different advisory IDs for the same issue, and since vuln_id_from_tool is part of the hash, switching providers can create new Findings for problems you already track.
• Advisories that aren't CVEs, such as GHSA IDs, stay in vuln_id_from_tool but are not added as vulnerability IDs. Search by the tool ID when you need them.
• A severity value bomber doesn't use on its documented scale defaults to Medium in DefectDojo. Spot-check imports from a new provider to confirm severities land where you expect.
• Use minimum_severity if UNSPECIFIED advisories would overwhelm triage; they import as Info.
• Tag imports with the SBOM's release identifier so Findings can be filtered by version.
• Risk-accept advisories that don't apply to how a component is used, with an expiration date, rather than marking them false positive, so they are reviewed again later.