// Analyze a repository's architecture and codebase to produce a structured threat model. Use when the user wants to identify security risks, create a threat model, assess attack surface, enumerate threats, or document security concerns for their project. Creates a THREAT_MODEL.md in the .pensar folder.
| name | repository-threat-model |
| description | Analyze a repository's architecture and codebase to produce a structured threat model. Use when the user wants to identify security risks, create a threat model, assess attack surface, enumerate threats, or document security concerns for their project. Creates a THREAT_MODEL.md in the .pensar folder. |
Analyze the repository's architecture, data flows, trust boundaries, and external integrations to produce a comprehensive threat model. The output is a .pensar/THREAT_MODEL.md file that documents assets, threat actors, attack surfaces, identified threats (using STRIDE), risk ratings, and recommended mitigations.
Copy this checklist and track progress:
Task Progress:
- [ ] Step 1: Analyze the codebase
- [ ] Step 2: Identify assets and trust boundaries
- [ ] Step 3: Map attack surfaces
- [ ] Step 4: Enumerate threats using STRIDE
- [ ] Step 5: Assess risk and prioritize
- [ ] Step 6: Write .pensar/THREAT_MODEL.md
Explore the repository thoroughly to build a mental model of the system. Gather:
Where to look:
| What | Where to check |
|---|---|
| Entry points | Route definitions, controller files, main.*, app.*, server.*, API directories |
| Auth | Middleware folders, auth modules, passport/guard configs, JWT utilities |
| Data models | ORM models, schema files, migration directories, GraphQL type definitions |
| Secrets | .env.example, .env.sample, config files, secret manager references, process.env / os.environ usage |
| External calls | HTTP client usage (fetch, axios, requests, http.Client), SDK imports |
| Infra | Dockerfile, docker-compose.yml, *.tf, *.yaml in deploy/infra directories, CI configs |
| Dependencies | package.json, requirements.txt, go.mod, Gemfile, Cargo.toml — note security-sensitive packages |
Based on the analysis, identify:
Assets — things of value that need protection:
Trust boundaries — lines where the level of trust changes:
Draw these as a simple text diagram if the architecture is complex enough to warrant it.
For each entry point and trust boundary, document the attack surface:
For each significant attack surface, apply the STRIDE model to systematically identify threats:
| Category | Question to ask |
|---|---|
| Spoofing | Can an attacker impersonate a user, service, or component? |
| Tampering | Can an attacker modify data in transit, at rest, or in processing? |
| Repudiation | Can actions be performed without adequate logging/audit trails? |
| Information Disclosure | Can sensitive data leak through errors, logs, APIs, or side channels? |
| Denial of Service | Can an attacker exhaust resources or make the service unavailable? |
| Elevation of Privilege | Can an attacker gain unauthorized access to higher-privilege operations? |
Focus on concrete, codebase-specific threats, not generic ones. Reference actual files, routes, or patterns found during analysis. For example:
/api/users/:id endpoint does not verify the authenticated user owns the requested resource (IDOR) — see routes/users.js:45"config/auth.ts:12 rather than loaded from environment"/api/upload does not validate file type or size — see controllers/upload.js"models/search.js use string concatenation instead of parameterized queries"Rate each identified threat using a simple risk matrix:
Likelihood: How easy is it to exploit?
Impact: What's the damage if exploited?
Risk rating: Combine likelihood and impact:
| Impact: Critical | Impact: High | Impact: Medium | Impact: Low | |
|---|---|---|---|---|
| Likelihood: High | Critical | Critical | High | Medium |
| Likelihood: Medium | Critical | High | Medium | Low |
| Likelihood: Low | High | Medium | Low | Low |
For each threat, also note a recommended mitigation — be specific and actionable, referencing libraries, patterns, or code changes.
Create the .pensar directory if it doesn't exist, then write .pensar/THREAT_MODEL.md with the following structure:
# Threat Model
> Auto-generated threat model for [repository name]. Last updated: [date].
## System Overview
[2-3 paragraph summary of the application: what it does, its architecture, tech stack, and deployment model]
### Architecture Diagram
\`\`\`
[Simple text/ASCII diagram showing major components, data flows, and trust boundaries]
\`\`\`
## Assets
| Asset | Description | Sensitivity |
|-------|-------------|-------------|
| [e.g., User credentials] | [What it is] | [Critical/High/Medium/Low] |
## Trust Boundaries
| Boundary | From | To | Controls |
|----------|------|----|----------|
| [e.g., API Gateway] | [Public internet] | [App server] | [TLS, rate limiting] |
## Attack Surfaces
| Surface | Entry Point | Auth Required | Data Exposed |
|---------|-------------|---------------|--------------|
| [e.g., REST API] | [/api/*] | [Mixed] | [User data, app data] |
## STRIDE Analysis
### Spoofing
| ID | Threat | Affected Component | Risk | Mitigation |
|----|--------|--------------------|------|------------|
| S-1 | [Description] | [File/component] | [Critical/High/Medium/Low] | [Specific fix] |
### Tampering
| ID | Threat | Affected Component | Risk | Mitigation |
|----|--------|--------------------|------|------------|
| T-1 | [Description] | [File/component] | [Critical/High/Medium/Low] | [Specific fix] |
### Repudiation
| ID | Threat | Affected Component | Risk | Mitigation |
|----|--------|--------------------|------|------------|
| R-1 | [Description] | [File/component] | [Critical/High/Medium/Low] | [Specific fix] |
### Information Disclosure
| ID | Threat | Affected Component | Risk | Mitigation |
|----|--------|--------------------|------|------------|
| I-1 | [Description] | [File/component] | [Critical/High/Medium/Low] | [Specific fix] |
### Denial of Service
| ID | Threat | Affected Component | Risk | Mitigation |
|----|--------|--------------------|------|------------|
| D-1 | [Description] | [File/component] | [Critical/High/Medium/Low] | [Specific fix] |
### Elevation of Privilege
| ID | Threat | Affected Component | Risk | Mitigation |
|----|--------|--------------------|------|------------|
| E-1 | [Description] | [File/component] | [Critical/High/Medium/Low] | [Specific fix] |
## Risk Summary
| Risk Level | Count | IDs |
|------------|-------|-----|
| Critical | [n] | [list] |
| High | [n] | [list] |
| Medium | [n] | [list] |
| Low | [n] | [list] |
## Methodology
This threat model was generated by analyzing the repository structure, source code, configuration files, and dependencies. Threats were identified using the [STRIDE](https://en.wikipedia.org/wiki/STRIDE_%28security%29) framework and assessed using a likelihood × impact risk matrix.
Important guidelines for the output:
| Problem | Fix |
|---|---|
| Repository is too large to fully analyze | Focus on entry points (routes, controllers, API handlers), auth modules, and data access layers first. Expand from there. |
| Cannot determine the tech stack | Check dependency manifests (package.json, requirements.txt, etc.), file extensions, and import statements |
| No clear entry points found | Look for main functions, app.* files, server.* files, route registrations, or framework-specific patterns (e.g., @app.route in Flask, router.get in Express) |
| Project is a library, not an application | Focus on: input validation of public API, dependency risks, potential for prototype pollution / injection if processing user data, and documentation of security considerations for consumers |
.pensar directory conflicts with existing files | Check if .pensar already exists; if so, update the existing THREAT_MODEL.md rather than overwriting other files in the directory |
AI-powered penetration testing and vulnerability scanning with the Pensar Apex CLI. Use for security scanning, pentesting, reviewing findings, or fixing vulnerabilities.
Dockerize an application with docker-compose, including all services, databases, and data seeding. Use when the user wants to containerize their app, create a docker-compose setup, set up a reproducible dev environment, or prepare the project for sandbox/agent use.
