Problem Statement
The organization needs a structured workflow to produce a lightweight threat model for new engineering features. The workflow must transform basic feature inputs into actionable security outputs including assets, trust boundaries, threat enumeration, mitigations, and a security test checklist. The approach must remain public‑safe, avoid sensitive vendor details, and emphasize practical steps.
Steps
Ingest Feature Context
INGESTCollect the feature summary, data handled, user roles, external integrations, and deployment environment. Normalize the information into a consistent structure for downstream analysis.
Identify Assets and Trust Boundaries
EXECUTEAnalyze the provided context to extract key assets and map logical trust boundaries such as client/server, internal services, or external integrations.
Enumerate STRIDE Threats
EXECUTEApply a simplified STRIDE lens to the assets and boundaries to list potential threats in clear, plain language.
Prioritize Threats and Suggest Mitigations
EXECUTERank threats by likelihood and impact, then generate practical mitigations that do not rely on sensitive vendor details.
Produce Security Test Checklist and Residual Risk
EXECUTEDraft a focused security test checklist based on identified mitigations and provide a concise residual risk statement reflecting remaining uncertainties or limitations.
Validate Outputs Against Constraints
EXECUTECheck that results adhere to tone, avoid prohibited vendor references, and maintain public-safe detail levels.
Prompt Configurations
Threat Modeling Prompt
You are generating a lightweight threat model. Use a clear, slightly cautious, constructive tone. Input includes: feature summary, data handled, user roles, external integrations, and deployment environment. Output must include: (1) assets and trust boundaries, (2) top STRIDE-style threats in plain language, (3) practical mitigations without referencing sensitive vendors, (4) a security test checklist, and (5) a residual risk statement. Do not invent technologies not mentioned unless necessary for common-sense assumptions. Keep all content public-safe and avoid detailed implementation specifics. Only use the provided information plus reasonable assumptions.
Example Inputs/Outputs
Feature summary: New API endpoint allowing internal analysts to upload CSV reports. Data: low-sensitivity operational metrics. Roles: internal analysts, backend service account. Integrations: internal data lake. Environment: cloud-hosted container service.
Assets include uploaded CSV files, API auth tokens, and data lake write operations. Trust boundaries include analyst-to-API boundary and API-to-data-lake boundary. Threats include spoofed analyst identities, malformed uploads causing service issues, and unauthorized data lake writes. Mitigations include strong auth, input validation, rate limiting, and restricted service account permissions. Security test checklist includes auth tests, schema validation tests, error-handling tests, and permission boundary tests. Residual risk: low, primarily dependent on timely patching and monitoring.