Codebase Analysis
You are performing the first phase of a security assessment. Your goal is to deeply understand the codebase. You are NOT looking for specific vulnerabilities yet. This is pure reconnaissance.
Create a sast/ folder in the project root (if it doesn't already exist). This phase produces one output file inside it:
sast/architecture.md — technology stack, architecture, entry points, data flows
Phase 1: Technology Reconnaissance
Explore the codebase and identify:
- Languages: All programming languages used and their versions if specified
- Frameworks: Web frameworks, ORM layers, template engines, task queues
- Package managers & dependencies: Lock files, dependency manifests (package.json, requirements.txt, go.mod, Gemfile, pom.xml, etc.)
- Infrastructure hints: Dockerfiles, docker-compose, Kubernetes manifests, Terraform, CI/CD configs
- Databases: SQL, NoSQL, cache layers, message brokers — look at connection strings, ORM models, migration files
- Authentication & authorization: Auth libraries, middleware, session configs, OAuth/OIDC providers, JWT usage, API key patterns
- External integrations: Third-party APIs, payment processors, email services, cloud SDKs, webhook handlers
- Entry points: HTTP routes, GraphQL schemas, gRPC service definitions, CLI commands, WebSocket handlers, scheduled jobs, message consumers
Start by reading dependency manifests, project configs, and directory structure. Then drill into source code to confirm findings.
Phase 2: Architecture Mapping
Based on Phase 1, build a mental model of:
- Service boundaries: Is this a monolith or microservices? What talks to what?
- Data flow: How does user input enter the system, get processed, get stored, and get returned?
- Trust boundaries: Where does the system transition between trusted and untrusted contexts? (e.g., user input -> backend, backend -> database, service -> service, server -> client)
- Privilege levels: What roles/permissions exist? How are they enforced? Is there an admin panel?
- Sensitive data inventory: PII, credentials, tokens, financial data, health records — where is each stored and how does it move?
Write the results of Phase 1 and Phase 2 to sast/architecture.md. Use this format:
# Architecture: [Project Name]
## Technology Stack
| Category | Details |
|---|---|
| Languages | ... |
| Frameworks | ... |
| Databases | ... |
| Auth mechanism | ... |
| Infrastructure | ... |
| External services | ... |
## Architecture Overview
[Describe the architecture: monolith vs microservices, how components interact,
main modules and their responsibilities]
## Data Flow
[Trace how user input enters the system, gets processed, stored, and returned.
Cover the primary flows (e.g., registration, login, core business actions).]
## Entry Points
| Entry Point | Type | Auth Required | Description |
|---|---|---|---|
| ... | HTTP/GraphQL/WS/etc. | Yes/No | ... |
## Trust Boundaries
[List each trust boundary and what crosses it]
## Sensitive Data Inventory
| Data Type | Where Stored | How Accessed | Protection |
|---|---|---|---|
| ... | ... | ... | ... |
Important Reminders
- Do NOT report specific vulnerabilities (like "line 42 has SQL injection"). That comes in later phases.
- Be thorough in exploration. Read actual source code, not just config files. Look at how auth middleware is applied, how queries are built, how file uploads are handled.
- If the codebase is large, prioritize security-sensitive areas: auth, payment, data access, file handling, admin functionality.
1---2name: sast-analysis3description: Perform codebase analysis and architecture mapping as the first phase of a security assessment. Explores the tech stack, frameworks, entry points, data flows, and trust boundaries. Outputs sast/architecture.md. Run this before any vulnerability detection skill. Use when asked to analyze a codebase for security or when sast/architecture.md does not yet exist.4---5
6# Codebase Analysis
7
8You are performing the first phase of a security assessment. Your goal is to deeply understand the codebase. You are NOT looking for specific vulnerabilities yet. This is pure reconnaissance.
9
10Create a `sast/` folder in the project root (if it doesn't already exist). This phase produces one output file inside it:
11
12`sast/architecture.md` — technology stack, architecture, entry points, data flows
13
14## Phase 1: Technology Reconnaissance
15
16Explore the codebase and identify:
17
18- **Languages**: All programming languages used and their versions if specified
19- **Frameworks**: Web frameworks, ORM layers, template engines, task queues
20- **Package managers & dependencies**: Lock files, dependency manifests (package.json, requirements.txt, go.mod, Gemfile, pom.xml, etc.)
21- **Infrastructure hints**: Dockerfiles, docker-compose, Kubernetes manifests, Terraform, CI/CD configs
22- **Databases**: SQL, NoSQL, cache layers, message brokers — look at connection strings, ORM models, migration files
23- **Authentication & authorization**: Auth libraries, middleware, session configs, OAuth/OIDC providers, JWT usage, API key patterns
24- **External integrations**: Third-party APIs, payment processors, email services, cloud SDKs, webhook handlers
25- **Entry points**: HTTP routes, GraphQL schemas, gRPC service definitions, CLI commands, WebSocket handlers, scheduled jobs, message consumers
26
27Start by reading dependency manifests, project configs, and directory structure. Then drill into source code to confirm findings.
28
29## Phase 2: Architecture Mapping
30
31Based on Phase 1, build a mental model of:
32
331. **Service boundaries**: Is this a monolith or microservices? What talks to what?
342. **Data flow**: How does user input enter the system, get processed, get stored, and get returned?
353. **Trust boundaries**: Where does the system transition between trusted and untrusted contexts? (e.g., user input -> backend, backend -> database, service -> service, server -> client)
364. **Privilege levels**: What roles/permissions exist? How are they enforced? Is there an admin panel?
375. **Sensitive data inventory**: PII, credentials, tokens, financial data, health records — where is each stored and how does it move?
38
39**Write the results of Phase 1 and Phase 2 to `sast/architecture.md`.** Use this format:
40
41```markdown
42# Architecture: [Project Name]
43
44## Technology Stack
45
46| Category | Details |
47|---|---|
48| Languages | ... |
49| Frameworks | ... |
50| Databases | ... |
51| Auth mechanism | ... |
52| Infrastructure | ... |
53| External services | ... |
54
55## Architecture Overview
56
57[Describe the architecture: monolith vs microservices, how components interact,
58main modules and their responsibilities]
59
60## Data Flow
61
62[Trace how user input enters the system, gets processed, stored, and returned.
63Cover the primary flows (e.g., registration, login, core business actions).]
64
65## Entry Points
66
67| Entry Point | Type | Auth Required | Description |
68|---|---|---|---|
69| ... | HTTP/GraphQL/WS/etc. | Yes/No | ... |
70
71## Trust Boundaries
72
73[List each trust boundary and what crosses it]
74
75## Sensitive Data Inventory
76
77| Data Type | Where Stored | How Accessed | Protection |
78|---|---|---|---|
79| ... | ... | ... | ... |
80```
81
82## Important Reminders
83
84- Do NOT report specific vulnerabilities (like "line 42 has SQL injection"). That comes in later phases.
85- Be thorough in exploration. Read actual source code, not just config files. Look at how auth middleware is applied, how queries are built, how file uploads are handled.
86- If the codebase is large, prioritize security-sensitive areas: auth, payment, data access, file handling, admin functionality.
aibot88