Use OWASP Threat Dragon to create data flow diagrams, identify threats using STRIDE and LINDDUN methodologies, and generate threat model reports for secure design review.
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Use OWASP Threat Dragon to create data flow diagrams, identify threats using STRIDE and LINDDUN methodologies, and generate threat model reports for secure design review.
Performing Threat Modeling with OWASP Threat Dragon
Overview
OWASP Threat Dragon is an open-source threat modeling tool that enables security teams and developers to create threat model diagrams, identify threats using established methodologies (STRIDE, LINDDUN, CIA, DIE, PLOT4ai), and generate comprehensive reports. Threat Dragon runs as both a web application and desktop application (Windows, macOS, Linux), supporting distributed teams working collaboratively on threat models. Version 2.x provides drag-and-drop diagram creation, an auto-generation rule engine for threats and mitigations, and PDF report output for documentation and GRC compliance.
When to Use
When conducting security assessments that involve performing threat modeling with owasp threat dragon
When following incident response procedures for related security events
When performing scheduled security testing or auditing activities
When validating security controls through hands-on testing
Common Misconfigurations & Verification
Trust boundaries omitted: a DFD with no dashed boundaries produces no meaningful threats — STRIDE per-element only fires where data crosses a trust level. Confirm every internet→app, app→DB, and user→admin transition has a boundary drawn, or the rule engine under-generates.
Rule-engine output accepted verbatim: Threat Dragon auto-suggests threats by element type but cannot see your auth or business logic. Triage every suggestion to Mitigated / Not Applicable / Open with a documented reason — mass "Not Applicable" is the most common way real threats are buried.
Data flows unlabeled: an arrow with no data description hides Information Disclosure/Tampering threats. Label each flow with what crosses it (PII, tokens, payment data).
Privacy threats skipped: STRIDE-only models miss Linkability/Identifiability — use the LINDDUN view for any system handling personal data under GDPR/HIPAA.
Stale model: a threat model not updated when architecture changes is worse than none. Store the JSON in version control beside the code and diff it on design changes.
Verify coverage: cross-check that every Process has all six STRIDE categories considered and every Open threat has an owner, priority, and mitigation. Re-open the generated PDF and confirm no element shows zero threats — an element with none usually means it was added after threat generation ran.
Prerequisites
OWASP Threat Dragon desktop application or web instance
Understanding of data flow diagram (DFD) notation
Familiarity with STRIDE or LINDDUN threat classification
Application architecture documentation and network diagrams
Stakeholder access for design review sessions
Threat Modeling Methodologies
STRIDE
Category
Threat Type
Description
Example
S
Spoofing
Impersonating a user or system
Stolen session tokens
T
Tampering
Modifying data in transit or at rest
SQL injection altering records
R
Repudiation
Denying an action occurred
Missing audit logs
I
Information Disclosure
Exposing sensitive data
API returning excessive fields
D
Denial of Service
Making a service unavailable
Resource exhaustion attack
E
Elevation of Privilege
Gaining unauthorized access
Broken access control
LINDDUN (Privacy-Focused)
Category
Threat Type
Description
L
Linkability
Associating data items across contexts
I
Identifiability
Identifying an individual from data
N
Non-repudiation
Inability to deny an action (privacy risk)
D
Detectability
Determining if data about a subject exists
D
Disclosure
Exposing personal information
U
Unawareness
User unaware of data collection
N
Non-compliance
Violating privacy regulations
Workflow
Step 1 --- Install Threat Dragon
Desktop Application:
Download the installer from the OWASP Threat Dragon releases page for Windows (.exe), macOS (.dmg), or Linux (.AppImage/.deb/.rpm).
Specific technical controls (encryption, authentication, rate limiting)
Owner responsible for implementation
Priority and timeline for remediation
Step 6 --- Generate Reports
Threat Dragon produces PDF reports containing:
Executive summary of the threat model
Data flow diagrams with annotations
Threat inventory with severity ratings
Mitigation status and recommendations
Compliance mapping where applicable
Step 7 --- Integrate into SDLC
Conduct threat modeling during the design phase of new features
Update threat models when architecture changes occur
Review threat models during security design reviews
Store threat model files in version control alongside code
Reference threat model findings in security acceptance criteria
Threat Model File Format
Threat Dragon uses JSON format for threat models, enabling version control and programmatic manipulation:
{"version":"2.2.0","summary":{"title":"E-Commerce Application","owner":"Security Team","description":"Threat model for the checkout flow"},"detail":{"contributors":[{"name":"Security Architect"}],"diagrams":[{"id":0,"title":"Checkout Flow","diagramType":"STRIDE","cells":[]}]}}
CycloneDX TMBOM Integration
Threat Dragon participates in the CycloneDX Threat Model Bill of Materials (TMBOM) effort, enabling export to a common format that can be consumed by other threat modeling tools and GRC platforms, preventing vendor lock-in.
Best Practices
Start simple: Begin with high-level DFDs (Level 0) before decomposing into detailed diagrams
Involve developers: Include development team members in threat modeling sessions for realistic threat assessment
Time-box sessions: Limit initial sessions to 90 minutes; iterate in follow-up sessions
Prioritize by risk: Use severity ratings (Critical, High, Medium, Low) to prioritize mitigations
Living documents: Treat threat models as living documents that evolve with the system
Automate where possible: Use the rule engine for initial threat generation, then refine manually
