Categories
Dynamic Application Security Testing (DAST)
Infrastructure Scanning
Integrates With
Burp Enterprise Scan
Burp Dastardly
Burp GraphQL API
Burp REST API
File Types
Base64
HTML
JSON
Burp Enterprise
Burp Suite Enterprise Edition (now branded as Burp Suite DAST) is an automated dynamic application security testing platform by PortSwigger that performs continuous, scalable vulnerability scanning of web applications and APIs to identify security flaws including injection attacks, cross-site scripting, authentication issues, and other OWASP vulnerabilities across the software development lifecycle. The platform leverages the same scanning engine as Burp Suite Professional with enterprise-grade automation, CI/CD integration, and centralized management capabilities, enabling organizations to conduct comprehensive security testing with minimal false positives while freeing security teams to focus on manual testing and remediation.
Burp Suite Enterprise Integration with DefectDojo
Burp Suite Enterprise Edition is the automated, scalable deployment of the scanner that security professionals trust most for manual web application testing. Where Burp Suite Professional gives individual testers an interactive proxy and manual testing toolset, Burp Suite Enterprise brings that same scanner engine to continuous, scheduled, and pipeline-triggered automated scanning across an entire application portfolio — with centralized scan management, concurrent scan capacity, and the depth of coverage that PortSwigger has refined through years of real-world penetration testing use. The findings Burp Suite Enterprise produces are, by reputation, among the most signal-rich DAST results available: detailed evidence, accurate confidence ratings, and vulnerability descriptions that reflect genuine understanding of web application attack patterns. Integrating Burp Suite Enterprise with DefectDojo brings those findings into a persistent vulnerability management lifecycle — deduplicated across scan cycles, SLA-enforced, assigned to remediation owners, and reportable across your entire application portfolio in a single platform.
Why Burp Suite Enterprise Matters
Burp Suite Enterprise's standing in enterprise DAST comes from the quality of its scanner engine — the same engine used by the world's most skilled web application penetration testers, deployed at scale.
- The PortSwigger scanner is recognized for the accuracy and depth of its web vulnerability detection — covering SQL injection, XSS (reflected, stored, DOM-based), XXE, SSRF, command injection, path traversal, insecure deserialization, authentication weaknesses, business logic vulnerabilities, CSRF, and a continuously updated library of application-specific checks
- Burp Suite Enterprise handles modern web application complexity: JavaScript-heavy SPAs, authenticated scan sessions, multi-step workflows, API endpoints discovered through crawling, and WebSocket communications — areas where simpler DAST tools produce incomplete coverage
- Every finding comes with detailed evidence: the exact HTTP request that triggered the vulnerability, the response that confirmed it, and PortSwigger's explanation of the vulnerability class with remediation guidance — reducing the time security engineers and developers spend validating and understanding findings
- Scan configurations support authenticated crawling through complex login flows, form submission, custom header injection for API authentication, and session handling rules — enabling coverage of the authenticated application surface that unauthenticated scans miss entirely
- Burp Suite Enterprise's REST API and scheduled scan capabilities allow it to run as part of a CI/CD pipeline, on a scheduled cadence, or triggered by application deployment events — supporting continuous DAST coverage rather than periodic assessment cycles
- Findings are exportable via the Burp Suite Enterprise API in XML and JSON formats that DefectDojo can consume, enabling automated pipeline import without manual report download
Advantages of This Integration
Burp Suite Enterprise delivers DAST findings with PortSwigger's depth. DefectDojo operationalizes those findings with the lifecycle management discipline that enterprise security programs require.
- Persistent finding records across DAST scan cycles: Each time Burp Suite Enterprise scans an application, reimporting into DefectDojo updates existing findings rather than generating a disconnected new record set. You can see which XSS or injection findings have persisted across multiple scan cycles, which were resolved between scans, and which have been open for 60 days without action — context that Burp's scan history console doesn't provide with the same durability or cross-application aggregation.
- SLA enforcement for web application vulnerabilities: DefectDojo applies configurable SLA policies by severity across all imported Burp Suite Enterprise findings. Critical and High DAST vulnerabilities get remediation deadlines; Medium findings get longer targets. Breach tracking surfaces overdue items in dashboards and weekly reports — turning Burp's severity ratings into enforceable deadlines rather than color-coded scan results.
- Cross-application portfolio visibility: Organizations scanning dozens or hundreds of web applications with Burp Suite Enterprise get aggregated findings across their entire portfolio in DefectDojo — open vulnerabilities by severity, type, application, age, and SLA status — without navigating application-by-application through Burp's scan management console.
- False positive management that persists across scans: Burp Suite Enterprise produces a low false positive rate, but for complex applications with unusual patterns, some findings warrant false positive documentation. Findings marked as false positives in DefectDojo are retained across reimports — the next Burp scan won't re-open them, and the documented rationale is auditable rather than relying on scanner-side suppression.
- Evidence-rich developer tickets: Burp Suite Enterprise findings include the full HTTP request/response pair that confirmed the vulnerability. When findings are pushed from DefectDojo to Jira or GitHub Issues, this evidence travels with the ticket — giving developers the exact reproduction steps and proof of exploitability without requiring access to Burp Suite Enterprise or a Burp-trained security engineer to explain the finding.
- Unified DAST and SAST/SCA view: Web application vulnerabilities found by Burp Suite Enterprise sit alongside SAST findings from Semgrep or Checkmarx, SCA findings from Snyk, and cloud findings from Wiz in a single DefectDojo product. Security teams prioritize across finding types from one queue; security leadership reports on total application risk rather than tool-specific dashboards.
- Compliance evidence for continuous DAST requirements: Frameworks including PCI DSS require regular application security testing of cardholder data environment applications. DefectDojo's engagement history, finding lifecycle records, and remediation tracking provide structured evidence of continuous DAST coverage — documentation that Burp Suite Enterprise's own reporting doesn't provide with the same lifecycle completeness.
How This Integration Works
Burp Suite Enterprise findings are exported via the Burp Suite Enterprise REST API or downloaded as XML scan reports, then imported into DefectDojo using the Burp Suite Enterprise parser.
Step 1 — Export findings from Burp Suite Enterprise
Using the Burp Suite Enterprise REST API to retrieve scan results:
# Get a list of completed scans
curl -s -X GET \
"https://<burp-enterprise-host>/api/v1/scans" \
-H "Authorization: Bearer <api-token>" \
-H "Content-Type: application/json" \
| jq '.scans[] | {id: .id, name: .name, status: .status}'
# Export scan results as XML for a specific scan ID
curl -s -X GET \
"https://<burp-enterprise-host>/api/v1/scans/<scan-id>/report" \
-H "Authorization: Bearer <api-token>" \
-H "Accept: application/xml" \
-o burp-scan-results.xml
# Export scan results in HTML format (also parseable)
curl -s -X GET \
"https://<burp-enterprise-host>/api/v1/scans/<scan-id>/report" \
-H "Authorization: Bearer <api-token>" \
-H "Accept: text/html" \
-o burp-scan-results.html
Alternatively, export scan reports directly from the Burp Suite Enterprise web UI:
- Navigate to the completed scan in the Burp Suite Enterprise console
- Select Report → XML or HTML format
- Download and save the report file for import into DefectDojo
For CI/CD pipeline integration, trigger a scan via the API and wait for completion before exporting:
# Trigger a new scan for a target
SCAN_ID=$(curl -s -X POST \
"https://<burp-enterprise-host>/api/v1/scans" \
-H "Authorization: Bearer <api-token>" \
-H "Content-Type: application/json" \
-d '{
"name": "Pipeline scan - <app-name>",
"scan_configuration_id": "<config-id>",
"urls": ["https://staging.example.com"]
}' | jq -r '.id')
# Poll for scan completion
while true; do
STATUS=$(curl -s -X GET \
"https://<burp-enterprise-host>/api/v1/scans/${SCAN_ID}" \
-H "Authorization: Bearer <api-token>" \
| jq -r '.status')
if [ "$STATUS" = "succeeded" ] || [ "$STATUS" = "failed" ]; then
break
fi
sleep 30
done
# Export results
curl -s -X GET \
"https://<burp-enterprise-host>/api/v1/scans/${SCAN_ID}/report" \
-H "Authorization: Bearer <api-token>" \
-H "Accept: application/xml" \
-o burp-scan-results.xml
Step 2 — Import into DefectDojo
Use Burp REST API as the scan type for API-exported XML, or Burp Scan for UI-exported XML reports:
# For API-exported XML
curl -X POST https://<defectdojo-host>/api/v2/import-scan/ \
-H "Authorization: Token <your-api-token>" \
-F "scan_type=Burp REST API" \
-F "file=@burp-scan-results.xml" \
-F "engagement=<engagement-id>" \
-F "product=<product-id>" \
-F "active=true" \
-F "verified=false"
# For UI-exported XML reports
curl -X POST https://<defectdojo-host>/api/v2/import-scan/ \
-H "Authorization: Token <your-api-token>" \
-F "scan_type=Burp Scan" \
-F "file=@burp-scan-results.xml" \
-F "engagement=<engagement-id>" \
-F "product=<product-id>" \
-F "active=true" \
-F "verified=false"
Step 3 — Reimport for recurring scans
For applications scanned on a recurring cadence, use the reimport endpoint to update existing findings rather than accumulate redundant test records:
curl -X POST https://<defectdojo-host>/api/v2/reimport-scan/ \
-H "Authorization: Token <your-api-token>" \
-F "scan_type=Burp REST API" \
-F "file=@burp-scan-results.xml" \
-F "test=<test-id>"
DefectDojo marks findings absent from the new scan as resolved, creates records for new findings, and leaves previously false-positived or risk-accepted findings untouched.
Data Granularity: What Gets Imported
|
Field |
Source in Burp Suite Enterprise Output |
Notes |
|---|---|---|
|
Title |
issue-type/name |
Vulnerability class name e.g., "SQL injection", "Reflected cross-site scripting" |
|
Severity |
severity |
High, Medium, Low, Information |
|
Confidence |
confidence |
Certain, Firm, Tentative — Burp's confidence in the finding's accuracy |
|
CWE ID |
Derived from issue type |
DefectDojo maps Burp issue types to CWE where applicable |
|
CVE ID |
vulnerability-classifications/cve |
Where Burp maps the issue to a specific CVE |
|
Description |
issue-detail |
Burp's detailed description of the specific instance |
|
Background |
issue-background |
Explanation of the vulnerability class and its risk |
|
Remediation Detail |
remediation-detail |
Specific remediation guidance for this finding instance |
|
Remediation Background |
remediation-background |
General remediation guidance for the vulnerability class |
|
Affected URL |
path |
The specific URL where the vulnerability was found |
|
Host |
host |
The target host (scheme + hostname) |
|
HTTP Request |
request (in evidence) |
The exact HTTP request that triggered the vulnerability |
|
HTTP Response |
response (in evidence) |
The server response confirming the vulnerability |
|
References |
references |
Links to OWASP, CWE, PortSwigger research, and related resources |
|
Vulnerability Classifications |
vulnerability-classifications |
CWE, CVE, and OWASP category mappings |
|
Serial Number |
serial-number |
Burp's internal unique finding identifier |
Use Cases
In a CI/CD pipeline for a staging environment: Burp Suite Enterprise scans trigger automatically when a new build is deployed to staging. The pipeline polls the Burp API for scan completion, exports the XML report, and imports into DefectDojo. Security engineers triage new Critical and High findings before the staging build is promoted to production. Previously accepted findings — confirmed false positives or accepted low-risk items — don't block the pipeline or require re-triage, keeping deployment velocity intact while maintaining security review discipline.
For continuous scheduled scanning of production applications: Public-facing web applications are scanned weekly on a Burp Suite Enterprise schedule. Each scan reimports into DefectDojo, automatically resolving findings from URLs that are no longer vulnerable and surfacing new findings introduced by recent deployments. Security and engineering teams review the weekly diff in DefectDojo rather than comparing raw XML reports, with SLA tracking ensuring that new High severity findings are assigned within 24 hours of the scan completing.
For a web application portfolio security assessment program: A security team with responsibility for 40 web applications configures Burp Suite Enterprise to scan all 40 applications on a monthly rotation. DefectDojo aggregates findings across all products, giving the security team a ranked view of which applications carry the most unresolved High and Critical DAST findings, which have the oldest open issues, and which have clean scan results. This portfolio view drives risk-based resource allocation — deeper manual pen testing resources are directed at the applications with the most significant automated DAST findings.
During a pre-launch security review for a new application: A new web application is assessed with Burp Suite Enterprise as part of its launch readiness review. Scan results import into a DefectDojo engagement scoped to the launch milestone. Security and product teams triage findings collaboratively — Critical and High findings block the launch unless remediated or formally risk-accepted with documented rationale. The engagement record serves as the go/no-go security evidence artifact for the launch, with a clear record of every finding and every disposition decision made before the application went live.
For compliance evidence across PCI DSS in-scope applications: Applications processing cardholder data require regular application security testing evidence for PCI DSS compliance. Burp Suite Enterprise scans run quarterly (at minimum) against all in-scope applications. DefectDojo's engagement history — showing scan dates, finding counts, severity distributions, and remediation records — provides the structured DAST coverage evidence that a QSA examiner needs, organized by application and time period, without manual report compilation from Burp's console.
Operational Tips
- Use authenticated scan configurations for meaningful coverage: Unauthenticated Burp Suite Enterprise scans miss all vulnerabilities behind login flows — frequently the most sensitive and highest-risk parts of a web application. Configuring authenticated scan sessions using Burp's recorded login sequences or session handling rules is essential for producing DAST findings that reflect real application risk. Treat an unauthenticated scan result as incomplete rather than as a clean bill of health.
- Match scan scope deliberately to the application's attack surface: Burp Suite Enterprise's crawler will follow links wherever they lead unless scope is explicitly constrained. Define scope using URL prefix matching and explicit exclude rules to keep scans focused on the target application — avoiding time wasted crawling third-party resources, CDN content, or authentication providers that aren't part of your attack surface.
- Use Burp REST API scan type for API-exported reports: DefectDojo has two Burp parsers — Burp Scan for UI-exported XML and Burp REST API for API-exported XML. The formats are similar but not identical. Using the wrong parser may result in incomplete field mapping. When exporting via the API as part of an automated pipeline, always use scan_type=Burp REST API.
- Tune confidence thresholds for your triage workflow: Burp Suite Enterprise reports findings at Certain, Firm, and Tentative confidence levels. For high-volume applications, consider filtering Tentative confidence findings to inactive on import — they represent Burp's less certain detections and carry higher false positive rates. Review them in batch on a separate cadence rather than mixing them with Certain and Firm findings in the active triage queue.
- Create separate engagements for pipeline scans and scheduled scans: Pipeline-triggered scans (per deployment) and scheduled scans (weekly, monthly) have different cadences and purposes. Keeping them in separate DefectDojo engagements prevents finding counts from mixing across scan types and makes it easier to report separately on continuous pipeline coverage versus periodic deep scans.
- Leverage Burp's issue evidence in Jira tickets: When pushing Burp findings from DefectDojo to Jira, include the HTTP request and response from the finding's evidence in the ticket description. This is the single most useful artifact for a developer triaging a DAST finding — it eliminates the need to reproduce the issue from scratch and makes the vulnerability concrete rather than theoretical.
- Coordinate suppression between Burp Enterprise and DefectDojo: Burp Suite Enterprise supports scan-level false positive marking. Where possible, prefer managing false positive decisions in DefectDojo — the rationale is documented with an approver and expiration date, and the decision travels with the DefectDojo finding record rather than being tied to a specific Burp scan configuration.