Source-Sink Security Analysis

Launch these four agents simultaneously:

Agent 1 -- Entry Points & Event Handlers: Find all places untrusted data enters the system:

• HTTP route handlers, WebSocket endpoints, GraphQL resolvers
• Message queue consumers, event listeners, webhook handlers
• CLI argument parsers, stdin readers
• File upload handlers, form processors
• SSE/streaming endpoints
• For each: list every field extracted from the payload and whether it's validated

Agent 2 -- Execution Sinks & Dangerous Functions: Find all sensitive execution points:

• subprocess, exec, eval, os.system, os.popen, shell=True
• Template rendering (Jinja2, Mako, Mustache -- check autoescape settings)
• SQL/query construction (raw queries, ORMs with raw(), string interpolation)
• LLM prompt assembly (f-strings, concatenation, template rendering into prompts)
• File operations with user-controlled paths (open, write, mkdir, symlink)
• URL construction for HTTP requests (SSRF vectors)
• Deserialization (pickle, yaml.load vs safe_load, JSON with custom decoders)
• Log statements with user-controlled data
• For each: note what protection exists at the sink itself

Agent 3 -- Client Layer & External Integrations: Find all API clients and external communication:

• HTTP clients: how are URLs constructed? Are headers/params user-controlled?
• Authentication: how are credentials stored, passed, rotated?
• API response handling: is response data trusted? Does it flow back to prompts or UI?
• CORS configuration, CSP headers, cookie settings
• WebSocket message handling and deserialization
• For each: note authentication, input validation, and whether responses are trusted

Agent 4 -- Config, Secrets & Sandbox Layer: Find all configuration and privilege boundaries:

• Config file loading (YAML, JSON, TOML -- safe parsing?)
• Secret/credential management (env vars, secret managers, key files)
• Sandbox/isolation mechanisms (containers, namespaces, seccomp, capability drops)
• Template rendering for config (Jinja2 in config files -- SSTI risk?)
• Permission checks, RBAC enforcement, middleware chains
• Rate limiting, input size limits, timeout enforcement
• For each: note trust assumptions and bypass potential

Phase 2: Trace Flows

For each source discovered in Phase 1, trace data through every function call to every reachable sink. This is where most of the analysis time should go.

For each flow, document:

1. Source: What untrusted data enters and where (file:line)
2. Path: Every function the data passes through, noting transformations
3. Validation checkpoints: What escaping/sanitization exists at each step
4. Sink: Where the data is ultimately consumed (file:line)
5. Gap analysis: What validation is MISSING

Pay special attention to these commonly-missed patterns:

• Metadata injection: User display names, filenames, MIME types, email addresses flowing into prompts or templates without escaping
• Indirect injection: Tool/API results containing attacker-controlled content flowing back into trusted contexts (e.g., Jira issue descriptions → LLM conversation history)
• Option injection: User-controlled strings passed as CLI arguments that could be interpreted as flags (e.g., --help, -X POST)
• Partial escaping: Escaping that covers some characters but not all relevant ones for the sink context
• Cross-boundary flows: Data that crosses trust boundaries (e.g., user input → config → template → shell)
• Log injection: Untrusted data in structured logs that could break log parsers or inject false entries
• TOCTOU: Time-of-check-to-time-of-use gaps between validation and use
• Path traversal: User-controlled strings in file paths, even after partial sanitization
• Deserialization gadgets: Untrusted data deserialized into objects that trigger side effects

Phase 3: Classify and Prioritize

Rate each flow using this matrix:

For each vulnerability, also assess:

• Likelihood: How likely is exploitation? (requires auth? requires specific config? requires compromising another system first?)
• Blast radius: What's the worst case if exploited? (RCE in sandbox vs. RCE on host vs. data exfiltration vs. DoS)
• Existing mitigations: What defenses already exist? (sandboxing, approval gates, rate limits)
• Residual risk: After mitigations, what risk remains?

Phase 4: Produce Report

Generate a single comprehensive markdown document with this structure:

# Source-Sink Security Analysis: {Project Name}

## 1. Executive Summary
- Total sources/sinks/flows analyzed
- Critical/High/Medium/Low finding counts
- Top 3 priority items

## 2. Master Attack Surface Map
- Mermaid flowchart: all sources → transformations → sinks
- Color-coded by severity

## 3. Source Classification
| Source | Controller | Trust Level | Entry Point | Section |
(table of all untrusted input sources)

