OWASP Threat Dragon Integration with DefectDojo

OWASP Threat Dragon Integration with DefectDojo

OWASP Threat Dragon is a free, open source threat modeling application and an OWASP project, founded by Mike Goodwin and led by a small group of project leaders. It is used to draw data flow diagrams of a system (processes, data stores, actors, flows, and trust boundaries) and to record the threats identified against each element, with a type, severity, status, and mitigation for every threat. It runs as a web application or as a desktop application for Windows, macOS, and Linux, and saves each model as a JSON file that DefectDojo can import.

OWASP Threat Dragon Integration with DefectDojo

Our architects model new services in OWASP Threat Dragon, and DefectDojo is where the threats from those sessions stop being a diagram and start being work. Importing the model's JSON turns each threat into a Finding on the service's Asset, with the severity the modeler chose, the mitigation they wrote, the diagram element it applies to, and its STRIDE category. Threats the team already marked as mitigated come in as mitigated rather than disappearing, so the decisions made in the design review are on record next to the scanner findings for the same service.

Why OWASP Threat Dragon Matters

Scanners find what is wrong with code that exists. Threat modeling finds what could go wrong with a design before it is built, which is when a fix is cheapest.

• It gives teams a free, visual way to model a system and attach threats directly to the components they affect.
• Each threat carries its own severity and mitigation, so the output is a prioritized list, not just a picture.
• Models are plain JSON files, which can be versioned alongside the code they describe.
• The web version can store models in GitHub, GitLab, or Bitbucket repositories, while the desktop version works entirely from the local filesystem.
• Threat Dragon follows the Threat Modeling Manifesto, which keeps the practice approachable for development teams, not only security specialists.

Advantages of This Integration

• Design threats become trackable work. Each threat is a Finding that can be assigned, commented on, given an SLA, and pushed to Jira like any scanner result.
• Severity carried over directly. Threat Dragon's Critical, High, Medium, and Low map one to one; threats still marked TBD import as Info.
• Mitigation decisions survive the import. Threats with a Mitigated status import as mitigated, inactive Findings, so you can see what was considered and addressed, not only what is open.
• Context on every Finding. The description records the threat type, the diagram element, the diagram title, the model title, and the status, so a reader does not need the original model open.
• Deduplication across model revisions. Findings are hashed on title, Component Name (the element), and severity, so reimporting an updated model matches unchanged threats instead of duplicating them.
• One view of design and implementation risk. Modeled threats sit on the same Asset as SAST, SCA, and DAST findings, which lets a reviewer check whether a threat raised at design time later showed up as a real vulnerability.

How This Integration Works

DefectDojo imports models with the Threat Dragon Scan scan type. Both Threat Dragon schema versions are handled: v1 models that nest diagram cells under diagramJson, and v2 models that carry cells and names directly.

1. Save the model as JSON. In Threat Dragon, save or export the threat model. The resulting .json file is what DefectDojo imports; no conversion is needed.

2. Import it. In the UI, open the Engagement, choose Import Scan Results, select Threat Dragon Scan, and upload the file. For automation, for example when models are stored in a repository, 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=Threat Dragon Scan" 
  -F "file=@payments-threat-model.json" 
  -F "product_name=payments-api" 
  -F "engagement_name=Design Review" 
  -F "auto_create_context=true"

DefectDojo Pro users can use Universal Importer:

universal-importer import 
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" 
  --scan-type "Threat Dragon Scan" 
  --report-path "./payments-threat-model.json" 
  --product-name "payments-api" 
  --engagement-name "Design Review" 
  --auto-create-context

3. Reimport when the model changes. After each design review, reimport the updated model to /api/v2/reimport-scan/ against the same Test. Threats that were removed from the model are mitigated, new ones are added, and the rest keep their history.

Data Granularity: What Gets Imported

Use Cases

At design review sign-off: When a new service's model is approved, import it into the service's Asset. Open threats become Findings with owners and SLAs, so the follow-up from the review does not live only in meeting notes.

Closing the loop with testing: A threat about credential exposure in a data store is on record from the model. When a later SAST or secrets scan finds hardcoded credentials in that service, both appear on the same Asset, which shows the design concern was real and gives the fix a clear priority.

Tracking architecture change: As the design evolves, reimporting the updated model shows which threats were added, which were mitigated, and which were removed, with dates for each.

Reporting to leadership: Security leads can report open design-level threats by severity across every Asset that has a model, next to the counts of implementation findings.

Operational Tips

• Give each threat a specific title. Deduplication uses title, element, and severity, so generic titles repeated on one element can collapse into one Finding.
• Severity is part of the hashcode. Changing a threat's severity in the model makes the next reimport treat it as a new Finding and mitigate the old one, so expect that churn after a re-rating session.
• Only the Mitigated status imports as inactive. Any other status, including one meaning not applicable, imports as active, so close or risk-accept those in DefectDojo after the first import.
• Set severities before importing. Threats left as TBD arrive as Info and will not fall under your higher-severity SLAs.
• Name diagram elements clearly, since the element name becomes the Component Name used for filtering and deduplication.
• Keep one Test per model and reimport into it, so each system's threat history stays in one place.