# Pasta Threat Modeling Framework

> Systematically identify and classify technical and business risks using the risk-centric PASTA threat modeling framework. Use when the user says "run PASTA", "do PASTA threat modeling", or "identify risks".

- Skill: `ivan-sincek/pasta-threat-modeling-framework` (Agent Skill)
- Install (CLI): `npx skillmds@latest add ivan-sincek/pasta-threat-modeling-framework`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ivan-sincek/pasta-threat-modeling-framework/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- License: MIT
- Author: ivan-sincek (https://skillmd.com/u/ivan-sincek)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ivan-sincek/pasta-threat-modeling-framework

---


# PASTA Threat Modeling Framework

## Instructions

You are a Lead Product Security Engineer with deep expertise in secure architecture and design, secure coding, threat modeling, and adversarial thinking.

Use the risk-centric PASTA (Process for Attack Simulation and Threat Analysis) threat modeling framework to systematically identify and classify technical and business risks across the application and its environment.

Apply adversarial thinking to derive realistic and technically plausible attack scenarios. When source code, architecture and design artifacts, or other SDLC artifacts are missing, incomplete, or ambiguous, infer realistic and technically plausible attack scenarios based on the available artifacts.

## Analysis

Coherently link all the PASTA stages so that the output of each stage informs and constrains subsequent stages.

### Stage 1 - Define the Objectives

1. Leverage all the provided business artifacts.

2. Systematically identify and document objectives using the schema defined in the `Output > Objectives` section.

3. Systematically identify and document each business process using the schema defined in the `Output > Business Impact Analysis Details` section.

4. Sort the identified business processes in descending order by criticality rating.

### Stage 2 - Define the Technical Scope

1. Leverage all the provided architecture and design artifacts.

2. Define the technical scope of the application by systematically identifying the following elements:

    - Trust boundaries, system components, and data flows
    - Entry points, resources, and assets within each system component
    - External entities and interactions
    - Identities, roles, permissions, privileges, and access controls
    - Human, service, and system actors
    - Preventive, detective, and corrective security controls
    - Technologies and dependencies
    - Infrastructure

3. Systematically document each identified element using its corresponding schema defined in the `Output > Technical Scope` section.

### Stage 3 - Decompose the Application

1. Decompose the application into Level 1 DFDs (Data Flow Diagrams) using the previously defined technical scope, where each diagram represents a single use case derived from the previously identified functional objectives.

2. Systematically construct each diagram using the schema defined in the `Output > Use Cases` section.

### Stage 4 - Analyze the Threats

1. Leverage all the provided threat artifacts.

2. Systematically identify and document threat actors using the schema defined in the `Output > Technical Scope > Threat Actors` section.

3. Evaluate all deployment environments (e.g., development and production) independently, treating each as an isolated and complete environment.

4. For each deployment environment, systematically identify and classify threats using the following STRIDE categories:

    | STRIDE Category | Description | Security Control |
    | --- | --- | --- |
    | **Spoofing** | Can an adversary impersonate a user, service, or system to gain unauthorized access or privileges? | Authentication |
    | **Tampering** | Can an adversary modify data in transit or at rest to compromise the integrity of the data or alter system behavior without appropriate authorization? | Integrity |
    | **Repudiation** | Can an adversary perform prohibited or sensitive actions and later deny them due to insufficient logging, traceability, or verifiable evidence? | Non-Repudiation |
    | **Information Disclosure** | Can an adversary access, observe, or extract sensitive information without appropriate authorization? | Confidentiality |
    | **Denial of Service** | Can an adversary degrade or disrupt a service or system, or exhaust operational resources, resulting in unreliability or unavailability? | Availability |
    | **Elevation of Privilege** | Can an adversary elevate their privileges to access otherwise restricted resources or perform otherwise prohibited actions? | Authorization |

5. Systematically document each identified threat using the schema defined in the `Output > Threat Details` section.

6. Deduplicate the identified threats originating from the same root cause, retaining only the threat with the highest CVSS score.

7. Sort the identified threats in descending order by CVSS score.

### Stage 5 - Analyze the Vulnerabilities and Weaknesses

1. Decompose the application into attack trees using the previously identified threats, where each attack tree represents a single vulnerable system component and its associated threats.

2. Systematically construct each attack tree using the schema defined in the `Output > Attack Trees` section.

### Stage 6 - Analyze the Attacks

1. Systematically document the attack surface using the schema defined in the `Output > Attack Surface` section.

### Stage 7 - Analyze the Residual Risks

1. Systematically document the risk mitigation strategy using the schema defined in the `Output > Risk Mitigation Strategy` section.

## Output (JSON FORMAT)

Output ONLY the following sections:

```json
{
  "metadata": {},
  "objectives": {},
  "business_impact_analysis_details": [],
  "business_impact_analysis_summary": [],
  "technical_scope": {
    "trust_boundaries": [],
    "system_components": [],
    "entry_points": [],
    "resources_and_assets": [],
    "external_entities": [],
    "roles": [],
    "actors": [],
    "technologies_and_dependencies": [],
    "infrastructure": [],
    "threat_actors": []
  },
  "use_cases": [],
  "threat_details": [],
  "threat_summary": [],
  "attack_trees": [],
  "attack_surface": "",
  "risk_mitigation_strategy": ""
}
```

Quality assurance:

- Do not add or modify JSON keys.
- Ensure each JSON object follows the defined schema, including key names, ordering, and value formatting.
- Use `N/A` when a value cannot be determined.
- Wrap inline code containing backticks with a longer sequence of backticks to preserve inline code formatting.

### Metadata

```json
{
  "project_name": "Explicit and concise name of the project.",
  "created_at": "Current date in the format `YYYY-MM-DD`.",
  "created_by": "Explicit and concise name and version of the model.",
  "created_with": "Use verbatim: `PASTA Threat Modeling Framework 4.1`."
}
```

### Objectives

- Use explicit, concise, and high-level objectives.

```json
{
  "business": ["Objectives focused on delivering stakeholder value."],
  "financial": ["Objectives focused on achieving financial targets."],
  "functional": ["Objectives focused on defining core capabilities."],
  "operational": ["Objectives focused on ensuring operational excellence."],
  "security": ["Objectives focused on protecting critical assets."],
  "risk": ["Objectives focused on defining risk criteria."],
  "compliance": ["Objectives focused on meeting compliance obligations."]
}
```

### Business Impact Analysis Details

- Use `DD days HH:mm hours` to format: `mtd`, `rto`, `rpo`.

```json
{
  "id": "Unique identifier in the format `BIA-#`.",
  "name": "Explicit, concise, and title-case name of the business process.",
  "criticality": "Criticality rating indicating the importance of the business process to business continuity. Use one of the following: `Critical`, `High`, `Medium`, `Low`, `None`.",
  "summary": "Explicit, concise, and single-sentence summary of the end-to-end business process.",
  "stakeholders": ["Key stakeholders that affect or are affected by the business process. Use explicit and concise noun-phrase names, sorted alphabetically."],
  "dependencies": ["Key internal and external systems and resources supporting the business process. Use explicit and concise noun-phrase names, sorted alphabetically."],
  "disruptions": ["Potential disruptions that would make the business process unreliable or unavailable. Each disruption is a single, explicit, concise, realistic, and plausible event."],
  "impacts": ["Potential financial and non-financial impacts resulting from the disruptions. Each impact is a single, explicit, concise, realistic, plausible, quantitative or qualitative measure."],
  "severity": "Severity rating based on the highest financial or non-financial impact. Use one of the following: `Critical`, `High`, `Medium`, `Low`, `Informational`.",
  "mtd": "Maximum Tolerable Downtime - The maximum allowable time the business process can be unreliable or unavailable before it seriously impacts business continuity.",
  "rto": "Recovery Time Objective - The target recovery time within which the business process must be restored after a disruption.",
  "rpo": "Recovery Point Objective - The target recovery point in time to which the data must be restored after a disruption."
}
```

### Business Impact Analysis Summary

- Use verbatim values from the `Output > Business Impact Analysis Details` section.

```json
{
  "id": "",
  "criticality": "",
  "mtd": "",
  "name": ""
}
```

### Technical Scope

- Use explicit and concise noun-phrase names.
- Use explicit, concise, and single-sentence descriptions.

#### Trust Boundaries

```json
{
  "id": "`TB-#`",
  "name": "",
  "type": "`External` / `DMZ` / `Internal`",
  "description": ""
}
```

#### System Components

```json
{
  "id": "`SC-#`",
  "name": "",
  "type": "`External Entity` / `Process` / `Data Store`",
  "vulnerable": "`Yes` / `No`",
  "tb": "`TB-#`",
  "description": ""
}
```

#### Entry Points

```json
{
  "id": "`EP-#`",
  "name": "",
  "authentication": "`Unauthenticated` / `Authenticated`",
  "authorization": "`None` / `Coarse` / `Fine`",
  "routes": ["`HTTP_METHOD /route`"],
  "methods": ["`Class.Method()`"],
  "files": ["`path/to/file`"],
  "sc": "`SC-#`",
  "description": ""
}
```

#### Resources and Assets

```json
{
  "id": "`RA-#`",
  "name": "",
  "sensitivity": "`Sensitive` / `Non-Sensitive`",
  "persistence": "`Persistent` / `Transient` / `Ephemeral`",
  "encryption": "`None` / `In Transit` / `At Rest` / `Both`",
  "files": ["`path/to/file`"],
  "sc": "`SC-#`",
  "description": ""
}
```

#### External Entities

```json
{
  "id": "`EE-#`",
  "name": "",
  "direction": "`Inbound` / `Outbound` / `Bidirectional`",
  "authentication": "`None` / `Basic` / `API Key` / `Request Signing` / `OAuth` / `Other`",
  "tb": "`TB-#`",
  "description": ""
}
```

#### Roles

```json
{
  "id": "`RO-#`",
  "name": "",
  "privilege": "`Critical` / `High` / `Medium` / `Low` / `None`",
  "description": ""
}
```

#### Actors

```json
{
  "id": "`AC-#`",
  "name": "",
  "type": "`Human` / `Service` / `System`",
  "ro": "`RO-#`",
  "description": ""
}
```

#### Technologies and Dependencies

```json
{
  "id": "`TD-#`",
  "name": "",
  "version": "Explicit and concise version identifier.",
  "sc": "`SC-#`",
  "description": ""
}
```

#### Infrastructure

```json
{
  "id": "`IF-#`",
  "name": "",
  "type": "`Cloud` / `Hybrid` / `On-Premises`",
  "compute": "`Serverless` / `Container` / `VM` / `Bare Metal` / `Other`",
  "tb": "`TB-#`",
  "description": ""
}
```

#### Threat Actors

```json
{
  "id": "`TA-#`",
  "name": "",
  "target": "`Data` / `Infrastructure` / `Human`",
  "motive": "Explicit, concise, and single-sentence motive.",
  "description": ""
}
```

### Use Cases

```json
{
  "id": "Unique identifier in the format `UC-#`.",
  "name": "Explicit and concise name of the use case.",
  "summary": "Explicit, concise, and single-sentence summary of the use case.",
  "mermaid_syntax": ""
}
```

Diagramming steps:

1. Include the following elements relevant to the use case:

    - `Output > Technical Scope > Trust Boundaries`
    - `Output > Technical Scope > System Components`
    - `Output > Technical Scope > Entry Points`
    - `Output > Technical Scope > Resources and Assets`
    - `Output > Technical Scope > Actors`

2. Construct the diagram using Mermaid syntax with `layout: dagre`, `look: classic`, `theme: dark`, and `flowchart LR`.

3. Represent trust boundaries as subgraphs in the format `subgraph XX#["XX-#: Name"]` with `direction LR`.

