Naabu Integration with DefectDojo

Naabu Integration with DefectDojo

Naabu is an open source port scanner written in Go by ProjectDiscovery. It checks which TCP ports, and with the right options UDP ports, answer on a host, and it can note whether an open port speaks TLS. Naabu is often used in reconnaissance and attack surface workflows alongside other ProjectDiscovery tools. With -json it writes JSON Lines output, one object per line, which is what DefectDojo imports.

Naabu Integration with DefectDojo

We use Naabu for scheduled port checks on our internet-facing hosts because it is a single binary that is easy to drop into a pipeline. What we were missing was memory: each run was a fresh list, and nobody could say which ports were new. Importing Naabu output into DefectDojo records every open port as an Info Finding with a host and port endpoint on the owning Asset, and reimporting the next run shows exactly which ports opened or closed.

Why Naabu Matters

Unexpected listening services are one of the most common ways exposure grows without anyone noticing. A port scan is the simplest way to see what is actually reachable.

• It is fast and lightweight enough to run on a schedule or on every infrastructure change.
• It reports the host name and the address it resolved to, which helps when several names point at the same machine.
• It can record whether a port speaks TLS, which is a useful first signal about the service behind it.
• Naabu cannot tell you whether a port should be open. That depends on what the host is for, which is context a vulnerability management platform holds.

Advantages of This Integration

What we get from importing Naabu into DefectDojo:

• Repeat lines collapsed. Naabu reports the same open port once per scan pass, so a single run can list each port twice. The parser keys on host, port, and protocol, so each port imports once.
• Ports as endpoints. Each open port becomes an endpoint built from host and port, which can be searched and reported on with the rest of the Asset's endpoints.
• Stable deduplication. DefectDojo hashes Naabu findings on title and endpoints. The description, which holds timestamps, is left out, so a rescan of an unchanged host does not import every port again.
• Change detection. Reimporting into the same Test mitigates ports that closed, adds new ones, and reactivates any that came back.
• Ownership. Findings land on the Asset responsible for the host, where they can be assigned, annotated, or sent to Jira when a port needs closing.
• Context for deeper testing. Open ports sit beside DAST and vulnerability scanner findings for the same Asset, which helps decide where to test next.

How This Integration Works

DefectDojo reads Naabu output with the Naabu Scan scan type.

1. Write JSON Lines output. Use -json and capture standard output. Only scan hosts you own or are authorized to test:

naabu -host app.example.com -p 80,443,8080 -json > naabu.json

Capturing standard output matters: Naabu's -o option writes nothing at all when no port is open, while a redirected stdout always produces a file, empty or not.

2. Import it. In the UI, open the Engagement, choose Import Scan Results, select Naabu Scan, and upload the file. 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=Naabu Scan" 
  -F "file=@naabu.json" 
  -F "product_name=public-web" 
  -F "engagement_name=Port Monitoring" 
  -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 "Naabu Scan" 
  --report-path "./naabu.json" 
  --product-name "public-web" 
  --engagement-name "Port Monitoring" 
  --auto-create-context

3. Reimport each run. Send later scans of the same hosts to /api/v2/reimport-scan/ against the same Test, so closed ports are mitigated and new ones stand out.

The parser reads the file line by line. If it is handed a JSON array instead of JSON Lines, it raises an error that says which format it expected.

Data Granularity: What Gets Imported

Naabu output contains no service versions or vulnerability data, so no CVE, CWE, or mitigation fields are set.

Use Cases

For external exposure monitoring: A team runs Naabu nightly against its public hostnames and reimports into one Test per environment. New Info Findings each morning are the ports that opened since the previous run, which is a short list to check against planned changes.

After infrastructure changes: When a new load balancer or security group rule goes live, a Naabu run and reimport confirms that only the intended ports answer, and records the result against the Asset.

In a reconnaissance pipeline: Teams that chain ProjectDiscovery tools import Naabu results alongside the findings from later stages, so the open ports that led to each issue are visible on the same Asset.

For audit history: Each port Finding keeps its discovery and mitigation dates, which shows how long a service was exposed without digging through old output files.

Operational Tips

• Keep one Test per host group and reimport into it. A new Test per scan works, but you lose the opened and closed history.
• All Naabu Findings are Info, so severity-based SLAs will not trigger. Review new Findings after each reimport, or raise severity on ports that should never be public.
• Keep the port list consistent between runs. Scanning fewer ports makes the missing ones look closed and mitigates them on reimport.
• Naabu resolves targets itself. If DNS is unusual in your environment, scan by IP so the run does not fail to find targets.
• A SYN scan needs raw socket privileges. In unprivileged CI runners, use Naabu's connect scan option instead.
• Tag imports with the environment or scan profile (for example tags=external,nightly) so different sweeps stay easy to filter.