sast-analysis

Name: sast-analysis
Author: utkusen

40installs56forks

How to install sast-analysis?

utkusen/sast-skills/sast-analysis

$npx -y skills add utkusen/sast-skills --skill sast-analysis

Installs into the current project.

Summary

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

Files · 1

View on GitHub

SKILL.md

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

People who liked this also viewed

6 picks

Type

sast-analysis

40installs56forks

View on GitHub

How to install sast-analysis?

utkusen/sast-skills/sast-analysis

$npx -y skills add utkusen/sast-skills --skill sast-analysis

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

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

People who liked this also viewed

6 picks

Type