Synopsys Coverity Integration with DefectDojo

Synopsys Coverity Integration with DefectDojo

Coverity is a commercial static application security testing (SAST) and code quality analyzer, originally developed by Coverity Inc., later part of the Synopsys Software Integrity Group, and now sold by Black Duck Software. It analyzes source code in a wide range of languages, including C, C++, Java, C#, JavaScript, and Python, and it also checks infrastructure and configuration files, reporting both security weaknesses mapped to CWE and quality defects. The Coverity CLI (coverity scan) can run a local analysis and write results as JSON, which is the format DefectDojo imports with this parser. Coverity Connect, the server that stores triaged issues per project and stream, can also export issue views as JSON through its REST API, and DefectDojo reads that export as a separate scan type.

Synopsys Coverity Integration with DefectDojo

We use Coverity for deep static analysis of our core services, and we bring its results into DefectDojo so security defects get the same follow-through as findings from every other tool. Each security issue from a Coverity JSON report becomes a Finding with its CWE, file, line, and remediation advice, deduplicated against previous runs and attached to the Asset that owns the code. Reimporting after each analysis gives us an honest picture of what was fixed, and the defects that only Coverity finds stop living in a separate console nobody outside the AppSec team opens. On DefectDojo Pro, the Coverity connector pulls issues straight from Coverity Connect on a schedule, so the server-side triage view arrives without anyone exporting files.

Why Synopsys Coverity Matters

Coverity is known for interprocedural analysis that follows data and control flow across functions and files, which is how it finds defects that pattern-based linters miss.

• It reports each issue with an event trace explaining how the defect arises, plus remediation guidance for many checkers.
• Security checkers map to CWE categories, which lines findings up with standards like the CWE Top 25 and OWASP Top 10.
• Each issue carries an impact rating (High, Medium, Low, or Audit) that helps separate real risk from review-only items.
• Coverity's own platform tracks issues per project and stream, but security leads still need those results in context with SCA, container, and DAST findings for the same application.

Advantages of This Integration

What we gained by routing Coverity results through DefectDojo:

• Security defects only. The parser imports issues whose checker properties include the SECURITY issue kind and skips quality-only defects, so the security queue isn't flooded with style and resource handling noise.
• Stable deduplication. DefectDojo hashes Coverity findings on title, CWE, line, file path, and description, so rerunning analysis on unchanged code doesn't duplicate findings.
• A lifecycle per codebase. Reimporting into the same Test mitigates defects that no longer appear and adds new ones, which gives each analysis run a clear delta.
• SLAs that respect Coverity's impact. High, Medium, and Low impact map straight to DefectDojo severities, and Audit becomes Info, so SLA rules don't treat audit-level items as urgent.
• Triage status carried over. The Coverity API scan type keeps Coverity Connect status: New and Triaged issues stay active, Fixed issues arrive inactive, and issues classified False Positive are marked as such.
• No export step on DefectDojo Pro. The Coverity connector reads a saved Coverity Connect view and creates a Record per Coverity project, so findings stay current without a pipeline job.
• Remediation in the ticket. The checker's remediation event lands in the Mitigation field, so a Jira ticket pushed from DefectDojo already tells the developer how to fix it.

How This Integration Works

DefectDojo imports Coverity CLI output with the Coverity Scan JSON Report scan type, and Coverity Connect issue view exports with the Coverity API scan type. DefectDojo Pro can also connect to Coverity Connect directly.

1. Run a local analysis and write JSON. With the Coverity CLI installed and configured for your project:

coverity scan --project-dir ./payments-api --local coverity-results.json --local-format json

The parser reads the top-level issues array. For each issue it uses checkerProperties (issue kinds, impact, CWE category, descriptions), the main and remediation entries in events, and the main event file path and line.

