Threat Composer Integration with DefectDojo
Threat Composer Integration with DefectDojo
Threat Composer is an open source threat modeling tool published by AWS Labs. It helps teams write structured threat statements (threat source, prerequisites, threat action, impact, and affected assets), record assumptions and mitigations, and link them to each other, alongside application, architecture, and data flow information. It runs in the browser, keeps work in browser local storage, and exports a threat model as a JSON file, which DefectDojo can import.
Threat Composer Integration with DefectDojo
Threat modeling sessions produce good thinking and poor follow-through. We use Threat Composer because its statement format forces precise threats, and we import the result into DefectDojo so each threat becomes a Finding on the Asset it concerns. The priority set in the session becomes the severity, the linked mitigations come along as remediation guidance, and the threat stays open until someone resolves it. Design risks then show up in the same backlog and the same reports as scanner findings for that service.
Why Threat Composer Matters
Scanners find implementation bugs. Threat modeling finds design flaws that no scanner will report, such as a missing authorization boundary or an unauthenticated internal API that becomes reachable after a network change.
- Its grammar for threat statements makes threats specific enough to act on and to test against.
- It links threats to mitigations and assumptions, so the reasoning behind a decision is recorded and not just the decision.
- It supports metadata such as priority and STRIDE categories on each threat.
- A threat model in a JSON file or a wiki page goes stale. Once threats are Findings, they have owners, status, and a place in reporting.
Advantages of This Integration
What DefectDojo adds to a Threat Composer model:
- Threats as trackable work. Every threat with a threat action becomes a Finding that can be assigned, commented on, risk-accepted, or pushed to Jira.
- Priority drives SLAs. Threat Composer's High, Medium, and Low priority map directly to DefectDojo severity, so design risks inherit your normal SLA timers.
- Mitigations travel with the threat. Linked mitigations, with their status, comments, and any assumptions behind them, are written into the Finding's Mitigation field.
- Status carried over. Threats marked resolved in Threat Composer import as mitigated, and threats resolved as not useful import as false positives.
- Design and implementation risk in one view. Threat model Findings sit on the same Asset as SAST, SCA, and DAST results, so a security review can compare the two.
How This Integration Works
DefectDojo imports Threat Composer models with the ThreatComposer Scan scan type.
1. Export the model. In Threat Composer, use the export feature to save the current workspace as a JSON file. The file contains the application info, architecture, data flow, assumptions, mitigations, the links between them, and the threats. The parser requires a threats array and rejects files without one.
2. Import it. In the UI, create or open an Engagement for the design review, choose Import Scan Results, select ThreatComposer Scan, and upload the JSON. To script it, 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=ThreatComposer Scan" \
-F "file=@threat-model.json" \
-F "product_name=checkout-service" \
-F "engagement_name=Design Review 2026" \
-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 "ThreatComposer Scan" \
--report-path "./threat-model.json" \
--product-name "checkout-service" \
--engagement-name "Design Review 2026" \
--auto-create-context
3. Keep it current. When the model is revisited, export again and reimport into the same Test. Resolved threats update, new threats are added, and removed threats are mitigated.
Data Granularity: What Gets Imported
| DefectDojo Field | Source in Threat Composer JSON | Notes |
|---|---|---|
| Title | threatAction |
Threats without a threat action are skipped |
| Severity | Priority metadata |
High, Medium, Low map directly; anything else, or no priority, becomes Info |
| Description | Threat statement, comments, linked assumptions |
Assumptions listed with their numeric IDs and comments |
| Mitigation | Linked mitigations | Each with numeric ID, status, content, comments, and its own assumptions |
| Impact | STRIDE metadata |
Letters expanded, for example Spoofing, Tampering |
| Unique ID | Threat id |
The threat's UUID |
| Vuln ID from Tool | Threat numericId |
The number shown in Threat Composer |
| Tags | Threat tags |
Imported as DefectDojo tags |
| Status | Threat status |
threatResolved becomes mitigated; threatResolvedNotUseful becomes mitigated and false positive; others stay active |
| Finding type | Static | All threats |
| Deduplication | Unique ID from tool or hash code | Hash code uses title and description |
Use Cases
After a design review: The team runs a threat modeling session in Threat Composer, exports the model, and imports it into an Engagement for that review. The AppSec lead assigns High priority threats to the service owners and pushes them to Jira, so design work is planned alongside features.
Before a launch: A release checklist queries DefectDojo for open High threats on the Asset. Anything still unresolved needs either a mitigation or a documented risk acceptance before the launch goes ahead.
Linking design to testing: With threats and scanner findings on the same Asset, a pentest scope can be built from the open threats, and later DAST or pentest Findings can be compared against what the model predicted.
For audit evidence: Frameworks that ask for documented threat modeling get more than a diagram. DefectDojo shows each threat, who owned it, how it was mitigated, and when it closed.
Operational Tips
- Set a Priority on every threat before exporting. Threats without one import as Info and may fall outside your SLA policy.
- Write distinct threat actions. The threat action alone becomes the title, and the hash uses title and description, so two threats with identical text will collide.
- Use Threat Composer's statuses rather than editing status in DefectDojo after import, then reimport. That keeps the model and the Findings consistent.
- Keep threat models in an Engagement of their own (for example one per design review) so they are easy to separate from scanner Tests in metrics.
- Tags on threats are imported as DefectDojo tags. A consistent tag scheme in Threat Composer (component names, data classifications) gives you useful filters later.
- A CWE written as a tag on a threat stays a tag. The parser does not set the CWE field, so if your reporting groups Findings by CWE, set it on the Finding after triage.
- Mitigation status is copied into the Mitigation text but does not change the Finding's status. A threat whose mitigations are all implemented still needs its own status updated in Threat Composer to import as mitigated.
- Remember the model lives in browser local storage. Export after each session and keep the JSON under version control so the import source isn't lost.