Threagile Integration with DefectDojo

Threagile Integration with DefectDojo

Threagile is an open source toolkit for agile threat modeling, created by Christian Schneider. Teams describe an architecture in a YAML file (technical assets, data assets, communication links, trust boundaries, and shared runtimes) and Threagile runs a set of built-in risk rules against that model. It produces a PDF report, data flow diagrams, an Excel risk list, and a risks.json file. Each risk has a category, severity, likelihood, impact, and a tracking status that the team maintains in the model. DefectDojo imports risks.json.

Threagile Integration with DefectDojo

We adopted Threagile because a threat model in YAML lives in the repository and changes with the architecture, instead of in a slide deck that goes stale. The gap was follow-through: risks identified in design reviews didn't show up anywhere our engineers track work. Importing Threagile risks into DefectDojo puts each one on the Asset as a Finding with a CWE, a severity, and an owner, next to the scanner findings for the same system. When the model is updated and Threagile runs again, reimport shows which design risks were resolved.

Why Threagile Matters

Scanners find implementation defects. Threat modeling finds design problems, such as a datastore reachable without an access layer or sensitive data crossing a trust boundary in clear text.

• The model is code, so it can be reviewed in pull requests and rerun in CI whenever the architecture changes.
• Built-in rules cover common architecture risks like missing authentication, unencrypted communication, missing network segmentation, and unguarded access from the internet.
• Each risk names the most relevant technical asset, trust boundary, or communication link, so it points at a specific part of the design.
• Risk tracking in the model records whether each risk is unchecked, in discussion, accepted, in progress, mitigated, or a false positive.
• Design risks rarely get SLAs or owners unless they enter the same system as other findings.

Advantages of This Integration

What we gained by sending Threagile output through DefectDojo:

• Design risks next to scanner findings. A missing-authentication risk from the model sits on the same Asset as DAST findings for that service, which helps when deciding whether a scanner result is a symptom of a design gap.
• CWE classification. The parser maps each Threagile risk category to a CWE (for example cross-site scripting to CWE-79, unencrypted communication to CWE-319), so threat model output shows up in CWE-based reports.
• Tracking status carries over. Risks marked accepted, false-positive, in-discussion, in-progress, or mitigated in the Threagile model arrive with the matching DefectDojo status.
• Stable identity across runs. Each finding uses Threagile's synthetic_id as its unique ID, so the same risk is recognized when the model is rerun.
• Accountability. Design risks get owners, SLAs, notes, and Jira tickets like any other finding.

How This Integration Works

DefectDojo imports Threagile output with the Threagile risks report scan type.

1. Run Threagile. With the official container image, from the directory containing your model:

docker run --rm -it -v "$(pwd)":/app/work threagile/threagile -verbose -model /app/work/threagile.yaml -output /app/work

This writes risks.json, along with the other report artifacts, to the output directory. The parser expects a JSON array of risks, each with category, title, severity, synthetic_id, and exploitation_impact. A missing field stops the import with an error.

2. Import it. In the UI, open the Engagement, choose Import Scan Results, select Threagile risks report, and upload risks.json. To automate 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=Threagile risks report" \
  -F "file=@risks.json" \
  -F "product_name=customer-portal" \
  -F "engagement_name=Threat Model" \
  -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 "Threagile risks report" \
  --report-path "./risks.json" \
  --product-name "customer-portal" \
  --engagement-name "Threat Model" \
  --auto-create-context

3. Reimport when the model changes. Rerun Threagile after architecture or risk tracking updates and send the new risks.json to /api/v2/reimport-scan/ for the same Test.

Data Granularity: What Gets Imported

Exploitation likelihood and data breach probability are not imported.

Use Cases

Design reviews in CI: The threat model lives in the service repository. A pipeline step runs Threagile on every change to the YAML and reimports risks.json. New risks from an added data flow show up as findings before the change ships.

Security architecture programs: An architecture team maintains models for its most important systems and imports each into its Asset. Leadership can see open design risks by severity alongside scanner findings, rather than in a separate document.

Linking design and testing: When a pentest or DAST tool reports a missing-authentication issue, the team can check whether the threat model already flagged that link and what was decided at the time.

Recording risk decisions: Risks the team accepts in Threagile's risk tracking arrive risk accepted in DefectDojo, so the decision and its reasoning are visible to auditors with the other risk acceptances.

Comparing design and implementation over time: After a refactor that adds an API gateway in front of a datastore, the team updates the model and reruns Threagile. The unguarded access risks for that datastore drop out of the next reimport and are mitigated, which records when the design change took effect.

Operational Tips

• Keep risk tracking in the Threagile model current. DefectDojo statuses come from risk_status, so a decision recorded only in DefectDojo can disagree with the model on the next import.
• Expect many findings to share a title. The title is the risk category, so use the component name and description to tell individual risks apart.
• Review duplicates carefully. Matching falls back to title, CWE, and severity, so two different risks of the same category and severity can be matched as duplicates.
• Set SLAs for design risks deliberately. Some categories, such as unnecessary data transfer, are cleanup items rather than urgent work.
• Use a dedicated Engagement (for example "Threat Model") so design findings can be reported separately from scanner output.
• Commit risks.json or attach it as a pipeline artifact, so each import can be traced to a model version.