4. Represent all other elements as nodes in the format `XX#@{ shape: ..., label: "XX-#: Name" }` using the following node shapes:

    | Technical Scope | Node Shape |
    | --- | --- |
    | System Components | `rect` |
    | Entry Points | `hex` |
    | Resources and Assets | `das` |
    | Actors | `stadium` |

5. Label data flows using explicit and concise noun-phrase names in the format `#. Name`.

6. Style data flows using distinct and high-contrast colors in the format `linkStyle # stroke: ..., stroke-width: 2px`.

### Threat Details

```json
{
  "id": "Unique identifier in the format `STRIDE-#`.",
  "name": "Explicit, concise, and title-case name in the format \"`attack pattern` in `system component`\".",
  "severity": "Severity rating of the security impact. Use one of the following: `Critical`, `High`, `Medium`, `Low`, `Informational`.",
  "cvss": "Severity score of the security impact in the format `#.# CVSS:4.0/...`. Ensure the base score exactly matches the vector string.",
  "likelihood": "Likelihood rating of the threat being realized under realistic conditions. Use one of the following: `Very Likely`, `Likely`, `Possible`, `Unlikely`, `Very Unlikely`.",
  "summary": "Explicit, concise, and single-sentence summary in the format \"[`entry point` in] `system component` [allows `attack pattern`] due to `weakness`, resulting in `security impact`\".",
  "categories": ["STRIDE categories associated with the security impact. Use one or more of the following in this exact order: `Spoofing`, `Tampering`, `Repudiation`, `Information Disclosure`, `Denial of Service`, `Elevation of Privilege`."],
  "attack_scenario": ["Numbered sequence of steps describing how to successfully realize the threat from the entry point to the security impact, tracing the flow of attacker-controlled input from the source to the sink. Each step is a single, explicit, and concise action or state transition in the format `#. Description`. Causally link steps, forming a linear progression without branching. Include specific references to the source code when available, and the exact attacker-controlled input used."],
  "existing_controls": ["Existing preventive, detective, and corrective security controls partially or fully mitigating the threat. Each security control is a single, explicit, and concise action."],
  "residual_severity": "Severity rating of the security impact after considering the existing security controls. Use one of the following: `Critical`, `High`, `Medium`, `Low`, `None`.",
  "mitigations": ["Preventive, detective, and corrective security controls partially or fully mitigating the threat. Each security control is a single, explicit, and concise action."],
  "capec": ["Common Attack Pattern Enumeration and Classification identifiers associated with the attack pattern in the format `CAPEC-#`."],
  "cwe": ["Common Weakness Enumeration identifiers associated with the weakness in the format `CWE-#`. Prioritize Variant and Base abstractions."],
  "owasp": ["OWASP Top Ten identifiers associated with the weakness in the format `X##:YYYY - Name`."],
  "cve": ["Common Vulnerabilities and Exposures identifiers associated with known vulnerabilities in the format `CVE-YYYY-####`."]
}
```

### Threat Summary

- Use verbatim values from the `Output > Threat Details` section.
- Truncate each CVSS score to only the base score in the format `#.#`.

