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 spots
• agent-owasp-check - review agent-specific OWASP ASI risks
• security-audit - broader workflow for OWASP plus STRIDE review