Outpost24 Integration with DefectDojo
Outpost24 Integration with DefectDojo
Outpost24 is a cybersecurity company based in Sweden that sells vulnerability management and attack surface products. Its network scanning comes in two forms: OUTSCAN, a cloud-hosted scanner for internet-facing systems, and HIAB, an on-premises scanner for internal networks. Both scan hosts and their exposed services for known vulnerabilities and misconfigurations, and both can export reports from Reporting Tools in several formats, including XML, which is the format DefectDojo imports.
Outpost24 Integration with DefectDojo
We use Outpost24 to scan our external perimeter and internal server ranges, and we import the XML reports into DefectDojo so infrastructure findings go through the same process as application findings. Each detail in the report becomes a Finding with its host, port, and service attached, a severity derived from CVSS, and the vendor's solution text as Mitigation. DefectDojo assigns those Findings to the team that owns the hosts, tracks them against SLAs, and keeps the history when the next scan shows what was patched.
Why Outpost24 Matters
Network-level vulnerabilities are still a common way in. Unpatched services, weak TLS configuration, and exposed management interfaces show up in breach reports year after year.
- OUTSCAN looks at your perimeter from the outside, which is how an attacker sees it.
- HIAB covers internal ranges that a cloud scanner can't reach, so the same tool family covers both views.
- Reports include CVSS v2 and v3 scores, CVE references, and solution text for each detail.
- A scan report is a point-in-time list. Without a tracking platform, it is hard to know which findings are new, which were fixed, and which have been open past their deadline.
Advantages of This Integration
What we get from routing Outpost24 results through DefectDojo:
- CVSS-based severity. The parser prefers the CVSS v3 score, falls back to CVSS v2, and maps the score to standard bands, so severities line up with other scanners under the same SLA rules.
- Host and service context. Each Finding carries the scanned IP or hostname, the port, and the service name as its endpoint, so it can be routed to the team that owns that system.
- Reimport lifecycle. Reimporting a new report into the same Test mitigates findings that no longer appear, adds new ones, and reactivates any that come back.
- Infrastructure next to applications. Outpost24 Findings can sit on the same Asset as DAST and SCA results for a service, which gives a fuller picture of what is exposed.
- Standard triage tools. Findings can be assigned, risk-accepted with an expiration date, marked false positive, or pushed to Jira.
How This Integration Works
DefectDojo imports Outpost24 results with the Outpost24 Scan scan type.
1. Export an XML report. In OUTSCAN or HIAB, open Reporting Tools, select the targets, choose Export Report, and pick XML as the format with the Vulnerability report type. The parser reads the detaillist section of the report, so use a report level that includes per-finding details.
2. Import it. In the UI, open the Engagement, choose Import Scan Results, select Outpost24 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=Outpost24 Scan" \
-F "file=@outpost24-report.xml" \
-F "product_name=external-perimeter" \
-F "engagement_name=Monthly Network Scan" \
-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 "Outpost24 Scan" \
--report-path "./outpost24-report.xml" \
--product-name "external-perimeter" \
--engagement-name "Monthly Network Scan" \
--auto-create-context
3. Reimport on each scan cycle. Send later reports for the same targets to /api/v2/reimport-scan/ against the same Test, so patched findings are closed and the open list stays current.
Data Granularity: What Gets Imported
The parser creates one Finding per detail element in the report.
| DefectDojo Field | Source in Outpost24 XML | Notes |
|---|---|---|
| Title | name |
The vulnerability name |
| Severity | cvss_v3_score, else cvss_score, else risk |
Under 4 Low, under 7 Medium, under 9 High, 9+ Critical. Risk 0 to 3 maps Low to Critical |
| Severity Justification | CVSS score and cvss_vector_description |
The plain-language CVSS v2 vector description |
| Description | description |
Vendor description of the issue |
| Mitigation | solution |
Vendor solution text |
| Impact | information |
Additional detail from the scan |
| URL | Reference of type "solution" | Link to the vendor solution, when present |
| Vulnerability IDs | cve/id |
First CVE on the detail |
| Endpoint | ip, portinfo/service, portinfo/portnumber |
Host, service as protocol, and port; a non-numeric port becomes 0 |
| Finding type | Not set by parser | DefectDojo's default (dynamic) applies |
| Deduplication | Legacy algorithm | No per-scanner config; hash falls back to title, CWE, line, file path, description |
CWE, CVSS vectors, and the report's host and port summary lists are not imported. Severity Info is never assigned, because the lowest band is Low.
Use Cases
For perimeter monitoring: A team runs OUTSCAN monthly against its public IP ranges and reimports each report into one Test per range. New exposures appear as new Findings, and anything patched since the last cycle is mitigated automatically.
For internal patch programs: HIAB scans of data center subnets are imported into Assets per business unit. Infrastructure owners see their own Findings with host and port detail, and security leads track SLA compliance across units.
During incident response: When a new CVE in a common service is announced, analysts filter DefectDojo by vulnerability ID to see which hosts reported it in the latest scans, instead of rerunning reports in the scanner.
For audits and PCI-style requirements: DefectDojo keeps scan dates, Finding status, and closure dates for each host, which supports evidence requests for regular network scanning and remediation.
Operational Tips
- Expect no Info Findings. Low-scoring details and those with risk 0 arrive as Low, so use
minimum_severityor filters if informational checks would flood the queue. - When a detail has both CVSS v3 and v2 scores, severity follows v3, but the justification text describes the v2 vector. Read the score, not just the prose, when reviewing.
- Keep target groups stable between scans and reimport into the same Test. Changing scope looks like fixed Findings on reimport, because missing hosts drop out of the report.
- Because this scan type uses the Legacy algorithm, reimport matches on title and severity. A severity change in Outpost24 data between scans can produce a new Finding, so review mitigated and new pairs with the same title.
- Tag imports with the scanner and scope (for example
tags=outscan,dmz) when both OUTSCAN and HIAB feed the same Asset. - Risk-accept findings on systems scheduled for decommissioning, with an expiration date that matches the shutdown plan.