Crashtest Security Integration with DefectDojo

Crashtest Security Integration with DefectDojo

Crashtest Security was a dynamic application security testing (DAST) service founded in 2017 in Munich, Germany, built for developers who wanted automated security tests in their delivery pipelines. It scanned traditional web applications, JavaScript-heavy front ends, and REST APIs for issues such as injection flaws, cross-site request forgery, file inclusion, insecure deserialization, and known CVEs in exposed software. Veracode acquired Crashtest Security in December 2022 and folded it into its DAST offering. The DefectDojo parser reads the two report formats Crashtest produced: a JSON findings export and a JUnit-style XML report.

Crashtest Security Integration with DefectDojo

Crashtest Security fit our pipeline because it was built to run on every deployment, and DefectDojo is where we keep its results honest over time. A DAST run tells us what is exposed on a given day. Importing Crashtest Security reports into DefectDojo puts each issue on the Asset that owns the application, gives it a CVSS-derived severity, an owner, and an SLA, and keeps it next to the SAST and SCA results for the same code. Teams with historical Crashtest data, or pipelines still producing these formats, keep that history in one place instead of losing it with an old portal.

Why Crashtest Security Matters

DAST finds what the deployed application actually exposes, regardless of language or framework.

• Crashtest tested running applications and APIs from the outside, which catches deployment and configuration problems that code scanners can't see.
• Its JSON findings link to a shared description per vulnerability type with remediation guidance, a reference, and CVSS base and impact scores.
• Detected software CVEs are reported as separate entries with their own CVSS score.
• The JUnit XML output let CI systems treat each security test as a pass or fail test case.
• Scan results by themselves are a snapshot. Without tracking, the same finding resurfaces after each deployment with no record of who is working on it.

Advantages of This Integration

What we gained by importing Crashtest Security results into DefectDojo:

• CVSS-based severity. JSON findings get their severity from the CVSS base score of the vulnerability type, which gives consistent SLA timing across scans.
• CVEs as first-class findings. Each detected CVE becomes its own Finding with the CVE ID set and an NVD reference, so it shows up in vulnerability ID searches and reports.
• Remediation guidance attached. The how_to_fix text from the JSON descriptions becomes the Finding's mitigation, which carries into any Jira ticket.
• A history per Test. Reimporting each scan into the same Test mitigates findings that disappeared and adds new ones.
• One view of the application. DAST findings sit on the same Asset as code and dependency findings and can be assigned, risk-accepted, or reported on together.

How This Integration Works

The parser registers two scan types: Crashtest Security JSON File and Crashtest Security XML File. It decides how to read the file from the file extension, so name JSON exports .json and JUnit reports .xml. Any other extension is rejected.

1. Obtain a report. The JSON parser expects the Crashtest findings structure: a findings object grouped by scanner, plus a descriptions list keyed by slug. A full API response with a top-level data wrapper is also accepted. The XML parser expects JUnit testcase elements, with a failure element on each failed check.

2. Import it. In the UI, open the Engagement, choose Import Scan Results, pick the matching Crashtest Security scan type, and upload the file. To automate it, use the import API, available in Community Edition and DefectDojo Pro:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" \
  -H "Authorization: Token $DD_API_TOKEN" \
  -F "scan_type=Crashtest Security JSON File" \
  -F "file=@crashtest-findings.json" \
  -F "product_name=storefront" \
  -F "engagement_name=DAST" \
  -F "auto_create_context=true"

For the JUnit format, use scan_type=Crashtest Security XML File and an .xml file.

3. Reimport each scan. Send later reports to /api/v2/reimport-scan/ for the same Test so the Test reflects the latest scan.

Data Granularity: What Gets Imported

JSON report

JUnit XML report

For both formats, no endpoint, file path, or CWE is set, and the static or dynamic flag keeps DefectDojo's default (dynamic). This scan type has no per-scanner dedupe entry, so the legacy algorithm applies, with default hashcode fields title, CWE, line, file path, and description.

Use Cases

Preserving DAST history: Teams that ran Crashtest Security before moving to another DAST tool import their last reports so remediation status, SLA breaches, and risk acceptances stay attached to the right Assets.

In a delivery pipeline: A pipeline that produced Crashtest JUnit XML imports it after each deployment. Because XML findings arrive inactive, the security team reviews and activates the ones that need action.

Prioritizing CVEs in exposed software: CVE entries from the JSON export carry their own CVSS-based severity and CVE ID, so they can be filtered and pushed to the team that owns the web server or framework.

Comparing with code findings: With DAST and SAST results on one Asset, AppSec leads can see whether an injection flaw found at runtime matches a code-level finding and close both with one fix.

Operational Tips

• Use the JSON format when you have the choice. It carries CVSS-based severity, mitigation, references, and separate CVE findings, while the XML format carries only a title, message, and type.
• XML findings arrive inactive. Set active=true on import if you want them to count toward metrics and SLAs immediately.
• No endpoints, file paths, or lines are set, and DefectDojo's documentation notes that legacy deduplication typically does not occur without them. Reimport into a stable Test per application instead of relying on cross-Test deduplication.
• The affected URL appears only inside the description text. Add the URL as a tag or note on important findings if you need to filter by it.
• Keep file extensions correct. The parser chooses JSON or XML handling from the extension, not from the scan type you select.
• Set minimum_severity on import if Info-level results from zero CVSS scores add noise.