MS Defender Integration with DefectDojo

Microsoft Defender Integration with DefectDojo

Microsoft Defender for Endpoint is Microsoft's endpoint security platform, and Microsoft Defender Vulnerability Management (MDVM) is the part of it that inventories software on onboarded devices and reports the CVEs affecting that software. Results are available in the Microsoft Defender portal and through the Defender REST API, including the machinesVulnerabilities endpoint (one record per device, software, and CVE) and the machines endpoint (device details such as operating system, IP addresses, and exposure level). DefectDojo imports JSON from these endpoints, and DefectDojo Pro can pull the same data directly through a connector.

Microsoft Defender Integration with DefectDojo

Microsoft Defender is already on every laptop and server we manage, so it is our most complete source of endpoint vulnerability data. Bringing those results into DefectDojo puts device CVEs alongside application and cloud findings, with owners, SLAs, and history. The Defender portal tells us what is vulnerable right now. DefectDojo tells us what was fixed, what is overdue, and which team is responsible, and it keeps that record across every export or sync.

Why Microsoft Defender Matters

Endpoint and server vulnerabilities are a large share of most organizations' exposure, and they are the findings that scanners outside the network see least clearly.

• Defender reports from an agent on the device, so coverage follows the device whether it is on the corporate network or not.
• Each record names the CVE, the vulnerable product and version, and the fixing KB where Microsoft publishes one.
• Device context such as operating system, RBAC group, risk score, and exposure level helps decide which machines to patch first.
• The volume is high. One CVE in a widely installed package can appear on hundreds of devices, which is exactly where deduplication, grouping, and SLA tracking help.

Advantages of This Integration

What we gained by routing Defender data through DefectDojo:

• Device CVEs in the same workflow as everything else. Endpoint findings get the same severity-based SLAs, assignment, risk acceptance, and Jira push as application findings.
• Device context on each Finding. When machine data is included, the description carries OS platform and version, health status, RBAC group, risk score, and exposure level, and the device's DNS name and IP addresses are added as endpoints.
• Reimport history. Reimporting a fresh export into the same Test closes device vulnerabilities that were patched and adds new ones.
• Scheduled sync with DefectDojo Pro. The Microsoft Defender connector reads MDVM data on a schedule and creates a Record per Defender device group, so imports stop depending on someone running an export.
• Volume control. The connector can import device groups in phases and can consolidate findings to one per CVE and software version per device group, with affected devices attached as endpoints.

How This Integration Works

Option 1: File import (Community Edition and DefectDojo Pro). DefectDojo uses the MSDefender Parser scan type, which accepts two inputs:

• A .json file saved from the Defender API api/vulnerabilities/machinesVulnerabilities endpoint. Each record becomes a Finding with the device's machine ID in the title.
• A .zip file you build yourself with two folders. Put one or more machinesVulnerabilities JSON files in vulnerabilities/ and the output of the api/machines endpoint in machines/. The parser joins the two on machine ID, so Findings get device names, OS details, and IP endpoints.

For very large or fast-changing environments, the DefectDojo docs recommend leaving machines/ empty for stability. Machine details are then skipped and only the machine ID is recorded.

Upload the file in the UI (Import Scan Results, then MSDefender Parser), or use the API:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" \
  -H "Authorization: Token $DD_API_TOKEN" \
  -F "scan_type=MSDefender Parser" \
  -F "file=@defender-export.zip" \
  -F "product_name=corporate-endpoints" \
  -F "engagement_name=Defender Weekly" \
  -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 "MSDefender Parser" \
  --report-path "./defender-export.zip" \
  --product-name "corporate-endpoints" \
  --engagement-name "Defender Weekly" \
  --auto-create-context

Option 2: Microsoft Defender connector (DefectDojo Pro). The connector authenticates as a Microsoft Entra ID app registration using client credentials. It needs the WindowsDefenderATP application permission Vulnerability.Read.All with admin consent, and a tenant license that includes the Defender vulnerability export APIs (for example Defender for Endpoint Plan 2 or MDVM Standalone).

1. Enter https://api.security.microsoft.com as the Location.
2. Enter the Tenant ID, Client ID, and Client Secret from the app registration.
3. Optionally list Device Groups to import, enable Consolidate Findings by Vulnerability, or set a Minimum Severity.

Each Defender device group becomes a Record, and devices outside any group are collected under Unassigned. Microsoft regenerates the snapshot the connector reads roughly every six hours. Use either the connector or file import for a given Asset, not both, to avoid duplicate Findings. Azure workloads covered by Defender for Cloud have their own separate Microsoft Defender for Cloud connector in DefectDojo Pro.

Data Granularity: What Gets Imported

The table describes the MSDefender Parser file import.

Use Cases

Patch compliance reporting: An IT security team imports Defender data weekly into one Test per device group and sets SLAs by severity. Leadership gets overdue Critical and High endpoint CVEs by team, and the Test history shows how quickly each Patch Tuesday was absorbed.

Large estates with DefectDojo Pro: A tenant with thousands of devices uses the connector's Device Groups allowlist to onboard a few groups at a time, and turns on consolidation so one CVE across 500 devices becomes one Finding with 500 endpoints instead of 500 Findings.

Restricted environments: Where an API connection from DefectDojo to Microsoft isn't approved, a scheduled job pulls the two Defender endpoints, builds the ZIP, and imports it through the API.

Correlating endpoint and application risk: Servers that host an application can be modeled in the same Asset as the application's code findings, so remediation planning for that service covers both the OS and the code.

Operational Tips

• Include the machines/ folder when you need endpoints and device names, and leave it empty when the machine list is too large or changes too quickly to join reliably.
• The parser decodes ZIP contents as ASCII and skips any file it can't decode or parse, logging a warning. If a ZIP imports fewer findings than expected, check the files for non-ASCII characters such as accented device names.
• Dedupe hashes the title and description, and the description includes the product version. A version change that still carries the CVE shows up as a new Finding.
• Choose one path per Asset. The connector is separate from the MSDefender Parser scan type, and the docs warn that running both on one Asset produces duplicate Findings.
• Enable consolidation before the connector's first Sync if you want it. Switching later closes the existing per-device findings and creates consolidated ones.
• Use connector severity overrides per device group, for example everything from production but only High and Critical from a lab group.