2. Import it. In the UI, open the Engagement, choose Import Scan Results, select Coverity Scan JSON Report, and upload the file. To automate it, use the import API in Community Edition or DefectDojo Pro:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" \
  -H "Authorization: Token $DD_API_TOKEN" \
  -F "scan_type=Coverity Scan JSON Report" \
  -F "file=@coverity-results.json" \
  -F "product_name=payments-api" \
  -F "engagement_name=SAST" \
  -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 "Coverity Scan JSON Report" \
  --report-path "./coverity-results.json" \
  --product-name "payments-api" \
  --engagement-name "SAST" \
  --auto-create-context

3. Reimport on each analysis. Send later reports to /api/v2/reimport-scan/ for the same Test so fixed defects are mitigated and their history stays together.

Option: Coverity Connect view export (Coverity API scan type). Export a Coverity Connect issue view as JSON from the /api/viewContents/issues REST endpoint. The view must include the Type, Impact, Status, and First Detected columns (displayType, displayImpact, status, firstDetected); CWE, File, and Occurrence Count are used when present. The parser expects the viewContentsV1.rows structure and rejects anything else. Import the file with scan_type=Coverity API using the same UI, API, or Universal Importer steps shown above.

Option: Coverity connector (DefectDojo Pro). In the DefectDojo Pro connector settings, add a Coverity connector and fill in:

• Location: your Coverity Connect server URL.
• Username: the Coverity Connect user the connector signs in as.
• Secret: that user's password or authentication key.
• View Name (optional): the saved issues view to read. Blank uses the default, Outstanding Issues.
• Import All Issue Kinds (optional): set to true to go beyond the default Security and Quality (RESOURCE_LEAK) filter.

DefectDojo creates a Record for each Coverity project and syncs it on the connector schedule.

Data Granularity: What Gets Imported

Issues without SECURITY in checkerProperties.issueKinds are not imported.

The Coverity API scan type maps a Coverity Connect view row differently:

Rows are imported when displayIssueKind is Security, or Quality with the RESOURCE_LEAK checker. The DefectDojo Pro connector uses the same default filter unless Import All Issue Kinds is enabled.

Use Cases

In a pull request pipeline: A CI job runs coverity scan on the changed service and reimports the JSON into that service's SAST Test. Developers see new security defects in DefectDojo or in Jira, and the pipeline can query DefectDojo for new High findings before merging.

For large C and C++ codebases: Teams with long-lived native code often carry a backlog of Coverity security defects. Importing them into DefectDojo lets the security team set SLAs, risk-accept legacy items with expirations, and report progress by team.

Alongside other SAST tools: Organizations that run Coverity for compiled languages and a lighter scanner for scripting languages can see both on one Asset and compare coverage by CWE.

For compliance evidence: Auditors asking for proof that static analysis runs and that findings are remediated can see discovery dates, owners, SLA status, and closure dates for each Coverity finding.

Operational Tips

• Plan SLAs around the severity ceiling. Coverity impact tops out at High in this mapping, so if your policy needs Critical, raise specific CWEs during triage.
• Coverity quality defects (for example resource leaks) are skipped by the file parser. If you want those tracked, manage them in Coverity rather than expecting them in DefectDojo.
• Keep the analysis root consistent. File paths come from the stripped main event path, and the file path is part of the hashcode, so changing the build layout will create new findings.
• Expect line shifts to matter. Line number is a hashcode field, so refactoring above a defect can mitigate it and recreate it as new on the next reimport.
• Pick one source per codebase. The CLI JSON scan type deduplicates on a hashcode, while Coverity API deduplicates on CID, so importing both for the same project produces parallel findings rather than merged ones.
• For the Coverity connector or the Coverity API export, build a saved view in Coverity Connect that holds exactly the issues you want tracked. The connector reads Outstanding Issues unless you set View Name.
• Use one Test per repository or Coverity stream and reimport into it, rather than a new Test per run.
• Tag imports with the branch or stream name (for example tags=main) to keep release branches separate in metrics.