Nikto Integration with DefectDojo

Nikto Integration with DefectDojo

Nikto is an open source web server scanner created by Chris Sullo and published through CIRT.net, with its source on GitHub at sullo/nikto. It sends a large set of requests to a web server to identify dangerous or default files, outdated server software, version-specific problems, and server configuration issues such as risky HTTP methods or missing headers. Nikto writes reports in several formats, including XML and JSON, and DefectDojo imports both.

Nikto Integration with DefectDojo

Nikto is the quick check we run against every web server we stand up, because it is free, fast, and catches the leftovers that slip through deployment: default files, verbose banners, directory indexing. Its output on its own is a long text list with no severity. Imported into DefectDojo, each item becomes a Finding with an endpoint for the affected host and path, deduplicated within the scan, and tracked to closure when the next scan comes back clean.

Why Nikto Matters

Web server hygiene problems are rarely exotic, but they are common, easy to exploit, and easy to miss in code review because they live in configuration.

• Nikto tests for thousands of known dangerous files and programs and for outdated versions of common servers.
• It checks server-level settings such as allowed HTTP methods, headers, and default content that application scanners often ignore.
• It runs anywhere Perl runs and needs no license, so it fits into pipelines and ad hoc checks alike.
• Nikto does not grade severity and does not remember previous scans. A platform has to supply both.

Advantages of This Integration

What we gained by sending Nikto results through DefectDojo:

• Grouped results. Within a JSON report, items with the same message and severity are merged into one finding with every affected path attached as an endpoint. XML items with identical details are merged the same way.
• A baseline severity. Nikto assigns none, so the parser sets Info by default and raises items with an OSVDB reference to Medium, which gives a starting point for SLAs.
• Lifecycle on reimport. Reimporting the next scan into the same Test mitigates items that disappeared, adds new ones, and reactivates any that come back after a redeploy.
• Triage that sticks. Nikto produces noise on some servers. Marking items as false positives in DefectDojo keeps them out of future metrics for that Test.
• Context next to other DAST results. Nikto findings sit on the same Asset as deeper web application scans, and can be assigned or pushed to Jira like any other finding.

How This Integration Works

DefectDojo imports Nikto results with the Nikto Scan scan type. The parser accepts three layouts and chooses by file extension: the older XML format, the newer XML format (with the niktoscan wrapper and nxvmlversion="1.2"), and JSON.

1. Run Nikto and save the report. Use -output with -Format to choose the format:

nikto -h https://staging.example.com -output nikto.json -Format json

or, for XML:

nikto -h https://staging.example.com -output nikto.xml -Format xml

The file name must end in .json or .xml. Other extensions fail with an unknown file format error.

2. Import it. In the UI, open the Engagement, choose Import Scan Results, select Nikto Scan, and upload the file. For automation, use the API in Community Edition or DefectDojo Pro:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" \
  -H "Authorization: Token $DD_API_TOKEN" \
  -F "scan_type=Nikto Scan" \
  -F "file=@nikto.json" \
  -F "product_name=marketing-site" \
  -F "engagement_name=Web Server Checks" \
  -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 "Nikto Scan" \
  --report-path "./nikto.json" \
  --product-name "marketing-site" \
  --engagement-name "Web Server Checks" \
  --auto-create-context

3. Reimport on later scans. Send subsequent reports to /api/v2/reimport-scan/ against the same Test, and keep using the same output format so titles stay consistent.

Data Granularity: What Gets Imported

Use Cases

After every deployment: A pipeline runs Nikto against the newly deployed environment and reimports into the Test for that host. Configuration regressions, such as a debug file shipped to production, show up as new findings within minutes.

Across a fleet of web servers: An infrastructure team running 60 web servers imports each host's Nikto report into the owning Asset. A single filtered view in DefectDojo shows which hosts still expose default content or outdated server versions.

As a first pass before deeper testing: Security teams run Nikto before a full DAST scan or pentest. Clearing the Nikto findings first lets the deeper test spend its time on application logic.

For legacy systems: Older servers that cannot be patched quickly get Nikto findings risk-accepted with an expiration date, so the exception is documented and comes back for review.

Operational Tips

• Set severity during triage. Nikto has no severity model, and the Info and Medium values come from whether an OSVDB reference exists, not from impact. OSVDB has been offline since 2016, so treat that rule as a rough heuristic.
• Pick one format and stay with it. JSON and XML produce different titles for the same item, so switching formats creates new findings on reimport.
• Prefer JSON if you want the references field filled; the XML parser does not set it.
• Use -Tuning and other Nikto options to skip test categories you do not need rather than marking the same results as false positives every run.
• Scan one host per JSON report. The JSON parser reads a single host object (or a list holding exactly one), so a multi-host JSON file will not import cleanly. Import each virtual host into its own Test.
• Check the endpoint list before closing a merged finding. One finding can cover many paths, and a fix on one path does not mean the others are clean until a rescan confirms it.
• Tag imports with the environment (for example tags=staging) so pre-production results stay separate from production.