drvoss Threat Model Analyst
Perform architecture-first security analysis using STRIDE-A: classic STRIDE plus explicit abuse-case thinking.
When to Use
- A new system or subsystem needs an initial threat model
- A major change landed and the question is "what changed security-wise?"
- You need to reason about trust boundaries, data flows, or risky integrations before implementation
- A security review needs architecture evidence, not only code-pattern scanning
When NOT to Use
| Instead of threat-model-analyst | Use |
|---|---|
| Code-level vulnerability scanning | security-scan or pr-security-review |
| Broad repository posture scoring | evaluate-repository |
| Agent-specific OWASP checklist review | agent-owasp-check |
| Supply-chain integrity validation | agent-supply-chain |
Modes
Single Analysis
Use when there is no prior threat model or when the whole system needs review.
Incremental Analysis
Use when a previous threat model exists and you need to compare the current system or a specific commit against that baseline.
Incremental mode is often the better day-to-day workflow because it highlights:
- new threats
- resolved threats
- still-present threats
- trust-boundary changes
- differences in severity or exploitability
Workflow
1. Define scope and assets
Clarify:
- what system or subsystem is in scope
- what assets matter most
- what actors exist
- what trust boundaries separate them
List obvious inputs and high-value outcomes before reading code in detail.
2. Build an architecture and data-flow sketch
You do not need perfect diagrams before analysis, but you do need a concrete model of:
- components
- entry points
- data stores
- external systems
- privileged execution zones
- trust boundaries between them
Represent the system as a lightweight DFD or component map if helpful.
3. Apply STRIDE-A to each component and flow
For each component or trust boundary, ask:
| Dimension | Question |
|---|---|
| Spoofing | Who could impersonate a user, service, or agent? |
| Tampering | What data or configuration could be modified without detection? |
| Repudiation | What actions would be hard to prove later? |
| Information Disclosure | What could leak across the boundary? |
| Denial of Service | What could exhaust or block the system? |
| Elevation of Privilege | What paths raise privileges unexpectedly? |
| Abuse | What realistic misuse path would an attacker or insider choose? |
4. Score and prioritize findings
For each finding, record:
- affected component or trust boundary
- short threat statement
- exploit path
- likely impact
- mitigating controls already present
- suggested remediation
Map to CWE, OWASP, or CVSS only when it clarifies the issue instead of bloating the report.
5. Run incremental analysis for changes
When comparing against a prior threat model, explicitly classify each item as:
- new
- resolved
- still present
- changed severity
This is especially useful for:
- new integrations
- changed authentication flows
- new background jobs or agents
- infrastructure moves
- CI/CD or deployment changes
6. Produce a concise decision-ready report
A good threat model report should leave the reader with:
- the architecture in scope
- the highest-risk boundaries
- the top findings in priority order
- what changed since the last model, if applicable
- the next mitigation step
Suggested structure:
## Architecture Overview
- ...
## Trust Boundaries
- ...
## STRIDE-A Findings
- [High] ...
- [Medium] ...
## Change Diff
- New: ...
- Resolved: ...
- Still present: ...
## Next Mitigations
- ...
Common Rationalizations
| Rationalization | Reality |
|---|---|
| "We'll just scan the code for vulnerabilities." | Code scanning misses architecture flaws, broken trust boundaries, and misuse paths. |
| "The old threat model is close enough." | Architecture drift makes stale threat models dangerously reassuring. |
| "Abuse cases are too speculative." | Real attackers optimize for abuse paths, not textbook categories. |
Red Flags
- No one can name the trust boundaries in the system
- External systems are treated as trusted by default
- Authentication or authorization changes are documented only at code level
- A prior threat model exists but no change diff was done after a major update
Verification
- The system scope and assets are explicit
- Components, flows, and trust boundaries were identified
- STRIDE-A was applied to each meaningful boundary or component
- Findings are prioritized instead of left as an unranked brainstorm
- Incremental changes are called out separately when a baseline exists
See Also
security-scan- inspect code-level vulnerabilities after the model identifies hot spotsagent-owasp-check- review agent-specific OWASP ASI riskssecurity-audit- broader workflow for OWASP plus STRIDE review