AppSpider (Rapid7) Integration with DefectDojo

AppSpider (Rapid7) Integration with DefectDojo

AppSpider is Rapid7's on-premises dynamic application security testing (DAST) scanner, originally developed by NTObjectives before Rapid7 acquired the company. It crawls web applications and web services, sends attacks against the inputs it discovers, and reports vulnerabilities such as injection flaws, cross-site scripting, and session management weaknesses, along with the HTTP requests and responses that demonstrate them. AppSpider reports are downloaded as a zip archive, and DefectDojo imports the VulnerabilitiesSummary.xml file inside it.

AppSpider (Rapid7) Integration with DefectDojo

We run AppSpider against internal and customer-facing applications that can't be scanned from a SaaS tool, and DefectDojo is where its results get worked. An AppSpider report is thorough but static: a zip of HTML and XML that describes one scan. Imported into DefectDojo, each vulnerability type becomes a Finding on the application's Asset, with every affected URL listed as an endpoint and the attack traffic attached as evidence. The next scan updates that history instead of producing another archive for someone to compare by hand.

Why AppSpider (Rapid7) Matters

A DAST scanner tests the application the way an attacker reaches it, through HTTP, which catches problems that source review never sees.

• AppSpider runs inside your own network, so it can reach applications that are not exposed to the internet.
• Each vulnerability includes the attack request and the server's response, which gives developers a concrete reproduction case.
• Findings are classified with a CWE and come with a description and recommendation text.
• On a large application, one weakness can appear on hundreds of URLs. Reading that in a report is tedious, and tracking it across scans without a platform is close to impossible.

Advantages of This Integration

What we gained by sending AppSpider results through DefectDojo:

• One Finding per issue, not per URL. The parser merges vulnerabilities of the same type and severity into a single Finding and attaches each affected URL as an endpoint, so a weakness repeated across a site is tracked once.
• Evidence kept with the Finding. Every AttackRequest request and response pair is stored with the Finding, so engineers can see exactly what triggered it.
• Lifecycle across scans. Reimporting a new report into the same Test mitigates issues that no longer appear and reactivates any that return.
• CWE-based reporting. Every finding carries AppSpider's CWE ID, which makes it possible to report DAST results by weakness class alongside other scanners.
• Shared SLAs and ticketing. AppSpider findings follow the same SLA rules as other tools on the Asset and can be assigned or pushed to Jira.

How This Integration Works

DefectDojo imports AppSpider results with the AppSpider Scan scan type.

1. Download the report and extract the summary. After a scan completes, download the zipped report from AppSpider and extract VulnerabilitiesSummary.xml. It is the only file in the archive DefectDojo reads. The parser checks that the XML root is a VulnSummary element and rejects other files with a message asking for the right one.

2. Import the file. In the UI, open the Engagement, choose Import Scan Results, select AppSpider Scan, and upload the XML. For automation, 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=AppSpider Scan" \
  -F "file=@VulnerabilitiesSummary.xml" \
  -F "product_name=claims-portal" \
  -F "engagement_name=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 "AppSpider Scan" \
  --report-path "./VulnerabilitiesSummary.xml" \
  --product-name "claims-portal" \
  --engagement-name "DAST" \
  --auto-create-context

3. Reimport each new scan. Send later reports for the same application to /api/v2/reimport-scan/ against the same Test, so fixed issues close and the history stays in one place.

File import is the documented path for AppSpider. DefectDojo Pro's Rapid7 InsightAppSec connector covers Rapid7's cloud DAST product, which is a separate product from AppSpider.

Data Granularity: What Gets Imported

AppSpider Scan has no scan-specific deduplication entry in DefectDojo's settings, so it uses the default (legacy) algorithm, which compares those fields and also takes endpoints into account.

Use Cases

For internal applications: A team scanning 15 intranet applications from an on-premises AppSpider instance imports each summary into the owning Asset. Security leads get one view of DAST exposure across internal apps that no external scanner can reach.

Before a production release: A scan of the staging environment is imported into a release Engagement. The release manager sees open High and Critical findings with owners attached, and the attack evidence makes it easy for developers to confirm a fix.

During remediation sprints: Because each vulnerability type is one Finding with its affected URLs listed, a developer can fix the root cause, rescan, and watch the endpoints and the Finding close on reimport.

For compliance evidence: PCI-DSS and similar programs ask for proof of regular application scanning and remediation. DefectDojo keeps discovery dates, SLA status, and closure history for each AppSpider finding.

Operational Tips

• Review the severity mapping before you configure SLAs. AppSpider's attack scores are shifted up one level in DefectDojo, so a 2-Low becomes Medium and a 4-High becomes Critical. Adjust SLA expectations or triage severity accordingly.
• Use minimum_severity with the shift in mind. Setting it to Medium keeps AppSpider 2-Low results and above, and drops 1-Informational items.
• Upload only VulnerabilitiesSummary.xml. Uploading the zip or another file from the report fails validation.
• Keep one Test per application and reimport into it, so merged endpoints and lifecycle status stay consistent between scans.
• Tag imports with the scan configuration or environment (for example tags=staging,authenticated) so authenticated and unauthenticated scans can be compared.
• Because findings merge by type and severity, a single Finding can cover many URLs. Check its endpoint list before closing it manually.