Netsparker Integration with DefectDojo

Netsparker Integration with DefectDojo

Netsparker was a dynamic application security testing (DAST) scanner for web applications and APIs. The product and company are now Invicti, and the scanner is sold as Invicti Enterprise (cloud-based) and Invicti Standard (on-premises). It crawls an application, sends attack requests, and reports confirmed and unconfirmed vulnerabilities with the HTTP request and response that triggered them. DefectDojo imports its Vulnerabilities List report in JSON format.

Netsparker Integration with DefectDojo

Many teams still have pipelines, scripts, and years of history built around the Netsparker name, and DefectDojo keeps the Netsparker Scan type for exactly that reason. We import the JSON vulnerability list into DefectDojo so each issue lands on the Asset that owns the application, with the affected URLs, the request and response evidence, CWE and CVSS data, and an SLA clock. The same parser code backs the newer Invicti Scan type, so moving to the current name is a scan type change rather than a new integration.

Why Netsparker Matters

DAST finds what source analysis cannot: issues that only exist once the application is deployed with its real configuration, authentication, and infrastructure.

• The scanner tests running applications, so it catches misconfigurations, missing security headers, and injection flaws as an attacker would see them.
• Many findings come with proof of exploit, which separates confirmed issues from ones that need a human to verify.
• Each finding includes remediation guidance and references, which saves the developer a search.
• A scanner's own dashboard tracks one application at a time. It does not put DAST results next to SAST, SCA, and pentest findings for the same Asset.

Advantages of This Integration

What we gained by sending Netsparker results through DefectDojo:

• One finding per issue type, with every affected URL. The parser groups entries with the same vulnerability name into a single finding and attaches each URL as an endpoint, so a header issue on 200 pages is one item to fix, not 200.
• Evidence kept with the finding. HTTP requests and responses from the report are stored on the finding, so a developer can see what the scanner sent without logging into the scanner.
• Triage carries over. Items marked as false positives in the scanner arrive flagged as false positives, and items marked as accepted risk arrive risk-accepted.
• Lifecycle on reimport. Reimporting the next scan into the same Test mitigates issues that are gone, adds new ones, and reactivates any regressions.
• SLAs, ownership, and ticketing. Findings carry Critical through Info severity, can be assigned to the application team, and can be pushed to Jira.

How This Integration Works

DefectDojo imports Netsparker results with the Netsparker Scan scan type. The DefectDojo docs recommend planning a move to the Invicti Scan type for new automation. Both read the same JSON layout.

1. Export a JSON vulnerability list. In Invicti Enterprise, open the scan, choose Report, select Vulnerabilities List under Lists, and set the format to JSON. Include both confirmed and unconfirmed issues if you want to triage everything in DefectDojo.

2. Import it. In the UI, open the Engagement, choose Import Scan Results, select Netsparker Scan, and upload the file. For automation, 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=Netsparker Scan" \
  -F "file=@netsparker-vulnerabilities.json" \
  -F "product_name=customer-portal" \
  -F "engagement_name=Weekly DAST" \
  -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 "Netsparker Scan" \
  --report-path "./netsparker-vulnerabilities.json" \
  --product-name "customer-portal" \
  --engagement-name "Weekly DAST" \
  --auto-create-context

3. Reimport after each scan. Send later exports to /api/v2/reimport-scan/ against the same Test. If you switch to the Invicti Scan type, start it in a new Test and treat the first import as a fresh baseline, since the two scan types use different deduplication settings.

Data Granularity: What Gets Imported

For comparison, the Invicti Scan type deduplicates by hashcode on title, description, and severity.

Use Cases

On a release schedule: A team scans staging before each release and reimports into the same Test. New High and Critical findings block the release through a check against the DefectDojo API, and fixed issues close without manual edits.

For a portfolio of web apps: An AppSec team scanning 40 applications imports each into its own Asset. Leaders get one report of open DAST findings by team and age instead of one scanner dashboard per app.

During a rename migration: Teams with long-running Netsparker automation keep importing under Netsparker Scan while they test the Invicti Scan type on a single application, then switch the rest once the baseline is clean.

With developers who do not use the scanner: Request and response evidence travels with the finding, so a developer working from a Jira ticket created in DefectDojo can reproduce the issue without a scanner license.

Operational Tips

• Expect grouping by title. The first entry's description and severity are kept for the whole group, so if the same issue name appears at different severities, review the merged finding.
• Do not rely on the static/dynamic flag for Netsparker findings in reports or filters; the parser marks them static.
• Mark false positives in the scanner before you export, or mark them in DefectDojo after import. Either way the decision sticks, since false-positive state in the report is imported.
• Use minimum_severity=Low if best-practice and informational items would bury your team. They arrive as Info.
• Keep one Test per application and scan profile so reimport history stays meaningful.
• Plan the move to Invicti Scan for new pipelines, as the DefectDojo docs ask, and keep the old Test read-only for history.