Wapiti Integration with DefectDojo

Wapiti Integration with DefectDojo

Wapiti is an open source black-box web application vulnerability scanner created by Nicolas Surribas and developed under the wapiti-scanner project on GitHub. Written in Python and licensed under GPL-2.0, it crawls a target site, finds the forms, parameters, and scripts it can inject into, and runs attack modules that check for classes of issues such as injection flaws, cross-site scripting, file disclosure, open redirects, server-side request forgery, and weak security headers. Wapiti writes reports in HTML, XML, JSON, TXT, CSV, and Markdown. DefectDojo imports the XML report.

Wapiti Integration with DefectDojo

Wapiti is the lightweight DAST tool we can point at any staging URL from a container without licenses or agents, and DefectDojo gives its output a lifecycle. Each Wapiti report lists what the scan found today. Imported into DefectDojo, those results become Findings on the Asset for that site, with the request that triggered each one, references to CWE and OWASP material, and an owner and SLA. When the next scan comes back clean for an issue, reimport closes it, so we track fixes instead of comparing HTML reports by eye.

Why Wapiti Matters

Many web vulnerabilities only show up when someone sends real requests to a running application. Wapiti does that from the outside, with no access to source code.

• It tests the deployed application, including its server configuration and headers, not just the code.
• Its modules cover the common web vulnerability classes and also check for known issues such as Log4Shell and Shellshock.
• It is free, scriptable from the command line, and easy to run in CI against a test environment.
• Every finding includes the HTTP request Wapiti sent, so developers can reproduce it.
• Run by itself, Wapiti has no history. You can't tell from a report whether an issue is new or has been open for three releases.

Advantages of This Integration

What we get by sending Wapiti reports through DefectDojo:

• Repeat entries collapsed. Within a report, entries with the same description, title, and severity merge into one Finding with an occurrence count, and their requests are kept together.
• Deduplication across scans. DefectDojo compares each new Wapiti finding to existing ones using its Legacy algorithm, which compares title or CWE, the endpoint, and a hash of title, CWE, line, file path, and description, so a weekly scan doesn't duplicate open issues.
• Fix tracking with reimport. Reimporting into the same Test mitigates findings that no longer appear and reactivates any that come back after a regression.
• Severity that fits our SLAs. Wapiti's numeric levels map to DefectDojo severities, so its findings fall under the same SLA rules as findings from commercial DAST tools.
• Workflow beyond the scanner. Findings can be assigned, commented on, risk-accepted, or pushed to Jira, and they show up in Asset-level metrics with SAST and SCA results.

How This Integration Works

DefectDojo imports Wapiti results with the Wapiti Scan scan type. The parser requires a Wapiti XML report whose root element is report.

1. Run Wapiti with XML output.

wapiti -u https://staging.example.com/ -f xml -o wapiti-report.xml

Scope, modules, and authentication options are up to you. The import only needs the XML file.

2. Import the report. In the UI, open the Engagement, choose Import Scan Results, select Wapiti Scan, and upload the XML. 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=Wapiti Scan" \
  -F "file=@wapiti-report.xml" \
  -F "product_name=partner-portal" \
  -F "engagement_name=Staging DAST" \
  -F "auto_create_context=true"

DefectDojo Pro users can use Universal Importer from the same pipeline:

universal-importer import \
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" \
  --scan-type "Wapiti Scan" \
  --report-path "./wapiti-report.xml" \
  --product-name "partner-portal" \
  --engagement-name "Staging DAST" \
  --auto-create-context

3. Reimport on each run. For a target you scan regularly, send each new report to /api/v2/reimport-scan/ for the same Test so findings are updated in place.

Data Granularity: What Gets Imported

Wapiti entries also carry a method, path, and parameter. The parser does not map those to separate fields, but the stored HTTP request shows the method and path, and the entry info text in the title often describes the affected parameter or page.

Use Cases

In a staging pipeline: After each deployment to staging, a CI job runs Wapiti against the site and reimports the XML into the site's Test. New findings are triaged the same day, and fixed issues close on the next run without anyone updating a spreadsheet.

For teams without a commercial DAST license: A small security team uses Wapiti for broad coverage of internal web applications and imports each into its own Asset. DefectDojo gives them SLA tracking and reporting that the scanner alone can't.

Alongside other scanners: Wapiti and another DAST tool scan the same application, and both import into the same Asset. Overlapping results can be compared, and the team sees which tool finds what.

For remediation verification: After a developer fixes a header or redirect issue, the next Wapiti run and reimport records the mitigation date, which gives auditors a timestamped trail.

Operational Tips

• Every Finding's endpoint is the scan's target URL, not the page where Wapiti found the issue. Read the title and the stored request to locate the affected path, and scan one site per Test so endpoints stay meaningful.
• The title includes Wapiti's per-entry info text. If that text includes values that change between runs, the title changes too and deduplication treats it as a new Finding, so watch for churn after the first few reimports.
• Wapiti's modules send active test requests. Point it at staging or test environments you own and are authorized to scan, and get approval before scanning production.
• Use minimum_severity if informational header findings flood the first import, then lower it once the backlog is under control.
• Tag imports with the environment and Wapiti version (for example tags=staging,wapiti) so results from different module sets can be separated later.
• Accept known low-risk findings with an expiration date instead of deleting them, so they are reviewed again after a set period.