OWASP Nettacker Integration with DefectDojo
OWASP Nettacker Integration with DefectDojo
OWASP Nettacker is an open source, Python-based framework for automated information gathering and security assessment, maintained as an OWASP project. It is organized into modules: some discover things about a target, such as open ports, served paths, or subdomains, and others check a target for a specific known vulnerability, often a named CVE. Nettacker can export reports in HTML, JSON, CSV, and plain text; DefectDojo imports the JSON report.
OWASP Nettacker Integration with DefectDojo
We run OWASP Nettacker in authorized assessments of our own infrastructure because its modules cover both discovery and specific vulnerability checks in one tool. Importing its JSON report into DefectDojo turns each module result into a Finding with a host and port endpoint on the Asset being assessed. Discovery results land as Info, vulnerability module hits land as Medium with the CVE attached where the module names one, and a reimport of the next assessment closes what is no longer reported.
Why OWASP Nettacker Matters
A security team assessing its own network usually needs two answers: what is exposed, and whether any of it is affected by known issues. Nettacker's module design addresses both.
- Scan modules report observations about a target, such as which ports answer or which paths are served.
- Vulnerability modules check for specific known issues, and many are named after the CVE they test for.
- It is an OWASP project with open source code, so teams can see what each module does.
- Its report records what each module saw, but it carries no severity, no ownership, and no history between runs.
Advantages of This Integration
Running Nettacker results through DefectDojo gave us:
- Severity where the report has none. Nettacker records events without rating them. The parser assigns Info to scan module results and Medium to modules whose names end in
_vuln, so vulnerability hits stand out from discovery noise. - CVE IDs recovered from module names. Nettacker names its CVE checks after the CVE but does not repeat the identifier as a field. The parser extracts it from the module name and stores it as the Finding's vulnerability ID.
- Host and port endpoints. Each event's target and port become an endpoint, so findings can be reported per host alongside the Asset's other endpoints.
- Clean rescans. DefectDojo hashes Nettacker findings on title and endpoints, and the parser leaves the run-specific scan ID and date out of the description, so reassessing an unchanged target does not import every event again.
- Repeats collapsed. One Finding is created per target, module, and port, even when a module reports the same event more than once in a run.
- Lifecycle on reimport. Reimporting the next assessment into the same Test mitigates events that are no longer reported, adds new ones, and reactivates any that return.
How This Integration Works
DefectDojo reads Nettacker reports with the Nettacker Scan scan type.
1. Write a JSON report. Run Nettacker with the modules your assessment calls for, against targets you own or are authorized to test, and add -o with a .json file name (for example -o nettacker-report.json) to write the report. The JSON report is a flat array of events.
2. Import it. In the UI, open the Engagement, choose Import Scan Results, select Nettacker Scan, and upload the file. For automation, the API works in Community Edition and DefectDojo Pro:
curl "https://YOUR_INSTANCE/api/v2/import-scan/"
-H "Authorization: Token $DD_API_TOKEN"
-F "scan_type=Nettacker Scan"
-F "file=@nettacker-report.json"
-F "product_name=corporate-network"
-F "engagement_name=Quarterly Assessment"
-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 "Nettacker Scan"
--report-path "./nettacker-report.json"
--product-name "corporate-network"
--engagement-name "Quarterly Assessment"
--auto-create-context
3. Reimport later assessments. Send the next report for the same scope to /api/v2/reimport-scan/ against the same Test, so resolved events are mitigated.
A run in which no module produces an event writes an empty file. The parser treats that as zero findings rather than an error.
Data Granularity: What Gets Imported
| DefectDojo Field | Source in Nettacker Report | Notes |
|---|---|---|
| Title | module_name, target, port |
"module fired against host:port" for vulnerability modules; "module: host:port" otherwise |
| Severity | Module name | Names ending in _vuln become Medium; all other modules become Info |
| Description | Module, target, port, event summary | Scan ID and date deliberately excluded |
| Vulnerability ID from tool | module_name |
Nettacker's own identifier for the check |
| Vulnerability IDs | CVE pattern in the module name | Set only when the module name contains a CVE |
| Endpoint | target and port |
Host and port, with no scheme |
| Finding type | Dynamic | All Nettacker findings are marked dynamic |
| Deduplication | Hashcode | Title, endpoints |
Nettacker reports no CWE, remediation text, or references, so those fields are left empty.
Use Cases
For periodic internal assessments: A security team runs an approved Nettacker profile against its internal ranges each quarter and reimports into one Test per scope. Vulnerability module hits are Medium Findings with CVEs attached, and the discovery results give the context around them.
When a new CVE check is relevant: After an advisory for a product the organization runs, the team runs the matching Nettacker vulnerability module against its own hosts. Any hit becomes a Finding with the CVE, which can be searched across Assets with results from other tools.
Feeding remediation: Medium Findings from vulnerability modules are assigned to the host owners and pushed to Jira, and the next assessment's reimport confirms whether each one was fixed.
For audit history: Each Finding keeps its discovery and mitigation dates, which shows how long an exposure existed without keeping old report files around.
Operational Tips
- Run Nettacker only against systems you own or have written authorization to assess, and keep the module selection consistent between runs.
- Keep one Test per scope and module profile. Reimporting a report from a different module set mitigates Findings that simply were not checked.
- Only module names ending in
_vulnare treated as vulnerabilities. Review other module types, such as credential-testing modules, individually and adjust severity during triage where your policy requires it. - A
_vulnmodule that names no CVE still imports as Medium without a vulnerability ID. Read the event summary in the description for detail. - Info discovery results can be numerous. Use
minimum_severity=Mediumon import if you only want vulnerability module hits, or keep them and filter in DefectDojo. - Tag imports with the assessment scope (for example
tags=internal,q3) so results from different scopes stay easy to separate.