florianbuetow 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
| ID | Component | Function | Trust Level | Auth Mechanism |
|----|-----------|----------|-------------|---------------|
| C-01 | Auth Service | Login, registration, JWT | High | N/A (is the auth) |
| C-02 | API Gateway | Request routing | Medium | JWT validation |
| C-03 | Payment Module | Charge processing | High | JWT + role check |
### Role-Permission Matrix
| Role | C-01 Auth | C-02 API | C-03 Payment | C-04 Admin |
|------|----------|---------|-------------|-----------|
| Anonymous | register, login | public endpoints | none | none |
| User | profile, logout | CRUD own data | pay, history | none |
| Admin | manage users | all endpoints | refunds | full access |
### Data Classification
| Data Entity | Classification | Components | Encrypted Rest/Transit |
|------------|---------------|------------|----------------------|
| Credentials | Restricted | Auth Service | Hashed / TLS |
| Payment tokens | Restricted | Payment | Yes / TLS |
### Trust Boundaries
| Boundary | From | To | Mechanism | Validated |
|----------|------|----|-----------|-----------|
| TB-01 | Internet | API Gateway | HTTPS | TLS |
| TB-02 | Gateway | Auth Service | Internal HTTP | JWT |
### 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.