## 4. Sink Classification
| Sink | Impact if Compromised | Protection Level | Section |
(table of all sensitive sinks)

## 5-N. Detailed Flow Analysis
One section per flow, containing:
- Trace (source → each hop with file:line → sink)
- Code snippets for critical points
- Escaping/validation analysis
- Injection vectors (with proof-of-concept payloads where applicable)
- Mitigating factors
- Residual risk assessment
- Mermaid diagram for complex flows

## N+1. Risk Assessment
- Mermaid quadrantChart (likelihood vs impact)
- Full vulnerability matrix table

## N+2. Remediation Priorities
- Ordered by risk, with specific fix recommendations

## N+3. File Reference Appendix
| File | Relevant Sections |

Mermaid Diagram Patterns

Use these patterns for consistency:

Master attack surface map (flowchart TB with subgraphs for Sources, Transforms, Sinks):

flowchart TB
    subgraph Sources["UNTRUSTED SOURCES"]
        S1["description"]
    end
    subgraph Sinks["SENSITIVE SINKS"]
        K1["description"]
    end
    S1 --> K1
    classDef critical fill:#ffcdd2,stroke:#b71c1c
    classDef high fill:#ffe0b2,stroke:#e65100
    classDef medium fill:#fff9c4,stroke:#f57f17
    classDef low fill:#c8e6c9,stroke:#2e7d32

Risk quadrant chart:

quadrantChart
    title Risk Assessment: Likelihood vs Impact
    x-axis Low Likelihood --> High Likelihood
    y-axis Low Impact --> High Impact
    quadrant-1 Prioritize
    quadrant-2 Monitor
    quadrant-3 Accept
    quadrant-4 Mitigate
    Vuln Name: [likelihood, impact]

Flow-specific sequence diagrams for complex multi-component flows.

Critical Rules

1. Read actual code -- never assume what validation exists. Grep for the function, read it, verify.
2. Trace completely -- follow data through every function call. Don't stop at "it calls validateInput()" -- read validateInput() and verify what it actually validates.
3. Note what's NOT there -- the absence of validation is as important as its presence. If a field flows to a sink with no escaping, say so explicitly.
4. Show code for critical findings -- include the actual vulnerable code snippet, not just a description.
5. Distinguish mitigated from accepted -- "mitigated" means a defense exists. "Accepted" means the team knows about the risk and chose not to address it. Don't conflate them.
6. Be specific about file:line -- every source, sink, and validation checkpoint should reference exact file paths and line numbers.
7. Include proof-of-concept payloads -- for critical/high findings, show what an attacker would send and what would happen.
8. Don't assume trust boundaries -- verify authentication on every endpoint, authorization on every operation, validation on every input. "It's internal" is not a defense.

Language-Specific Patterns to Check

Python

• subprocess.run/Popen with shell=True or unsanitized args
• os.system(), os.popen(), eval(), exec()
• yaml.load() vs yaml.safe_load()
• pickle.loads() with untrusted data
• Jinja2 Environment(autoescape=False) or Template() without sandbox
• f-strings or .format() in SQL queries
• shlex.quote() usage (correct?) vs shlex.split() (dangerous with untrusted input)
• os.path.join() without traversal checks (it doesn't prevent ../)
• __import__() or importlib with user-controlled module names

JavaScript/TypeScript

• child_process.exec() vs execFile() vs spawn()
• eval(), Function(), vm.runInNewContext()
• Template literals in SQL queries
• innerHTML, dangerouslySetInnerHTML
• JSON.parse() with prototype pollution potential
• URL construction without validation (SSRF)
• require() or dynamic import() with user-controlled paths

Go

• os/exec.Command() with unsanitized args
• text/template vs html/template
• database/sql with string concatenation
• filepath.Join() without filepath.Clean() traversal check
• unsafe package usage
• reflect with user-controlled type names

General

• CORS with Access-Control-Allow-Origin: *
• Missing CSRF protection
• Hardcoded secrets or credentials in source
• Error messages leaking internal structure
• Debug endpoints exposed in production
• Rate limiting gaps on sensitive endpoints

Output Delivery

After generating the report, ask the user how they want it delivered:

• Written to a file in the repo (e.g., docs/SOURCE_SINK_ANALYSIS.md)
• Created as a GitHub gist (secret)
• Displayed in the conversation

Default to asking, but if the user specified a preference upfront, honor it.