Microfocus Webinspect Integration with DefectDojo
Microfocus Webinspect Integration with DefectDojo
WebInspect is a dynamic application security testing (DAST) scanner that crawls a running web application or web service and sends attack requests to find issues such as injection flaws, cross-site scripting, information disclosure, and insecure configuration. It was created by SPI Dynamics, became part of HP and then Micro Focus under the Fortify brand, and is now owned by OpenText, which is renaming Fortify WebInspect to OpenText Dynamic Application Security Testing (OpenText DAST). WebInspect can export scan details as XML, and DefectDojo imports that XML. Teams that run scans centrally through WebInspect Enterprise (WIE) can also connect DefectDojo Pro to the WIE server directly.
Microfocus Webinspect Integration with DefectDojo
We run WebInspect against staging builds of our customer-facing applications, and DefectDojo is where its results turn into assigned work. The WebInspect console is good at showing one scan in detail. It isn't where our developers live, and it doesn't put DAST results next to the SAST and SCA findings for the same application. Importing the XML into DefectDojo gives each issue an owner and an SLA, groups repeated issues across URLs into one Finding, and keeps history across rescans so we can see what a release actually fixed. Where scans run through WebInspect Enterprise, the DefectDojo Pro connector pulls each application's latest completed scan without anyone exporting XML.
Why Microfocus Webinspect Matters
DAST tests the application the way an attacker meets it: over HTTP, after deployment, with real configuration.
- It finds problems that only exist at runtime, such as missing security headers, cookie flags, server misconfiguration, and error pages that leak details.
- It tests the deployed stack, including web servers, frameworks, and proxies that static analysis never sees.
- WebInspect classifies issues with CWE identifiers and Fortify categories, which helps map results to policy and compliance requirements.
- Large WebInspect scans can produce the same issue on hundreds of URLs. Without a platform to group and track them, teams either drown in repeats or stop reading.
Advantages of This Integration
What we get by sending WebInspect results through DefectDojo:
- Grouping across URLs. Within one report, issues with the same name, description, and severity are merged into a single Finding with every affected URL attached and an occurrence count.
- History across rescans. Reimporting into the same Test mitigates issues that no longer appear, adds new ones, and reactivates any that return after a regression.
- SLA tracking. WebInspect's 0 to 4 severity scale maps onto DefectDojo's Info through Critical, so DAST issues fall under the same SLA rules as everything else.
- Fix guidance attached. WebInspect's Fix section becomes the Finding's Mitigation and its Reference Info becomes References, so developers have remediation advice in the Finding or the Jira ticket pushed from it.
- Central scans without exports on DefectDojo Pro. The WebInspect Enterprise connector creates a Record for each application its token can see and imports DAST findings from the most recent completed scan.
- One view per application. DAST Findings sit on the same Asset as code and dependency findings, so application risk reports include runtime issues.
How This Integration Works
DefectDojo imports WebInspect XML exports with the Microfocus Webinspect Scan scan type. DefectDojo Pro can instead sync from a WebInspect Enterprise server with a connector, described after the file steps.
1. Export the scan as XML. From WebInspect, export the scan details as XML. The parser expects the export whose root element is Sessions, containing one Session per URL with its Issues. Any other XML layout is rejected with "This doesn't seem to be a valid Webinspect xml file."
2. Import it. In the UI, open the Engagement, choose Import Scan Results, select Microfocus Webinspect Scan, and upload the XML. For automation, use the 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=Microfocus Webinspect Scan" \
-F "file=@webinspect-scan.xml" \
-F "product_name=customer-portal" \
-F "engagement_name=Staging 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 "Microfocus Webinspect Scan" \
--report-path "./webinspect-scan.xml" \
--product-name "customer-portal" \
--engagement-name "Staging DAST" \
--auto-create-context
3. Reimport after each scan. For a recurring scan of the same application, send later exports to /api/v2/reimport-scan/ against the same Test so fixed issues are closed and returning ones are flagged.
Option: WebInspect Enterprise connector (DefectDojo Pro). You need a WebInspect Enterprise API token; WIE accepts a Fortify-style API token, and the connector never logs it. Add a WebInspect Enterprise connector in DefectDojo Pro and set:
- Location: your WebInspect Enterprise server URL.
- Secret: the API token.
- Minimum Severity (optional): limits which findings are imported.
Each WIE application the token can see becomes a Record, and its findings come from that application's most recent completed scan. The connector syncs on a schedule, so there is no reimport step to script.
Data Granularity: What Gets Imported
| DefectDojo Field | Source in WebInspect XML | Notes |
|---|---|---|
| Title | Issue Name |
The WebInspect check name |
| Severity | Issue Severity |
0 Info, 1 Low, 2 Medium, 3 High, 4 Critical; anything else Info |
| Description | CWE Classification text |
Lists the CWE classification names; the Summary section isn't carried over |
| Mitigation | ReportSection named "Fix" | WebInspect's remediation guidance |
| References | ReportSection named "Reference Info" | Converted from HTML to text |
| CWE | Classification with kind="CWE" |
One CWE per Finding; 0 if none is present |
| Endpoint | Session URL |
Merged Findings carry every affected URL |
| Occurrences | Count of merged issues | Incremented for each repeat in the report |
| Unique ID from Tool | Issue id attribute |
Stored when present |
| Finding type | Dynamic | All WebInspect findings are dynamic |
| Deduplication | Legacy algorithm | No per-scanner config; hash falls back to title, CWE, line, file path, description |
The table describes the XML file parser. The connector doc does not list its field mappings, so check a synced Record before building reports that depend on specific fields.
WebInspect's Implication and Execution sections, the 7PK classifications, and the raw request and response are not imported. Keep the WebInspect scan file if you need them for reproduction.
Use Cases
Before a release: The AppSec team scans the staging build, imports the XML into the release Engagement, and pushes High and Critical Findings to Jira. The release gate checks DefectDojo for active Critical Findings on that Asset.
For recurring scans of a portfolio: A team scanning 20 web applications each month reimports each export into a Test per application. Monthly metrics show which applications are improving and which keep reintroducing the same header or cookie issues.
When triaging large scans: A scan that reports a missing header on 300 pages arrives as one Finding with 300 endpoints. The team fixes it once at the web server or framework level and closes it on the next reimport.
For compliance evidence: Auditors asking for proof of regular DAST and remediation can see scan dates, Finding status history, and SLA compliance per application in DefectDojo reports.
Operational Tips
- Read the WebInspect console or export for full context when triaging. The imported description holds only the CWE classification text, so the Summary, Implication, and Execution details stay in WebInspect.
- Use one Test per application and reimport into it. Because this scan type uses the Legacy algorithm, reimport matches on title and severity, which works well when the same scan policy is reused.
- Keep scan policies consistent between runs. Changing the policy changes which checks run, and missing checks will look like fixed Findings on reimport.
- Review Info Findings before filtering them out. Severity 0 in WebInspect covers best-practice items, and
minimum_severity=Lowon import is a reasonable way to keep them out of developer queues. - Use risk acceptance with an expiration date for findings that are compensated elsewhere, such as headers set by a CDN in production but absent in staging.
- Scope the WIE API token to the applications you want in DefectDojo. The connector creates a Record for every application the token can see.
- With the connector, only completed scans count. A scan that is still running or that failed leaves the previous results as the current state.
- Tag imports with the environment (for example
tags=staging) if you scan more than one environment for the same Asset.