Syft Integration with DefectDojo

Syft Integration with DefectDojo

Syft is an open source CLI tool and Go library from Anchore that generates software bills of materials (SBOMs) from container images, filesystems, and archives. It catalogs operating system packages and language ecosystem dependencies, recording each package's name, version, type, purl, CPEs, licenses, and the file locations where it was found. Syft writes several formats, including its native syft-json, CycloneDX, and SPDX. DefectDojo's Syft parser reads the native syft-json format.

Syft Integration with DefectDojo

We generate Syft SBOMs for every image we ship, and importing them into DefectDojo gives each Asset a searchable inventory of what is actually installed. Syft does not report vulnerabilities, and DefectDojo does not pretend it does: every package lands as an Info Finding that records presence, version, purl, and license. That inventory lives beside the vulnerability findings from our scanners for the same Asset, so when a new advisory drops we can check which services carry the affected package before the next scan cycle even runs.

Why Syft Matters

An SBOM answers a question that vulnerability scanners only answer indirectly: what is in this artifact? Syft is a common way to produce one.

• It catalogs both OS packages and language dependencies from a single image or directory scan.
• Each package carries a purl and CPEs, which are the identifiers downstream tools use to match advisories.
• License data is recorded per package where the source declares it, which supports license review.
• File locations show where each package was found inside the image or directory, which helps trace a dependency back to the layer or lockfile that introduced it.
• Its output feeds vulnerability scanners such as Grype, so one SBOM can serve both inventory and scanning.

Advantages of This Integration

• Inventory per Asset. Every cataloged package becomes an Info Finding on the Asset, searchable by component name and version across your whole portfolio.
• Honest severity. Syft assigns no severity, so all entries import as Info. They never trip a vulnerability SLA, and they never get mixed up with actual findings in a severity report.
• Deduplication on package identity. Findings are hashed on component name, component version, and the purl (or the package name when no purl exists), so a repeated SBOM of an unchanged image does not duplicate the inventory.
• Change tracking with reimport. Reimporting a new SBOM into the same Test mitigates packages that were removed, adds new ones, and reactivates any that returned. A version bump shows up as one package mitigated and one added.
• Pairs with vulnerability data. Feed the same SBOM to a scanner DefectDojo also parses, such as Grype, and import both. Inventory and vulnerabilities then sit on the same Asset under the same Engagement.

How This Integration Works

DefectDojo imports native Syft output with the Syft SBOM scan type. If you export CycloneDX or SPDX from Syft instead, use DefectDojo's CycloneDX or SPDX parsers; this page covers syft-json.

1. Generate the SBOM. Scan a directory, image, or archive and write syft-json:

syft scan dir:. -o syft-json > syft.json

For a container image, replace dir:. with the image reference, for example registry.example.com/myapp:2.3.0.

2. Import it. In the UI, open the Engagement, choose Import Scan Results, select Syft SBOM, 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=Syft SBOM" 
  -F "file=@syft.json" 
  -F "product_name=myapp" 
  -F "engagement_name=SBOM" 
  -F "auto_create_context=true"

DefectDojo Pro users can do the same with Universal Importer:

universal-importer import 
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" 
  --scan-type "Syft SBOM" 
  --report-path "./syft.json" 
  --product-name "myapp" 
  --engagement-name "SBOM" 
  --auto-create-context

3. Reimport per release. Send each new SBOM for the same artifact to /api/v2/reimport-scan/ against the same Test, so the inventory reflects the current build and keeps the history of what changed.

Data Granularity: What Gets Imported

CPEs, file metadata, and relationships in the SBOM are not mapped to Finding fields.

Use Cases

Responding to a new advisory: When a widely used library publishes a fix, search DefectDojo by component name to list every Asset whose latest SBOM contains the affected versions. That answer comes from inventory you already have, before any rescan.

In a CI/CD pipeline: Each image build runs Syft and reimports the SBOM, then runs a vulnerability scanner on the same SBOM and imports those results too. Engineers see what changed in the package set and which of those changes introduced new vulnerabilities.

License review: Because the description records declared licenses, a compliance reviewer can filter an Asset's Syft findings and spot packages with licenses that need approval or with none declared.

Supplier and audit requests: When a customer asks what a product ships, the Syft findings on that Asset give a current, versioned package list with history of when each package was added or removed.

Operational Tips

• Do not set minimum_severity above Info for Syft imports. Every Syft entry is Info, so a higher threshold imports nothing.
• Keep Syft SBOMs in their own Engagement or Test, separate from vulnerability scans, so inventory counts do not distort finding metrics.
• Use one Test per artifact and reimport into it. A new Test per build works, but you lose the clean record of which packages were added or removed.
• Tag imports with the image tag or release number so the inventory for a given version can be retrieved later.
• If you need CycloneDX or SPDX for distribution, you can still import syft-json into DefectDojo. Syft can write several formats in one run, so you do not have to choose.
• Large images can contain thousands of packages. Expect a matching number of Info findings and plan dashboards and filters accordingly.