Discover a codebase's threat surface through systematic investigation — map ecosystem groups, dependency graphs, service connections, authentication mechanisms, and trust boundaries. Use when performing threat modeling, security review, or architectural analysis of any multi-ecosystem repository.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
Discover a codebase's threat surface through systematic investigation — map ecosystem groups, dependency graphs, service connections, authentication mechanisms, and trust boundaries. Use when performing threat modeling, security review, or architectural analysis of any multi-ecosystem repository.
tier
standard
applyTo
**/*threat*,**/*surface*,**/*analysis*
currency
2026-04-30T00:00:00.000Z
lastReviewed
2026-04-30T00:00:00.000Z
Threat Surface Analysis
Systematic codebase investigation to discover the attack surface — services, dependencies, authentication, and trust boundaries. Language-agnostic, works across any ecosystem.
When to Use
Security review of a new or unfamiliar codebase
Threat modeling preparation (discovering what to model)
Architecture discovery for legacy systems
Identifying external service connections and auth mechanisms
Finding unprotected endpoints or misconfigured trust boundaries
Core Principles
Intent-based classification — classify by runtime purpose and behavior, not project name
Evidence, not conclusions — record what was found; defer interpretation
Unknowns are valuable — "Auth: Unknown" is better than guessing
Source projects are anchors — entry points (web apps, functions, CLIs) become threat surfaces. Libraries are invisible.
Config flows DOWN — a source project's config covers all its library dependencies
Phase 1: Ecosystem Detection
Discover all programming languages, build systems, and infrastructure-as-code in the repository.
Procedure (aim for ~5 tool calls)
List workspace root — one level deep
Scan for manifests using the table below (1–2 calls)
Identify ecosystem groups — a repo may contain multiple (e.g., .NET + React + Terraform)
Read workspace descriptors — .sln, package.json workspaces, go.work, etc.
Form hypothesis — 2–3 sentences on what the system does
Manifest → Ecosystem Mapping
Manifest Pattern
Ecosystem
*.sln, *.csproj, *.fsproj
.NET
package.json
Node.js / TypeScript
go.mod
Go
pyproject.toml, requirements.txt, Pipfile
Python
pom.xml, build.gradle, build.gradle.kts
Java / Kotlin
Cargo.toml
Rust
Gemfile
Ruby
*.bicep, *.tf, *.tfvars
Infrastructure as Code
docker-compose.yml, Dockerfile
Container / Docker
azure-pipelines.yml, .github/workflows/*.yml
CI/CD Pipeline
Output
## Ecosystem Groups
Group 1: <Ecosystem>
Workspace descriptor: <path>
Projects: <list>
Dependency format: <e.g., PackageReference in .csproj>
Config patterns: <e.g., appsettings.json>
Shared / Cross-cutting:
IaC files: <list>
CI/CD files: <list>
Phase 2: Project Classification
Classify every project by type and assign preliminary trust boundaries.
Classification Priority (first match wins)
Priority
Signal
ProjectType
1
Test framework dependency (xunit, jest, pytest, etc.)
Test (exclude)
2
HTTP server framework (Express, ASP.NET, Flask, etc.)
WebApplication
2
Serverless function framework
FunctionApp
2
Background worker / task processor
WorkerService
2
Client-side SPA (React, Angular, Blazor WASM)
ClientApp
2
gRPC server
GrpcService
3
Produces executable + CLI entrypoint
ConsoleApplication
4
No executable output, exports only
Library
Trust Boundary Defaults
Deployment Pattern
Trust Boundary
Cloud-hosted (Azure, AWS, GCP)
Cloud
Runs locally / dev tooling
On-Premises
CI/CD pipeline tooling
DevOps
Client-side / browser
Client
Source vs Library Rule
Source projects = entry points (web apps, functions, CLIs, workers). These become threat-surface components.
Libraries = internal code compiled into source projects. Not standalone components.
Transitive dependency rule: SourceProject → Library → SDK → External Service. Only the SourceProject and External Service matter for threat modeling.
Phase 3: Code Investigation
Produce a structured evidence artifact identifying services, dependencies, and authentication.