Parasoft DTP Integration with DefectDojo

Parasoft DTP Integration with DefectDojo

Parasoft DTP (Development Testing Platform) is a commercial reporting and analytics server from Parasoft. It collects results from Parasoft's testing tools, such as C/C++test, Jtest, and dotTEST, and organizes static analysis violations against coding standards and rule sets like CERT C and MISRA. DTP exposes those violations through report filters in its web interface and through its REST API, which returns them as JSON that DefectDojo can import.

Parasoft DTP Integration with DefectDojo

Our embedded and Java teams already push their Parasoft analysis into DTP, so DTP is where static analysis violations live. The trouble is that DTP is a world the application security team rarely visits, and its violations never sat next to our dependency, container, or pentest findings. Bringing Parasoft DTP results into DefectDojo gives each violation an Asset, an owner, an SLA clock, and a status history, and the DefectDojo Pro connector keeps that view current without anyone exporting files.

Why Parasoft DTP Matters

Static analysis in safety and security sensitive code is usually driven by a standard, and DTP is how Parasoft customers report against that standard.

• It aggregates violations from several Parasoft analyzers and languages into one server, organized by report filter.
• Rule identifiers such as CERT_C-INT30-a tie each violation to a specific clause of a coding standard, which auditors and reviewers ask about by name.
• DTP keeps a stable hash for each violation, so the same problem can be followed as the surrounding code changes.
• DTP is built for development and quality teams. Without a shared platform, its violations are hard to weigh against the rest of an application's security risk.

Advantages of This Integration

What changed once Parasoft DTP violations started flowing into DefectDojo:

• File imports and API syncs agree with each other. The parser mirrors the DefectDojo Pro connector field for field and uses the same scan type, so a team can start with file uploads and later enable the connector without getting two copies of every violation.
• Stable identity across builds. Deduplication prefers DTP's own violation hash as the unique ID, falls back to the violation ID, and only then to the rule plus file. When no unique ID matches, DefectDojo compares the title, severity, file path, and rule ID.
• A correct severity ladder. DTP grades severity 1 as the most severe. The parser maps 1 to Critical and 4 to Low, so SLAs apply in the right order instead of upside down.
• Filtering by rule and language. Each finding is tagged with its rule, rule category, analyzer, and language, which makes it easy to build views such as "all Integers category violations in C".
• Shared workflow. Violations can be assigned, risk-accepted with an expiration date, marked as false positives, or pushed to Jira alongside every other finding on the Asset.

How This Integration Works

DefectDojo imports Parasoft DTP data with the Parasoft DTP Scan scan type. There are two routes, and both produce the same findings.

Option 1: JSON file import (Community Edition and DefectDojo Pro). This route exists for teams that cannot hand DefectDojo DTP credentials, for example on air-gapped networks or while a security review is pending. Save the static analysis violations response from the DTP REST API as a JSON file. The parser expects an object with a staticAnalysisViolations list, and also accepts a bare array or an object that names the list violations, data, or results.

In the UI, open the Engagement, choose Import Scan Results, select Parasoft DTP Scan, and upload the file. To automate it:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" 
  -H "Authorization: Token $DD_API_TOKEN" 
  -F "scan_type=Parasoft DTP Scan" 
  -F "file=@dtp-violations.json" 
  -F "product_name=firmware-controller" 
  -F "engagement_name=Static Analysis" 
  -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 "Parasoft DTP Scan" 
  --report-path "./dtp-violations.json" 
  --product-name "firmware-controller" 
  --engagement-name "Static Analysis" 
  --auto-create-context

For later exports, use /api/v2/reimport-scan/ against the same Test so resolved violations are mitigated and new ones are added.

Option 2: Parasoft DTP connector (DefectDojo Pro). The connector pulls violations from the DTP server on a schedule. Configure it with:

1. Your DTP server URL in the Location field, including the port if it is non-standard.
2. A DTP username in the Username field and its password in the Password field. The connector authenticates with HTTP Basic authentication and never logs the password.
3. Optionally, a Minimum Severity to limit what is imported.

DefectDojo creates one Record for each DTP report filter, and each Record carries that filter's violations from the latest build. Findings describe the current state of the code rather than piling up build after build. Map each Record to the DefectDojo Asset that owns the code.

Data Granularity: What Gets Imported

The author field in the DTP response is not imported, matching the connector.

Use Cases

For coding standard compliance: A team building firmware under CERT C reports every DTP violation into DefectDojo, sets SLAs on Critical and High rules, and gives auditors a record showing when each violation was found, who owned it, and when it closed.

On restricted networks: A defense contractor whose DTP server sits on an isolated network exports violations to JSON, carries the file across, and imports it. Later, if policy allows, the same Asset moves to the connector without duplicate findings.

Across many report filters with DefectDojo Pro: An organization with a DTP report filter per product maps each Record to its Asset. Security leads see static analysis debt by product in DefectDojo metrics next to SCA and DAST results.

When prioritizing remediation: Tags on rule category and language let a lead pull every memory safety related violation in C code into a focused remediation sprint and push those findings to Jira.

Operational Tips

• Keep DTP's violation hash in your exports. It is the most stable identity, and the rule plus file fallback can merge two violations of the same rule in one file.
• Line number is not part of the hash, so code that shifts around a violation does not create a duplicate. File path and rule are, so the same rule firing in two files stays two findings.
• Use the connector's Minimum Severity, or minimum_severity on file imports, to keep DTP's informational tier out of your triage queue.
• Map one DTP report filter to one DefectDojo Asset. That keeps ownership and SLA reporting aligned with how your developers already scope work in DTP.
• Pick a path per Asset and stick with it where possible. File import and the connector deduplicate against each other, but a single source is simpler to reason about.
• Filter on tags such as the rule category to triage a family of violations in one pass, then risk-accept rules your team has formally deviated from with a documented reason.