threat-modeling

Threat Modeling Skill — STRIDE Methodology

1. When to Use

If a target is provided via arguments, focus the review on: $ARGUMENTS

Invoke this skill whenever any of the following conditions are met:

• New service or microservice design — A new component is being introduced into the architecture and needs threat analysis before implementation begins.
• Architecture review — An existing system is undergoing redesign, migration, or significant refactoring (e.g., monolith-to-microservices, on-prem-to-cloud).
• PRD with infrastructure implications — A product requirements document describes features that involve new data stores, external integrations, authentication changes, or network topology modifications.
• API design — New or modified API endpoints are being defined, especially those that accept user input, handle authentication tokens, or expose sensitive data.
• Pre-launch security review — A system is approaching production deployment and requires a structured assessment of threats before go-live.
• Compliance-driven review — Regulatory requirements (SOC 2, PCI DSS, HIPAA, FedRAMP) mandate documented threat analysis.
• Incident post-mortem — A security incident has occurred and the team needs to re-evaluate the threat landscape to prevent recurrence.

2. Context the Agent Needs

Before beginning the threat model, gather the following. Mark each item as obtained or missing and proceed with what is available, noting gaps as assumptions.

• System description — High-level purpose, business context, and intended users.
• Component inventory — Services, databases, message queues, caches, CDNs, third-party APIs, serverless functions, and any other runtime components.
• Data flow descriptions — How data moves between components, including protocols (HTTPS, gRPC, AMQP), serialization formats (JSON, Protobuf), and transport security (TLS version, mTLS).
• Trust boundaries — Where authentication and authorization are enforced; boundaries between internal networks, DMZs, public internet, third-party services, and user devices.
• Authentication and authorization mechanisms — OAuth 2.0 flows, API keys, JWTs, SAML, RBAC/ABAC policies, service-to-service identity (SPIFFE/mTLS).
• Data classification — What data is stored or processed (PII, PHI, financial data, credentials, secrets) and its sensitivity level.
• Threat actor profiles — External attackers, malicious insiders, compromised supply chain, nation-state actors, automated bots.
• Compliance and regulatory requirements — Applicable standards (SOC 2, PCI DSS, HIPAA, GDPR, FedRAMP).
• Existing security controls — WAF, IDS/IPS, SIEM, secret management (Vault, AWS Secrets Manager), encryption at rest and in transit.
• Deployment environment — Cloud provider (AWS, GCP, Azure), Kubernetes, serverless, on-premises, hybrid.