PASTA Stage 3: Application Decomposition

Break the application into its constituent components and analyze trust boundaries, user roles, privilege levels, and data sensitivity at each layer. This produces the component map that Stages 4-7 use to identify where threats and attacks focus.

Supported Flags

Read ../../shared/schemas/flags.md for the full flag specification. Key behaviors:

Flag Stage 3 Behavior

--scope

Default changed . Scans middleware, auth modules, role definitions, permission configs, database schemas.

--depth quick

Component inventory from project structure and imports only.

--depth standard

Full decomposition + role-permission matrix + data classification.

--depth deep

Standard + cross-component data flows, inter-service auth, shared resource access patterns.

--depth expert

Deep + formal trust boundary analysis with privilege escalation path mapping.

--severity

Not applicable at this stage.

Framework Context

Read ../../shared/frameworks/pasta.md , Stage 3 section. PASTA is SEQUENTIAL. Stage 3 consumes Stage 2 output and feeds Stage 4.

Prerequisites

Required: Stage 2 output -- entry point inventory, DFD, technology stack, and external dependencies. If unavailable, warn and proceed with assumptions.

Workflow

Step 1: Determine Scope

Parse --scope flag (default: changed ). Prioritize: middleware, auth modules, role/permission definitions, policy files (RBAC, ABAC, ACL), database schemas, service definitions, module boundaries.

Step 2: Identify Components

Decompose into functional units: authentication, authorization, core business logic, data access layer, API layer, background processing, admin/management, integration layer (third-party clients, webhooks), and infrastructure (logging, caching, sessions).

Step 3: Map Roles and Permissions

For each component: identify user roles (anonymous, authenticated, admin, service account), permission model (RBAC/ABAC/ACL), enforcement location (middleware, decorators, inline), default permissions, and permission gaps.

Step 4: Map Trust Boundaries

Identify where trust levels change: external-to-app, unauthenticated-to-authenticated, user-to-admin, service-to-service (mTLS, API keys, JWT), app-to-datastore, and app-to-third-party.

Step 5: Classify Data

For each data entity: Public (marketing, public APIs), Internal (analytics, internal docs), Confidential (PII, credentials, tokens), Restricted (payment data, health records, encryption keys).

Step 6: Document Auth/Authz Flows

Trace end-to-end: credential validation, session/token issuance, per-request permission checks, and bypass paths (debug endpoints, feature flags, test accounts).

Analysis Checklist

• What trust boundaries does data cross between components?

• Which components run with elevated privileges?

• How are service-to-service calls authenticated?

• Where does data sensitivity change (encryption, masking, aggregation)?

• Are there shared databases or caches across trust boundaries?

• What is the default permission level for new users or services?

• Are there components that lack authorization checks entirely?

• Do admin interfaces share authentication with user-facing interfaces?

Output Format

Stage 3 produces a Component Inventory with Trust Boundaries. ID prefix: PASTA (e.g., PASTA-S3-001 ).

PASTA Stage 3: Application Decomposition

Component Inventory

Role-Permission Matrix

Data Classification

Trust Boundaries

Authorization Gaps

[Components or endpoints without proper authorization enforcement]

Findings follow ../../shared/schemas/findings.md with:

• metadata.tool : "pasta-decompose" , metadata.framework : "pasta" , metadata.category : "Stage-3"

Next Stage

Stage 4: Threat Analysis (pasta-threats ). Pass the Component Inventory, Role-Permission Matrix, Data Classification, and Trust Boundaries. Stage 4 cross-references with real-world threat intelligence to identify relevant threats.