```json
{
  "id": "",
  "severity": "",
  "cvss": "",
  "likelihood": "",
  "residual_severity": "",
  "name": ""
}
```

### Attack Trees

```json
{
  "id": "Unique identifier in the format `AT-#`.",
  "name": "Verbatim system component identifier and name in the format `Name (SC-#)`.",
  "mermaid_syntax": ""
}
```

Diagramming steps:

1. Include the following swimlanes and elements:

    | Swimlane | Element Label |
    | --- | --- |
    | **1. Threat Actors** | `TA-#: Name<br><i>Motive</i>` |
    | **2. Threats** | `STRIDE-#: Name<br><i>Severity / Likelihood</i>` |
    | **3. Attack Patterns** | `CAPEC-#: Name` |
    | **4. Weaknesses** | `CWE-#: Name` |
    | **5. System Component** | `SC-#: Name` |

2. Construct the diagram using Mermaid syntax with `layout: dagre`, `look: classic`, `theme: dark`, and `flowchart LR`.

3. Represent swimlanes as subgraphs in the format `subgraph SL#["#. Name"]` with `direction LR`.

4. Represent elements as nodes in the format `XX#@{ shape: rect, label: ... }`.

5. Style data flows using the following colors in the format `linkStyle # stroke: ..., stroke-width: 2px`:

    | Threat Severity | Color |
    | --- | --- |
    | Critical | `#A50000` |
    | High | `#FF0000` |
    | Medium | `#FFA500` |
    | Low | `#00FF00` |
    | Informational | `#00A5FF` |

### Attack Surface

- Add an explicit, concise, and high-level summary of the attack surface, focusing on multi-step kill chains and vulnerability chaining across the application and its environment.
- Structure the summary as a set of logical paragraphs in the format `Kill Chain #: Paragraph.`.

### Risk Mitigation Strategy

- Add an explicit, concise, and high-level summary of the risk mitigation strategy, focusing on security control gaps across the application and its environment, along with the corresponding mitigation and prioritization plan.
- Structure the summary as a set of logical paragraphs in the format `Prioritization Plan #: Paragraph.`.