Veracode Integration with DefectDojo

Veracode Integration with DefectDojo

Veracode is a commercial application security platform that offers static analysis (SAST), dynamic analysis (DAST), software composition analysis (SCA), and manual penetration testing as a hosted service. Its static scanner analyzes compiled application packages uploaded to the platform, and its SCA product grew out of Veracode's acquisition of SourceClear. Results are available as a Detailed XML report, through the Findings REST API as JSON, and, for SCA projects, as CSV or JSON issue exports.

Veracode Integration with DefectDojo

We pay for Veracode because it covers static, dynamic, and dependency testing under one contract, and we send its results to DefectDojo because Veracode is not the only scanner our teams run. Inside DefectDojo, a Veracode flaw becomes a Finding on the Asset that owns the application, sitting next to container, cloud, and pentest findings for the same service. Mitigations approved in Veracode carry over on XML import, fixed flaws close on reimport, and remediation work runs through the same SLAs, Jira projects, and reports as everything else we track.

Why Veracode Matters

Veracode is often the primary application scanner in regulated organizations because it can test compiled code without needing build access to every repository, and because its policy engine maps cleanly to compliance requirements.

• Binary static analysis finds flaws in languages and frameworks that are hard to cover with source-only tools.
• Dynamic Analysis tests the running application, so one vendor covers both sides of the SAST and DAST split.
• Veracode SCA (formerly SourceClear) flags vulnerable open source libraries, including transitive dependencies.
• Policy evaluation tells you which flaws block compliance, which helps teams decide what must be fixed before release.
• On its own, Veracode only knows about Veracode findings. The rest of an application's risk lives elsewhere.

Advantages of This Integration

What changes when Veracode results flow through DefectDojo:

• Stable identity for static and dynamic flaws. XML imports carry a unique ID built from the Veracode application ID and issue ID, and DefectDojo deduplicates on that ID first, falling back to a hashcode when no ID is present.
• Mitigation decisions survive the trip. Flaws whose mitigation was accepted in Veracode arrive as mitigated, and flaws Veracode marked as false positives arrive flagged as false positives.
• Policy context. JSON imports tag findings that violate a Veracode policy with policy-violation, so you can filter and report on them directly.
• One SLA model. Veracode's 1 to 5 severity scale maps onto Info through Critical, so Veracode findings fall under the same SLA rules as every other tool.
• Automated sync with DefectDojo Pro. The Veracode connector pulls open findings per Veracode application on a schedule, with no exports to manage.

How This Integration Works

DefectDojo has two scan types for Veracode file imports. Veracode Scan reads the Detailed XML report and Findings API JSON (SAST, DAST, and SCA). Veracode SourceClear Scan reads Veracode SCA project reports in CSV or JSON. DefectDojo Pro adds an API connector.

1. Get a report. For Veracode Scan, download the Detailed Report in XML from the Veracode Platform, or call the Findings API (/appsec/v2/applications/{application_guid}/findings). Veracode signs API requests with HMAC, and its HTTPie plugin handles that:

http --auth-type=veracode_hmac \
  "https://api.veracode.com/appsec/v2/applications/APP_GUID/findings?scan_type=STATIC" \
  > veracode-findings.json

The parser accepts this response as is (the _embedded.findings layout) or a file with a top-level findings array, which is easier when you merge several API calls. File extension matters: .xml goes to the XML parser and .json to the JSON parser. JSON findings with a status of CLOSED are skipped.

For Veracode SourceClear Scan, export the project's issues as CSV, or save the JSON issues response from the Veracode SCA API. Only rows whose issue type is a vulnerability are imported.

2. Import it. In the UI, open the Engagement, choose Import Scan Results, and pick the scan type. Through the API (Community Edition and DefectDojo Pro):

curl "https://YOUR_INSTANCE/api/v2/import-scan/" \
  -H "Authorization: Token $DD_API_TOKEN" \
  -F "scan_type=Veracode Scan" \
  -F "file=@veracode-detailed.xml" \
  -F "product_name=claims-portal" \
  -F "engagement_name=Veracode Policy Scans" \
  -F "auto_create_context=true"

With Universal Importer in DefectDojo Pro:

universal-importer import \
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" \
  --scan-type "Veracode SourceClear Scan" \
  --report-path "./sca-issues.csv" \
  --product-name "claims-portal" \
  --engagement-name "Dependency Scans" \
  --auto-create-context

3. Or connect Veracode directly (DefectDojo Pro). Generate a Veracode API ID and secret key for an account that can see the target applications. In the connector, enter the regional API base URL in Location (https://api.veracode.com, https://api.veracode.eu, or https://api.veracode.us), the API ID, and the secret, plus an optional Minimum Severity. Each Veracode application becomes a Record that you map to a DefectDojo Asset. Findings are split into SAST, DAST, SCA, and Manual types, and because only open findings are imported, a sync closes whatever Veracode reports as resolved.

Data Granularity: What Gets Imported

The table covers the Veracode Scan parser (XML and JSON) followed by the SourceClear parser.

For Veracode SourceClear Scan, each vulnerability issue becomes a Finding titled library:version | CVE, with the component name and version, CVE, CWE, CVSS v3 vector (JSON) or score (CSV), the project name and vulnerability title in the description, and the issue link as a reference. The issue ID is stored as the unique ID. JSON severity is derived from the CVSS v3 score, CSV severity comes from the Severity column. Resolved issues (and ignored issues in CSV) import as mitigated. Deduplication uses title, vulnerability IDs, component name, component version, and severity.

Use Cases

For a policy-driven release process: A team runs Veracode policy scans before each release and imports the Detailed XML report into the application's Engagement. Approved mitigations arrive closed, policy-relevant flaws are assigned with SLA deadlines, and release reviews query DefectDojo instead of exporting from two platforms.

Across a mixed tool estate: An organization uses Veracode for its Java and .NET portfolio and other scanners for containers and cloud. DefectDojo puts every finding for a given Asset in one place, so risk reporting covers the whole application.

For dependency hygiene: Veracode SCA results imported with the SourceClear scan type sit beside the static flaws for the same Asset. Teams can see whether the bigger risk in a service is its own code or its libraries.

With DefectDojo Pro at scale: A security team with hundreds of Veracode applications uses the connector, maps each Record to an Asset once, and lets scheduled syncs keep findings current.

Operational Tips

• Prefer the Detailed XML report when you want Veracode's mitigation decisions and stable issue IDs. JSON imports don't set a unique ID, so they rely on the hashcode fields, which include the description.
• Keep one report format per Test. Switching an application between XML and JSON imports changes how findings are matched and can create duplicates.
• Expect XML SCA findings to match on hashcode only. They carry no Veracode issue ID, so continuity between scans depends on the title, CWE, and description staying the same.
• Use the policy-violation tag from JSON imports to build an SLA or report view for compliance-blocking flaws only.
• Set minimum_severity if Veracode's informational flaws add noise, and lean on Veracode policy for what blocks a release.
• If you are on DefectDojo Pro, set the connector's Minimum Severity rather than filtering after import, and keep one Record per Veracode application mapped to one Asset.