Wazuh Integration with DefectDojo

Wazuh Integration with DefectDojo

Wazuh is an open source security platform for threat detection, integrity monitoring, incident response, and compliance, built around agents installed on servers, workstations, and cloud workloads. Its vulnerability detection module compares each agent's installed packages against vulnerability feeds and records the CVEs that apply. From Wazuh 4.8 onward, those detections are stored in the Wazuh Indexer (based on OpenSearch) in the wazuh-states-vulnerabilities-* index; earlier versions exposed them through the Wazuh server API. DefectDojo can import either form as JSON, and DefectDojo Pro can read the Indexer directly with a connector.

Wazuh Integration with DefectDojo

We already had Wazuh agents on most of our fleet for detection and file integrity monitoring, so its vulnerability detection gave us host CVE data at no extra deployment cost. What Wazuh does not do well is the remediation side: assigning a CVE on a set of hosts to the team that owns them and holding that team to a deadline. Sending Wazuh results into DefectDojo turns each package CVE on each agent into a Finding on the right Asset, with an owner, an SLA, and a status history that persists after the package is upgraded.

Why Wazuh Matters

Host package vulnerabilities are a steady source of risk, and an agent that is already deployed is the cheapest way to see them.

• Wazuh agents report installed packages continuously, so vulnerability data stays current without scheduling network scans.
• Detections name the package, the installed version, the CVE, and a CVSS score, which is what a patch team needs to prioritize.
• The same platform covers Linux, Windows, and macOS agents, so one data source spans a mixed fleet.
• Wazuh's dashboards show the current state, but they are not built to track who is fixing which CVE and by when.

Advantages of This Integration

What we gained by sending Wazuh data through DefectDojo:

• Per-agent findings. Each Finding carries the agent name (or, for older exports without a name, the agent IP) as its endpoint, so a CVE on 200 hosts shows exactly where it applies.
• Package context. Component name and version come from the affected package, which lets DefectDojo group and report on vulnerable components across Assets.
• Severity and CVSS. Wazuh severities map to DefectDojo's scale and the CVSS v3 score is carried over, so host CVEs fall under the same SLA rules as everything else.
• Scheduled sync with DefectDojo Pro. The Wazuh connector reads the Indexer on a schedule, creates a Record per agent, and keeps Findings current without file exports.
• Lifecycle on reimport. For file imports, reimporting into the same Test mitigates CVEs that disappeared after patching and reactivates any that return.

How This Integration Works

There are two ways to get Wazuh results into DefectDojo.

Option 1: JSON file import (Community Edition and DefectDojo Pro). Use the Wazuh scan type. The parser recognizes two layouts automatically:

• Wazuh 4.8 and later: an Indexer search response with a hits.hits array, each hit holding agent, package, and vulnerability objects.
• Wazuh 4.7 and earlier: a server API response with data.affected_items. DefectDojo's documentation also points to a community exporter script that fetches findings per agent group and includes host names.

For 4.8 and later, query the vulnerability index on the Wazuh Indexer and save the response:

curl "https://wazuh-indexer.example.com:9200/wazuh-states-vulnerabilities-*/_search?size=10000" \
  -u "$WAZUH_INDEXER_USER:$WAZUH_INDEXER_PASSWORD" \
  -o wazuh-vulns.json

Then import the file in the UI (Engagement, Import Scan Results, scan type Wazuh), or through the API:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" \
  -H "Authorization: Token $DD_API_TOKEN" \
  -F "scan_type=Wazuh" \
  -F "file=@wazuh-vulns.json" \
  -F "product_name=linux-servers" \
  -F "engagement_name=Wazuh Vulnerability Detection" \
  -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 "Wazuh" \
  --report-path "./wazuh-vulns.json" \
  --product-name "linux-servers" \
  --engagement-name "Wazuh Vulnerability Detection" \
  --auto-create-context

Large fleets produce large files. If an export exceeds the default 100MB upload limit, raise DD_SCAN_FILE_MAX_SIZE on self-hosted instances.

Option 2: Wazuh connector (DefectDojo Pro). The connector reads the wazuh-states-vulnerabilities-* index directly, so it works with Wazuh 4.8 and later. Configure it with:

1. The Wazuh Indexer base URL, including scheme and port (the Indexer listens on 9200 by default), in the Location field. For Wazuh Cloud, use the Indexer endpoint from the Wazuh Cloud console, not the dashboard URL.
2. An Indexer user with read access to the vulnerability index in Username and Password. A dedicated user for DefectDojo is recommended.
3. Optionally, a Minimum Severity to skip lower-severity Findings.

DefectDojo creates a Record for each Wazuh agent and imports that agent's CVEs on a schedule. Vulnerability detection must be enabled in Wazuh so the index is populated.

Data Granularity: What Gets Imported

The table describes the file import.

Use Cases

For patch management: An infrastructure team reimports the Wazuh export weekly into a Test per server group. After each patch window, DefectDojo shows which CVEs closed on which hosts and which agents were missed.

For a mixed fleet with DefectDojo Pro: The connector keeps every agent's CVEs in sync automatically, with one Record per agent mapped to the Asset that owns it, so ownership follows the host rather than one large Engagement.

For compliance reporting: Wazuh is often deployed for PCI DSS or similar controls. With its CVEs in DefectDojo, discovery dates, SLA status, and closure dates are available as evidence without screenshots.

Alongside network scanning: Agent-based CVEs from Wazuh sit next to network scanner results on the same Asset, so a team can see where both sources agree and where one sees hosts the other misses.

Operational Tips

• Split exports by agent group when you can. The 4.7 API export puts every vulnerability into one file, while the exporter script DefectDojo's docs reference produces one file per group, which maps cleanly to separate Engagements or Assets.
• A single Indexer search returns at most size hits, and OpenSearch caps that at 10,000 by default. Check the hits.total value in the response If your fleet has more, combine the pages into one hits.hits array before reimporting, because reimporting a single partial page mitigates Findings that only appear on the other pages.
• The parser sets a unique ID from the tool on every Finding, but the "Wazuh" scan type falls back to the legacy deduplication algorithm. Self-hosted administrators can set DD_DEDUPLICATION_ALGORITHM_PER_PARSER to use unique_id_from_tool for "Wazuh" if they want deduplication on that ID.
• On 4.7 exports, CVEs with no available fix ("Package unfixed") are skipped, so they will not appear in DefectDojo until Wazuh reports a fix.
• Set minimum_severity, or the connector's Minimum Severity, if Low and Info package CVEs would bury the team.
• Prefer the connector on DefectDojo Pro with Wazuh 4.8 or later. It removes the export step and the file size concerns entirely.