PASTA Stage 2: Define Technical Scope
Map the technical boundaries of the system -- architecture, protocols, entry
points, and attack surface. Build data flow diagrams (DFDs) showing how data
moves through the system and where trust boundaries exist.
Supported Flags
Read ../../shared/schemas/flags.md for the full flag specification. Key behaviors:
| Flag |
Stage 2 Behavior |
--scope |
Default changed. Scans routes, API specs, Dockerfiles, IaC, and network configs. |
--depth quick |
Entry points from route definitions and API specs only. |
--depth standard |
Full entry point scan + dependency catalog + protocol identification. |
--depth deep |
Standard + infrastructure analysis (Docker, K8s, Terraform) + network boundary mapping. |
--depth expert |
Deep + complete DFD with trust levels annotated on every data flow. |
--severity |
Not applicable at this stage. |
Framework Context
Read ../../shared/frameworks/pasta.md, Stage 2 section. PASTA is SEQUENTIAL.
Stage 2 consumes Stage 1 output and feeds Stage 3.
Prerequisites
Required: Stage 1 output -- business-critical assets, compliance requirements,
and risk tolerance thresholds. If unavailable, warn and proceed with assumptions.
Workflow
Step 1: Determine Scope
Parse --scope flag (default: changed). Prioritize: route files, controllers,
API gateway configs, Dockerfiles, docker-compose.yml, K8s manifests, Terraform,
nginx configs, OpenAPI/Swagger specs, GraphQL schemas.
Step 2: Enumerate Entry Points
Scan for all data ingress paths:
- HTTP/REST: Express routes, FastAPI paths, Spring
@RequestMapping, Django URLs.
- GraphQL: Schemas, resolvers, mutations, subscriptions.
- WebSocket: Socket.io handlers, WS endpoints.
- Message queues: RabbitMQ, Kafka, SQS, Redis pub/sub consumers.
- File uploads: Multipart handlers, S3 presigned URLs.
- Webhooks: Incoming receivers from third-party services.
- CLI/Scheduled: Admin consoles, cron tasks, Lambda triggers, workers.
Step 3: Map External Dependencies
Catalog outbound connections: third-party APIs (payment, auth, email), databases,
caches (Redis, Memcached), cloud services (S3, SQS, Pub/Sub), and package
dependencies from manifest files.
Step 4: Identify Network Boundaries
- Internet-facing vs. internal services.
- Network segmentation (VPCs, security groups, firewalls).
- Container orchestration (Docker networks, K8s namespaces, service meshes).
- CDN/proxy layers (Cloudflare, nginx, API gateways, load balancers).
- Legacy/deprecated endpoints still reachable.
Step 5: Build Data Flow Diagram
Construct a textual DFD: external entities, processes, data stores, data flows
with protocol labels, and trust boundary lines.
Analysis Checklist
- What are all the ways data enters and exits this system?
- Which components are internet-facing vs. internal-only?
- What third-party services does the application depend on?
- What protocols and ports are exposed?
- Are there deprecated endpoints still reachable?
- What is the deployment topology (monolith, microservices, serverless)?
- Are there admin or debug endpoints exposed in production?
- What authentication mechanisms protect each entry point?
Output Format
Stage 2 produces a Technical Scope Document with DFD. ID prefix: PASTA (e.g., PASTA-S2-001).
## PASTA Stage 2: Technical Scope
### Technology Stack
| Layer | Technology | Version |
|-------|-----------|---------|
| Language / Framework / Database / Cache / Deployment | ... | ... |
### Entry Points
| ID | Type | Path/Handler | Auth Required | Protocol |
|----|------|-------------|---------------|----------|
| EP-01 | REST API | POST /api/users | No | HTTPS |
| EP-02 | WebSocket | /ws/chat | Yes (JWT) | WSS |
### External Dependencies
| Service | Purpose | Data Exchanged | Protocol |
|---------|---------|---------------|----------|
| Stripe | Payments | Card tokens | HTTPS |
### Data Flow Diagram
User --> [API Gateway] --> [Auth] --> [App Server] --> [Database]
Trust Boundaries:
- Internet | DMZ: User to API Gateway
- DMZ | Internal: API Gateway to App Server
- App | Data: App Server to Database
### Attack Surface Summary
| Surface | Entry Points | Internet-Facing | Auth Required |
|---------|-------------|-----------------|---------------|
| REST API | N | Yes | Mixed |
Findings follow ../../shared/schemas/findings.md with:
metadata.tool: "pasta-scope", metadata.framework: "pasta", metadata.category: "Stage-2"
Next Stage
Stage 3: Application Decomposition (pasta-decompose). Pass entry points,
DFD, dependencies, and network boundaries. Stage 3 decomposes into components,
maps trust boundaries, and catalogs roles and permissions.
1---2name: pasta-scope3description: This skill should be used when the user asks to "define technical scope", "map attack surface", "identify entry points", "build a data flow diagram", or is running PASTA stage 2. Also triggers when the user asks about DFDs, network boundaries, external dependencies, or deployment topology in a threat modeling context. Part of the PASTA threat modeling methodology (Stage 2 of 7).4---56# PASTA Stage 2: Define Technical Scope78Map the technical boundaries of the system -- architecture, protocols, entry9points, and attack surface. Build data flow diagrams (DFDs) showing how data10moves through the system and where trust boundaries exist.1112## Supported Flags1314Read `../../shared/schemas/flags.md` for the full flag specification. Key behaviors:1516| Flag | Stage 2 Behavior |17|------|------------------|18| `--scope` | Default `changed`. Scans routes, API specs, Dockerfiles, IaC, and network configs. |19| `--depth quick` | Entry points from route definitions and API specs only. |20| `--depth standard` | Full entry point scan + dependency catalog + protocol identification. |21| `--depth deep` | Standard + infrastructure analysis (Docker, K8s, Terraform) + network boundary mapping. |22| `--depth expert` | Deep + complete DFD with trust levels annotated on every data flow. |23| `--severity` | Not applicable at this stage. |2425## Framework Context2627Read `../../shared/frameworks/pasta.md`, Stage 2 section. PASTA is SEQUENTIAL.28Stage 2 consumes Stage 1 output and feeds Stage 3.2930## Prerequisites3132**Required**: Stage 1 output -- business-critical assets, compliance requirements,33and risk tolerance thresholds. If unavailable, warn and proceed with assumptions.3435## Workflow3637### Step 1: Determine Scope3839Parse `--scope` flag (default: `changed`). Prioritize: route files, controllers,40API gateway configs, Dockerfiles, `docker-compose.yml`, K8s manifests, Terraform,41nginx configs, OpenAPI/Swagger specs, GraphQL schemas.4243### Step 2: Enumerate Entry Points4445Scan for all data ingress paths:461. **HTTP/REST**: Express routes, FastAPI paths, Spring `@RequestMapping`, Django URLs.472. **GraphQL**: Schemas, resolvers, mutations, subscriptions.483. **WebSocket**: Socket.io handlers, WS endpoints.494. **Message queues**: RabbitMQ, Kafka, SQS, Redis pub/sub consumers.505. **File uploads**: Multipart handlers, S3 presigned URLs.516. **Webhooks**: Incoming receivers from third-party services.527. **CLI/Scheduled**: Admin consoles, cron tasks, Lambda triggers, workers.5354### Step 3: Map External Dependencies5556Catalog outbound connections: third-party APIs (payment, auth, email), databases,57caches (Redis, Memcached), cloud services (S3, SQS, Pub/Sub), and package58dependencies from manifest files.5960### Step 4: Identify Network Boundaries61621. Internet-facing vs. internal services.632. Network segmentation (VPCs, security groups, firewalls).643. Container orchestration (Docker networks, K8s namespaces, service meshes).654. CDN/proxy layers (Cloudflare, nginx, API gateways, load balancers).665. Legacy/deprecated endpoints still reachable.6768### Step 5: Build Data Flow Diagram6970Construct a textual DFD: external entities, processes, data stores, data flows71with protocol labels, and trust boundary lines.7273## Analysis Checklist74751. What are all the ways data enters and exits this system?762. Which components are internet-facing vs. internal-only?773. What third-party services does the application depend on?784. What protocols and ports are exposed?795. Are there deprecated endpoints still reachable?806. What is the deployment topology (monolith, microservices, serverless)?817. Are there admin or debug endpoints exposed in production?828. What authentication mechanisms protect each entry point?8384## Output Format8586Stage 2 produces a **Technical Scope Document** with DFD. ID prefix: **PASTA** (e.g., `PASTA-S2-001`).8788```89## PASTA Stage 2: Technical Scope9091### Technology Stack92| Layer | Technology | Version |93|-------|-----------|---------|94| Language / Framework / Database / Cache / Deployment | ... | ... |9596### Entry Points97| ID | Type | Path/Handler | Auth Required | Protocol |98|----|------|-------------|---------------|----------|99| EP-01 | REST API | POST /api/users | No | HTTPS |100| EP-02 | WebSocket | /ws/chat | Yes (JWT) | WSS |101102### External Dependencies103| Service | Purpose | Data Exchanged | Protocol |104|---------|---------|---------------|----------|105| Stripe | Payments | Card tokens | HTTPS |106107### Data Flow Diagram108User --> [API Gateway] --> [Auth] --> [App Server] --> [Database]109Trust Boundaries:110- Internet | DMZ: User to API Gateway111- DMZ | Internal: API Gateway to App Server112- App | Data: App Server to Database113114### Attack Surface Summary115| Surface | Entry Points | Internet-Facing | Auth Required |116|---------|-------------|-----------------|---------------|117| REST API | N | Yes | Mixed |118```119120Findings follow `../../shared/schemas/findings.md` with:121- `metadata.tool`: `"pasta-scope"`, `metadata.framework`: `"pasta"`, `metadata.category`: `"Stage-2"`122123## Next Stage124125**Stage 3: Application Decomposition** (`pasta-decompose`). Pass entry points,126DFD, dependencies, and network boundaries. Stage 3 decomposes into components,127maps trust boundaries, and catalogs roles and permissions.
florianbuetow