sbomqs Integration with DefectDojo

sbomqs Integration with DefectDojo

sbomqs is an open source command-line tool from Interlynk that scores the quality of a Software Bill of Materials. It reads SPDX and CycloneDX documents and rates them on a 0 to 10 scale, feature by feature, against criteria such as the NTIA minimum elements and BSI TR-03183 guidance: whether components carry names, versions, suppliers, licenses, checksums, and identifiers. It does not look for vulnerabilities. Its score command can write the results as JSON, which DefectDojo imports.

sbomqs Integration with DefectDojo

We started running sbomqs because customers and regulators began asking for SBOMs, and we realized ours were technically valid but thin. A document with no suppliers and no license data passes a schema check and still fails the person who needs to use it. Importing sbomqs results into DefectDojo turns each weak spot in an SBOM into a Finding on the Asset that ships it, so the team that owns the build can see the gap, fix the generator, and watch the Finding close on the next import.

Why sbomqs Matters

An SBOM is only as useful as the data inside it. Vulnerability matching, license review, and supplier risk all depend on fields that many generators leave empty.

• sbomqs measures completeness feature by feature, so you learn exactly which element is missing rather than getting a single pass or fail.
• It scores against published expectations, including the NTIA minimum elements and BSI TR-03183, which is the language customers and auditors use.
• It works on both SPDX and CycloneDX, so one quality check covers SBOMs from different build tools.
• Missing data hides risk. A component with no version or identifier cannot be matched against vulnerability databases, so a gap in the SBOM can quietly become a gap in SCA coverage.
• A score on its own is easy to ignore. Tracking each gap as work with an owner is what gets generators fixed.

Advantages of This Integration

What we gained by sending sbomqs results through DefectDojo:

• Gaps become actionable items. Each feature that scores below its maximum becomes a Finding with the category, feature name, score, and the sbomqs explanation (for example "0/1 have supplier names").
• Only real gaps are imported. Features at full score and features sbomqs marks as ignored for the run are skipped, so the Test lists only what needs work.
• Severity that reflects the size of the gap. An element that is entirely absent imports as Medium, a weak score as Low, and a nearly complete one as Info, which gives a natural order for fixing.
• Progress over time. Reimporting the score for each new build mitigates gaps that were fixed and reactivates any that return when a generator changes.
• SBOM quality next to SBOM content. Quality Findings live on the same Asset as SCA results, so reviewers can see whether a clean vulnerability report rests on a complete inventory.

How This Integration Works

DefectDojo imports sbomqs output with the sbomqs Scan scan type.

1. Score the SBOM as JSON. Run sbomqs against the SBOM your build produces:

sbomqs score sbom.json --json > sbomqs.json

2. Import the report. In the UI, open the Engagement, choose Import Scan Results, select sbomqs Scan, and upload the file. 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=sbomqs Scan" 
  -F "file=@sbomqs.json" 
  -F "product_name=payments-api" 
  -F "engagement_name=SBOM Quality" 
  -F "auto_create_context=true"

DefectDojo Pro users can run the same import from a pipeline with Universal Importer:

universal-importer import 
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" 
  --scan-type "sbomqs Scan" 
  --report-path "./sbomqs.json" 
  --product-name "payments-api" 
  --engagement-name "SBOM Quality" 
  --auto-create-context

3. Reimport for every release. Send later reports to /api/v2/reimport-scan/ against the same Test. Gaps that the next SBOM fills are mitigated, and new ones are added.

The parser reads every document listed in the report's files section, so a report covering more than one SBOM produces Findings for each, identified by file name.

Data Granularity: What Gets Imported

Use Cases

In a CI/CD pipeline: The build generates an SBOM, runs sbomqs on it, and reimports the score into a Test for that service. If a dependency update or generator change drops supplier or license data, a new Finding appears on the Asset before the SBOM goes to a customer.

Before delivering SBOMs to customers: A product security team checks every SBOM against NTIA minimum elements before it leaves the company. Open Medium Findings mean an element is missing entirely, which is a clear reason to hold the release of the document.

When comparing SBOM generators: A platform team scoring output from two or three generators imports each into its own Test. The Findings show which tool leaves which elements empty, which makes the choice of generator a data question.

For regulatory readiness: Organizations preparing for SBOM requirements can report on how many Assets still have gaps in required elements and track that number down over time.

Operational Tips

• The highest severity sbomqs Findings can reach is Medium. If SBOM completeness is a release requirement for you, set SLAs for Medium and Low that match, or raise severity on specific features during triage.
• Keep the SBOM file name stable between builds. The file name is the component used in deduplication, so renaming sbom.json to include a version number creates a new set of Findings each time.
• Some features may not apply to your use case. Risk-accept them with a note explaining why, so they stay documented instead of reappearing as open work.
• Info Findings mark elements that are mostly present. Use minimum_severity=Low on import if you only want to track larger gaps.
• Tag imports with the SBOM format and generator, for example tags=cyclonedx,syft, to compare quality across toolchains in metrics.
• Read the Description before fixing. The scoring engine version and document average score are recorded there, which helps explain why a score moved after an sbomqs upgrade.
• Run sbomqs on the exact SBOM you publish, not an intermediate file, so the Findings describe what customers receive.