d} on element ${t.elementId} requires mitigation.` ), warnings: [] }; }

const mediumThreats = this.model.threats.filter(
  t => t.severity === 'medium' && t.status === 'open'
);

return {
  passed: true,
  errors: [],
  warnings: mediumThreats.map(t => 
    `WARNING: Medium threat ${t.id} is open. Consider addressing in next sprint.`
  )
};

}

/**

• Checks for missing STRIDE categories on sensitive data flows. */ public checkDataFlowCoverage(): string[] { const sensitiveFlows = this.model.dataFlows.filter( f => f.dataClassification === 'confidential' || f.dataClassification === 'restricted' );

const missingCategories: string[] = [];

const strideCategories: STRIDE[] = ['S', 'T', 'R', 'I', 'D', 'E'];

sensitiveFlows.forEach(flow => {
  const flowThreats = this.model.threats.filter(t => t.elementId === flow.id);
  const coveredCategories = new Set(flowThreats.map(t => t.category));
  
  strideCategories.forEach(cat => {
    if (!coveredCategories.has(cat)) {
      missingCategories.push(
        `MISSING: STRIDE category '${cat}' not analyzed for flow ${flow.id}.`
      );
    }
  });
});

return missingCategories;

} }

export interface ValidationResult { passed: boolean; errors: string[]; warnings: string[]; }

### Architecture Decisions and Rationale

*   **Threat Model as Code:** Storing the model in JSON/YAML alongside source code ensures the threat model evolves with the system. It enables diffs in pull requests, allowing security reviews to focus on architectural changes rather than static documents.
*   **TypeScript Schema:** Using a typed schema enforces completeness. The compiler catches missing fields, and the validator logic can be integrated into pre-commit hooks or CI pipelines to block deployments with unresolved critical threats.
*   **STRIDE on DFDs:** STRIDE provides a comprehensive mnemonic for threat identification. Applying it to DFD elements ensures coverage of data flows, external interactions, and storage, which are common attack vectors in distributed systems.
*   **Trust Boundaries:** Explicitly defining trust zones allows for precise identification of where authentication, authorization, and encryption controls are required. This reduces ambiguity in implementation.

## Pitfall Guide

### Common Mistakes

1.  **Boiling the Ocean:** Attempting to model the entire enterprise architecture at once leads to analysis paralysis. Teams should model services or features incrementally, focusing on the highest risk components first.
2.  **Ignoring Business Logic:** Focusing exclusively on technical threats (e.g., SQL injection) while missing business logic flaws (e.g., privilege escalation via workflow manipulation) leaves critical gaps. Threat models must include use cases and user roles.
3.  **Static Documentation:** Treating the threat model as a one-time document created during design. As the system evolves, the threat model must be updated. Without versioning and automation, the model quickly becomes obsolete.
4.  **No Mitigation Strategy:** Listing threats without assigning owners, mitigations, or risk acceptance decisions renders the exercise futile. Every identified threat must have a disposition: mitigate, transfer, or accept.
5.  **Excluding Developers:** When security teams perform threat modeling in isolation, developers lack ownership and context. The process must be collaborative, involving the engineers who understand the implementation details.
6.  **Over-Reliance on Automation:** While tools can assist with DFD generation and checklist validation, they cannot replace human analysis of complex interactions and novel attack vectors. Automation should support, not replace, the analyst.
7.  **Neglecting Third-Party Dependencies:** Modern systems rely heavily on external APIs, libraries, and SaaS components. Failure to model the trust relationships and failure modes of these dependencies introduces supply chain risks.

### Best Practices

*   **Lightweight Sessions:** Conduct threat modeling in 30-60 minute sessions during sprint planning or design reviews. Use checklists and templates to accelerate the process.
*   **Focus on Data:** Prioritize analysis based on data sensitivity. Flows involving PII, financial data, or cryptographic keys require deeper scrutiny than public content delivery.
*   **Automate Validation:** Integrate threat model validation into CI/CD. Use scripts to check that new code changes align with the documented threat model and that mitigations are present.
*   **Risk-Based Prioritization:** Use a consistent risk scoring methodology (e.g., DREAD or qualitative High/Medium/Low) to prioritize remediation efforts based on business impact.
*   **Continuous Improvement:** Review threat models periodically and after security incidents. Update the model to reflect new threats, architectural changes, and lessons learned.

## Production Bundle

### Action Checklist

- [ ] **Define Scope:** Identify the service boundary, trust zones, and critical assets for the current sprint or feature.
- [ ] **Draw DFD:** Create a data flow diagram highlighting processes, stores, external entities, and trust boundaries.
- [ ] **Apply STRIDE:** Systematically analyze each DFD element for Spoofing, Tampering, Repudiation, Information Disclosure, DoS, and Elevation of Privilege.
- [ ] **Document Threats:** Record identified threats with severity, description, and affected element in the threat model repository.
- [ ] **Assign Mitigations:** Define mitigation strategies for high/critical threats and assign owners to implement controls.
- [ ] **Validate Model:** Run the threat model validator script to ensure coverage and resolution of critical risks.
- [ ] **Review in PR:** Include threat model updates in pull requests and require security review for architectural changes.
- [ ] **Update CI/CD:** Integrate threat model validation checks into the deployment pipeline to prevent regression.

### Decision Matrix

| Scenario | Recommended Approach | Why | Cost Impact |
|----------|---------------------|-----|-------------|
| **Microservice with PII** | Full STRIDE + DFD | High sensitivity data requires rigorous analysis of data flows and trust boundaries. | Medium (Initial setup) / Low (Long-term) |
| **Legacy Monolith Refactor** | Incremental STRIDE by Module | Modeling the whole system is infeasible; focus on modules being modified or exposed. | Low |
| **Serverless Function** | Lightweight Checklist | Ephemeral nature reduces attack surface; focus on IAM, input validation, and dependencies. | Low |
| **IoT Device Firmware** | PASTA Framework | PASTA emphasizes attacker perspective and business impact, crucial for physical safety risks. | High |
| **Internal Tooling** | LINDDUN Privacy Focus | If data privacy is the primary concern, LINDDUN provides targeted analysis for PII. | Medium |

### Configuration Template

Use this JSON schema to structure your threat model repository. This template supports versioning and validation.

```json
{
  "schemaVersion": "1.0",
  "serviceId": "user-auth-service",
  "version": "2.1.0",
  "lastUpdated": "2024-05-20T14:30:00Z",
  "assets": [
    {
      "id": "asset-001",
      "name": "User Credentials",
      "type": "data",
      "classification": "restricted"
    }
  ],
  "trustZones": ["external", "dmz", "internal"],
  "dataFlows": [
    {
      "id": "flow-001",
      "source": "client-app",
      "destination": "auth-gateway",
      "protocol": "HTTPS/TLS1.3",
      "dataClassification": "restricted"
    }
  ],
  "threats": [
    {
      "id": "threat-001",
      "elementId": "flow-001",
      "category": "I",
      "description": "Credential interception via MITM if TLS is misconfigured.",
      "severity": "high",
      "mitigation": "Enforce TLS 1.3 with certificate pinning on client.",
      "status": "mitigated"
    }
  ]
}

Quick Start Guide

1. Initialize Repository: Create a threat-model.json file in your service repository using the configuration template.
2. Sketch DFD: Use a tool like Threat Dragon or a simple diagramming library to draw the data flow for your current feature. Identify trust boundaries.
3. Run STRIDE Session: Schedule a 30-minute meeting with the feature team. Walk through each DFD element and brainstorm threats using the STRIDE mnemonic.
4. Log Findings: Update threat-model.json with identified threats, severity, and proposed mitigations.
5. Integrate Validation: Add the TypeScript validator script to your CI pipeline. Configure the pipeline to fail if high/critical threats are open and unmitigated.

By embedding threat modeling into the development lifecycle, engineering teams transform security from a reactive bottleneck into a proactive design discipline. This approach reduces risk, lowers remediation costs, and accelerates delivery by ensuring defenses are architected into the system from the start.