STRIDE + PASTA Threat Modelling API Guide

11 routes under /threat-models with full STRIDE categorisation, PASTA stage mapping, DFD component modelling, and automatic regulatory traceability to RBI TRA, SEBI CSCRF SDLC, and IRDAI IS Audit requirements.

11 Routes Overview

The threat modelling module exposes 11 routes under /threat-models/*. All routes require Bearer JWT authentication and the X-Tenant-Id header.

#	Method	Route	Description
1	`GET`	`/threat-models`	List all threat models for the tenant (paginated)
2	`POST`	`/threat-models`	Create a new threat model
3	`GET`	`/threat-models/:id`	Get full threat model detail (single-endpoint pattern)
4	`PUT`	`/threat-models/:id`	Update threat model metadata
5	`DELETE`	`/threat-models/:id`	Soft-delete a threat model
6	`POST`	`/threat-models/:id/components`	Add DFD components (processes, data stores, external entities)
7	`POST`	`/threat-models/:id/threats`	Add STRIDE threats to the model
8	`POST`	`/threat-models/:id/mitigations`	Add mitigations linked to threats
9	`POST`	`/threat-models/:id/pasta-stages`	Map PASTA stage analysis (stages 1–7)
10	`POST`	`/threat-models/:id/regulatory-map`	Generate regulatory mapping for the model
11	`GET`	`/threat-models/:id/export`	Export threat model as PDF or JSON

Single-Endpoint Detail Pattern

The GET /threat-models/:id endpoint returns the complete threat model with all nested arrays in a single response. This avoids N+1 queries and simplifies client-side rendering.

GET /threat-models/tm_9x8y7z6w
Authorization: Bearer <token>
X-Tenant-Id: acme-bank

// Response 200 — single object with all nested data
{
  "id":          "tm_9x8y7z6w",
  "name":        "Core Banking UPI Module",
  "status":      "IN_PROGRESS",
  "methodology": "STRIDE_PASTA",
  "createdAt":   "2026-04-01T09:00:00+05:30",

  // All nested arrays included in single response
  "components":     [/* DFD components */],
  "threats":        [/* STRIDE-categorised threats */],
  "mitigations":    [/* linked mitigations */],
  "pastaStages":    [/* 7-stage PASTA analysis */],
  "regulatoryMap":  [/* RBI, SEBI, IRDAI mappings */],
  "summary": {
    "totalThreats":     18,
    "mitigatedThreats": 12,
    "openThreats":      6,
    "components":       9,
    "regulatoryGaps":   2
  }
}

Why Single-Endpoint? Threat models are typically rendered in full — a DFD diagram with threats overlaid, mitigations linked, and regulatory gaps highlighted. Fetching this data across multiple endpoints introduces latency and complexity. The single-endpoint pattern returns everything needed in one round-trip.

Enum Exactness

The API enforces exact enum values. Abbreviated or informal values will be rejected with a 422 VALIDATION_ERROR. This is a common source of integration errors.

STRIDE Threat Categories

Always use the full enum value, not abbreviations:

// STRIDE category enums — use EXACTLY these values
"SPOOFING"              // NOT "S" or "Spoofing"
"TAMPERING"             // NOT "T" or "Tampering"
"REPUDIATION"           // NOT "R" or "Repudiation"
"INFORMATION_DISCLOSURE" // NOT "I" or "Info Disclosure"
"DENIAL_OF_SERVICE"     // NOT "D" or "DoS"
"ELEVATION_OF_PRIVILEGE" // NOT "E" or "EoP"

DFD Component Types

DFD components must use the exact type enum:

// DFD component type enums
"PROCESS"           // A processing element (circle in DFD)
"DATA_STORE"        // A data store (parallel lines in DFD)
"EXTERNAL_ENTITY"   // An external entity (rectangle in DFD)
"DATA_FLOW"         // A data flow between components (arrow in DFD)
"TRUST_BOUNDARY"    // A trust boundary (dashed line in DFD)

Common Mistake Using "S" instead of "SPOOFING" or "DataStore" instead of "DATA_STORE" will return a 422 error. All enums are UPPER_SNAKE_CASE. Your client-side validation should enforce this before making API calls.

Creating a threat with STRIDE category

POST /threat-models/tm_9x8y7z6w/threats
Content-Type: application/json

