Dragos Integration with DefectDojo

Dragos Integration with DefectDojo

Dragos is an industrial cybersecurity company, and the Dragos Platform is its OT security product for industrial environments. It provides asset visibility, vulnerability management, and threat detection for operational technology and industrial control systems, matching the devices it discovers against vulnerability advisories, including Dragos's own. Deployments are organized around SiteStore servers, and vulnerability detections are available through the Dragos API as JSON, which DefectDojo can import as a file or pull with the DefectDojo Pro connector.

Dragos Integration with DefectDojo

Our OT team runs Dragos, and our IT and application security work lives in DefectDojo. Bringing Dragos detections into DefectDojo means a vulnerable PLC firmware version gets an owner, a status, and an SLA in the same place as a vulnerable web server, while keeping the context OT engineers need: which device, which zone, which Purdue level, and whether the flaw is known to be exploited. On DefectDojo Pro, the connector syncs each OT zone on a schedule. Sites that are too isolated for an API connection can export the data and import a file, and both routes deduplicate against each other.

Why Dragos Matters

OT vulnerabilities are handled differently from IT ones. Patching often waits for a maintenance window or a planned outage, and the cost of a mistake is physical.

• Dragos inventories devices that IT scanners cannot safely touch, and reports what is vulnerable on each one.
• Its advisories and exploitability intelligence help decide which flaws must be handled in the next window and which can wait.
• Purdue level and zone information shows how close a vulnerable device sits to the physical process.
• OT networks are frequently air-gapped, so a security program needs a way to move findings out without an API connection.

Advantages of This Integration

What running Dragos detections through DefectDojo gives a combined IT and OT program:

• One scan type for file and API. The parser uses Dragos Scan, the exact string the Dragos connector reports, so exported files and connector syncs produce one set of findings.
• Per-device identity. Each finding's unique ID combines the Dragos vulnerability ID and asset ID, so the same advisory on two devices stays two findings. In OT, those two devices may sit at different Purdue levels.
• Portable severity. Severity comes from the CVSS base score when present, so OT findings line up with the rest of your SLA rules. Dragos's own 0 to 5 scale is used only when there is no score.
• OT context without regrading. Active exploitation, public proof of concept, remote exploitability, and the Dragos risk score are recorded in Severity Justification rather than used to move the severity.
• Device details in every finding. Vendor, model, firmware, zone, Purdue level, and IP addresses are written into the description, and vendor, model, zone, and type become tags.
• Platform workflow. Findings can be assigned, risk-accepted until the next outage, pushed to Jira, and reported on next to IT findings.

How This Integration Works

Both routes use the Dragos Scan scan type. It does not follow the Vendor - Connectors Import naming used by many other connector scan types, so copy it exactly.

Option 1: File import (Community Edition and DefectDojo Pro). This path exists for organizations that cannot grant Dragos API credentials, which in OT is common. Save the JSON response from the Dragos detections endpoint, which is paged as an object with a content list. The parser also accepts a bare array, or an object naming the list detections, data, or results. Each detection carries the asset it was found on, so one list is the whole export and nothing needs to be joined.

In the UI, open the Engagement, choose Import Scan Results, select Dragos Scan, and upload the file. To automate it:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" 
  -H "Authorization: Token $DD_API_TOKEN" 
  -F "scan_type=Dragos Scan" 
  -F "file=@dragos-detections.json" 
  -F "product_name=plant-north-ot" 
  -F "engagement_name=OT Vulnerabilities" 
  -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 "Dragos Scan" 
  --report-path "./dragos-detections.json" 
  --product-name "plant-north-ot" 
  --engagement-name "OT Vulnerabilities" 
  --auto-create-context

Option 2: Dragos connector (DefectDojo Pro). Create an API key in Dragos under Admin, Users, Add New API Key, with the asset:read, detection:read, and vulnerability:read privileges. The secret is shown only once, so capture it when the key is generated. In the DefectDojo Pro UI:

1. Enter your Dragos SiteStore host in the Location field.
2. Enter the key ID in the API Key ID field and the secret in the API Key Secret field.
3. Optionally set a Minimum Severity.

DefectDojo creates a Record for each OT zone, since one SiteStore deployment represents one site and the zone is the meaningful grouping within it. Each Record carries the vulnerabilities detected on that zone's assets, and you map it to a DefectDojo Asset.

Data Granularity: What Gets Imported

Purdue level 0, the physical process layer, is reported as 0. When Dragos does not know the level, the line is left out instead.

Use Cases

For a unified IT and OT risk view: A manufacturer maps each Dragos zone to a DefectDojo Asset per plant. Leadership sees OT and IT vulnerability counts and SLA status in the same reports, while plant engineers keep device-level detail.

From an air-gapped site: A site with no outbound connectivity exports detections on a schedule, carries the file across the boundary through an approved process, and imports it. If the connector is later allowed, findings deduplicate against the earlier imports.

For maintenance window planning: Engineers filter on the active-exploit tag and Purdue level to decide what must be patched in the next window, then risk-accept the rest with an expiration date tied to the next planned outage.

For vendor follow-up: Tags for vendor and model let the team group findings by device type and raise one request with a vendor covering every affected unit.

Operational Tips

• Copy the scan type exactly as Dragos Scan. A different string will not deduplicate with the connector.
• Use risk acceptance with expiration dates for flaws that must wait for an outage. It records the decision and brings it back for review.
• Read Severity Justification during triage. The severity reflects CVSS, but the exploitation context there is what usually decides OT priority.
• Reimport each site's export into the same Test so devices that were patched or retired are mitigated.
• Set minimum_severity, or Minimum Severity on the connector, if Info-level detections would bury actionable ones.
• Give the Dragos API key only the three read privileges the connector needs.