Automox Integration with DefectDojo

Automox Integration with DefectDojo

Automox is a cloud-native endpoint management platform that automates patching and configuration for Windows, macOS, and Linux devices through a lightweight agent. For each device it reports the packages with patches awaiting installation, along with their CVEs, a CVE score, and whether a reboot is needed. DefectDojo imports that awaiting-patch data as a JSON file, or pulls it with the DefectDojo Pro Automox connector.

Automox Integration with DefectDojo

We patch through Automox, and the security question we kept getting was simple: which known vulnerabilities are still waiting on a patch, on which machines, and for how long? Importing Automox's missing-patch list into DefectDojo answers it. Each missing patch becomes a Finding with its CVEs, score, and device, measured against the same SLAs as our scanner findings. The file parser and the Pro connector produce matching findings under one scan type, so we can switch between them without duplicates.

Why Automox Matters

Patching is where most vulnerability remediation actually happens on endpoints, and Automox knows what is still outstanding.

• It reports from an agent on the device, so the missing-patch list reflects what is actually installed.
• Each package lists the CVEs the patch fixes, which links patch work directly to vulnerability risk.
• It flags patches that require a reboot, which is often the real reason a patch sits unapplied.
• Automox shows patch status, but security teams also need SLA tracking, exceptions, and reporting next to their other findings.

Advantages of This Integration

• Patch coverage as findings. Each missing patch is a Finding titled Missing patch: <name>, with the mitigation telling the owner to install the available version.
• CVE context. CVE IDs from the package become vulnerability IDs, and Automox's cve_score is stored as the CVSS v3 score, so findings can be filtered and prioritized by CVE.
• Device context. When the export includes the device list, each finding names its device and operating system, and is tagged with the OS family.
• Reboot visibility. Patches that need a reboot are tagged requires-reboot, which makes it easy to plan maintenance windows.
• File and API agree. The parser mirrors the connector field for field under the scan type Automox Scan, so file imports and connector Syncs deduplicate against each other.

How This Integration Works

Option 1: File import. Use this path when you can't grant Automox API credentials. Automox reports the patch and its device through two different endpoints, so the export carries both lists, joined on the package's server_id. The packages list can be named packages, data, or results, or the file can be a bare array of packages (which is what the packages endpoint returns). The device list can be named devices or servers. A package whose device is missing from the export is still imported, just without the device lines.

In the UI, open an Engagement, choose Import Scan Results, select Automox Scan, and upload the JSON. 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=Automox Scan" 
  -F "file=@automox-patches.json" 
  -F "product_name=workstations" 
  -F "engagement_name=Automox" 
  -F "auto_create_context=true"

With DefectDojo Pro, run Universal Importer from a scheduled job:

universal-importer import 
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" 
  --scan-type "Automox Scan" 
  --report-path "./automox-patches.json" 
  --product-name "workstations" 
  --engagement-name "Automox" 
  --auto-create-context

Option 2: Automox connector (DefectDojo Pro). Create an API key under Settings, API in the Automox console. In the DefectDojo Pro UI, add the Automox connector, enter https://console.automox.com/api as the Location, paste the API key, and optionally set a Minimum Severity. The connector creates a Record for each Automox device group, carrying the patches awaiting installation on the devices in that group.

A finding here is a missing patch, not a scanner result. Use this integration to track patch coverage, and pair it with a vulnerability scanner if you also need findings for issues no patch addresses.

Data Granularity: What Gets Imported

Use Cases

Patch SLAs: Security sets an SLA for Critical and High missing patches. IT keeps patching through Automox, and each Sync or reimport shows which patches were applied in time and which breached.

Maintenance planning: An operations lead filters on the requires-reboot tag to see which outstanding patches are waiting on a restart and schedules the maintenance window for those device groups.

Exceptions with expiry: A device running a line-of-business app can't take a particular update yet. Its finding is risk-accepted with an expiration date and a note, so the exception gets reviewed instead of forgotten.

Air-gapped or restricted setups: A team that can't connect an outside system to the Automox API exports packages and devices to one JSON file and imports it, keeping the same scan type the connector uses.

Operational Tips

• Include the device list in file exports. Without it, findings still import, but they lose the device name, OS, and OS-family tag.
• Automox severities of none, unknown, and no_known_cves all become Info. Use minimum_severity to keep those out if you only want patches tied to known CVEs.
• Reimport into the same Test, or let the connector Sync on schedule, so patches that were installed drop out and are mitigated.
• Rows without a numeric id are skipped. If counts look low, check the export for missing IDs.
• Tag imports with the device group or business unit to make reporting by owner straightforward.
• Remember that already-installed packages can appear in an export. Their findings import without the "Patch available but not installed" status line.