{
  "title":          "Spoofed UPI callback from unverified merchant",
  "strideCategory": "SPOOFING",
  "description":    "Attacker sends forged UPI callback to simulate successful payment...",
  "componentId":    "comp_upi_callback_handler",
  "severity":       "HIGH",
  "likelihood":     "PROBABLE",
  "pastaStage":     5                        // Stage 5: Vulnerability Analysis
}

Regulatory Mapping

RiskSage automatically maps threat model findings to Indian regulatory requirements. The POST /threat-models/:id/regulatory-map endpoint generates mappings based on the threats and mitigations in the model.

Regulator	Framework	Requirement	Maps To
RBI	Threat Risk Assessment (TRA)	Annual TRA for critical applications	Threat model completeness, STRIDE coverage per component
SEBI	CSCRF SDLC	Threat modelling in SDLC for market infrastructure	PASTA stage completion, mitigation coverage ratio
IRDAI	IS Audit Guidelines	Application-level threat assessment	Component-level threat enumeration, risk acceptance documentation

POST /threat-models/tm_9x8y7z6w/regulatory-map
Content-Type: application/json

{
  "frameworks": ["RBI_TRA", "SEBI_CSCRF_SDLC", "IRDAI_IS_AUDIT"]
}

// Response 200
{
  "regulatoryMap": [
    {
      "framework":    "RBI_TRA",
      "controlRef":   "RBI.TRA.4.2",
      "requirement":  "Threat assessment for internet-facing applications",
      "status":       "COMPLIANT",
      "evidence":     "18 threats identified across 9 DFD components with STRIDE coverage"
    },
    {
      "framework":    "SEBI_CSCRF_SDLC",
      "controlRef":   "SEBI.SDLC.3.1",
      "requirement":  "Threat modelling during design phase",
      "status":       "GAP",
      "gap":          "PASTA Stage 7 (Risk & Impact Analysis) not completed"
    },
    {
      "framework":    "IRDAI_IS_AUDIT",
      "controlRef":   "IRDAI.APP.2.1",
      "requirement":  "Application-level threat enumeration",
      "status":       "COMPLIANT",
      "evidence":     "All EXTERNAL_ENTITY components have associated SPOOFING threats"
    }
  ]
}

PASTA 7-Stage Mapping

PASTA (Process for Attack Simulation and Threat Analysis) has 7 stages. RiskSage tracks completion of each stage within the threat model.

Stage	Name	API Field	Description
1	Definition of Objectives	`OBJECTIVES`	Business objectives, security requirements, compliance drivers
2	Definition of Technical Scope	`TECHNICAL_SCOPE`	System architecture, technology stack, DFD components
3	Application Decomposition	`DECOMPOSITION`	Trust boundaries, entry points, assets, data flows
4	Threat Analysis	`THREAT_ANALYSIS`	Threat actors, attack patterns, threat intelligence
5	Vulnerability Analysis	`VULNERABILITY_ANALYSIS`	Known CVEs, weakness enumeration, VAPT correlation
6	Attack Modelling	`ATTACK_MODELLING`	Attack trees, kill chains, exploitation scenarios
7	Risk & Impact Analysis	`RISK_IMPACT`	Residual risk, business impact, CRQ integration

PASTA + CRQ Integration Stage 7 (Risk & Impact Analysis) can be linked directly to a CRQ analysis via the crqAnalysisId field. This connects qualitative threat modelling to quantitative risk output — a powerful combination for board-level reporting.

See CRQ Engine Developer Guide →

Export Options

Export the complete threat model for stakeholder review or regulatory submission:

// Export as PDF (for board/audit submission)
GET /threat-models/tm_9x8y7z6w/export?format=pdf

// Export as JSON (for CI/CD integration)
GET /threat-models/tm_9x8y7z6w/export?format=json

// Response headers for PDF:
Content-Type: application/pdf
Content-Disposition: attachment; filename="threat-model-tm_9x8y7z6w.pdf"

STRIDE + PASTA Threat Modelling API Guide

11 Routes Overview

Single-Endpoint Detail Pattern

Enum Exactness

STRIDE Threat Categories

DFD Component Types

Creating a threat with STRIDE category

Regulatory Mapping

PASTA 7-Stage Mapping

Export Options

Found this useful?

Related Guides