Pipeline Phases

Shannon executes penetration tests through five distinct phases, combining sequential reconnaissance with parallel vulnerability analysis and exploitation.

Pipeline Overview

The pipeline is designed to emulate a human penetration tester’s methodology:

Pre-Reconnaissance

External scans and source code analysis to map the attack surface

Reconnaissance

Detailed exploration correlating code-level insights with live behavior

Vulnerability Analysis

5 parallel agents hunting for specific OWASP vulnerability classes

Exploitation

5 parallel agents executing real-world attacks to prove impact

Reporting

Executive-level report with reproducible proof-of-concepts

Phase 1: Pre-Reconnaissance

Agent: pre-recon
Model Tier: Large (Claude Opus)
Execution: Sequential
Location: src/temporal/workflows.ts:375

Purpose

Build a comprehensive map of the application’s attack surface before any exploitation attempts.

Activities

External Scanning

Shannon integrates with industry-standard reconnaissance tools:

Nmap — Port scanning and service detection
Subfinder — Subdomain enumeration
WhatWeb — Technology stack fingerprinting
Schemathesis — API schema analysis

With PIPELINE_TESTING=true, these tools are skipped (graceful degradation).

Source Code Analysis

Deep static analysis of the target repository:File structure and technology stack
Entry points and API endpoints
Database schemas and ORM configurations
Authentication and authorization patterns
Data flow paths from user input to dangerous sinks
Prompt template: prompts/pre-recon-code.txt

Deliverable

Produces code_analysis_deliverable.md containing:

Technology stack summary
Entry point inventory
High-level architecture overview
Initial security observations
Key files and functions of interest

This deliverable is consumed by all downstream phases.

Example Findings

## Technology Stack
- **Backend:** Node.js + Express
- **Database:** PostgreSQL with Sequelize ORM
- **Frontend:** React + TypeScript

## Entry Points
1. `/api/auth/login` - Authentication endpoint
2. `/api/users/:id` - User profile retrieval
3. `/api/search?q=` - Search functionality

## Security Observations
- Raw SQL query construction in `src/db/queries.ts:45`
- User input directly interpolated in search endpoint
- JWT tokens stored in localStorage

Phase 2: Reconnaissance

Agent: recon
Model Tier: Medium (Claude Sonnet)
Execution: Sequential
Prerequisites: pre-recon
Location: src/temporal/workflows.ts:378

Purpose

Perform live application exploration via browser automation to correlate code-level insights with real-world behavior.

Activities

Authentication
Application Mapping
Correlation

Login Flow ExecutionShannon supports multiple authentication methods:

Form-based — Username/password with optional TOTP
SSO/OAuth — Sign in with Google, GitHub, etc.
API tokens — Header or query parameter authentication
Basic auth — HTTP Basic Authentication

Template: prompts/shared/login-instructions.txtExample with 2FA:

authentication:
  login_type: form
  credentials:
    username: "[email protected]"
    password: "password123"
    totp_secret: "LB2E2RX7XFHSTGCK"
  login_flow:
    - "Type $username into the email field"
    - "Type $password into the password field"
    - "Click 'Continue'"
    - "Wait for TOTP prompt"
    - "Enter generated TOTP code"

Live ExplorationThe recon agent uses Playwright to:

Discover authenticated routes and functionality
Map UI workflows and form submissions
Identify JavaScript frameworks and client-side routing
Test API endpoints with authenticated sessions
Capture application behavior and error messages

MCP Integration: playwright-agent2 (dedicated instance)

Deliverable

recon_deliverable.md contains:

Authenticated user workflows
API endpoint inventory with request/response examples
Authentication mechanism details
Session management observations
Entry point prioritization for vulnerability analysis

Phase 3: Vulnerability Analysis

Agents: 5 parallel agents
Model Tier: Medium (Claude Sonnet)
Execution: Parallel (configurable concurrency)
Prerequisites: recon
Location: src/temporal/workflows.ts:380-448

Parallel Execution Model

Why parallel? Vulnerability analysis is CPU-bound (LLM reasoning) rather than I/O-bound. Running 5 agents concurrently reduces wall-clock time from ~5 hours to ~1 hour.

Each vulnerability type has a dedicated agent:

Injection

injection-vuln

XSS

xss-vuln

Authentication

auth-vuln

Authorization

authz-vuln

SSRF

ssrf-vuln

Concurrency Control

Control parallel execution via config:

pipeline:
  max_concurrent_pipelines: 2  # Run 2 of 5 at a time

Default: 5 (all parallel)
Range: 1-5

Subscription plan users: Set max_concurrent_pipelines: 2 to reduce burst API usage and avoid rolling rate limits.

Analysis Methodology

Each agent performs structured data flow analysis:

Source Identification

Find all user-controlled input sources:

HTTP request parameters (query, body, headers)
File uploads and multipart data
WebSocket messages
URL path segments

Sink Detection

Identify dangerous operations for each vulnerability type:

Injection: SQL queries, shell commands, eval()
XSS: HTML rendering, DOM manipulation
Auth: Login bypass, JWT flaws, session fixation
Authz: IDOR, privilege escalation, missing access checks
SSRF: HTTP clients, DNS lookups, file reads

Data Flow Tracing

Trace user input to dangerous sinks:

Follow variables through functions
Track sanitization and validation
Identify bypasses and edge cases

Hypothesis Generation

Create exploitable attack paths:

Describe the vulnerability
Provide exploitation steps
Estimate severity (Critical/High/Medium/Low)
Queue for Phase 4 exploitation

Queue System

Each agent writes findings to a vulnerability queue:

// deliverables/injection_queue.json
{
  "vulnerabilities": [
    {
      "id": "INJ-001",
      "type": "SQL Injection",
      "location": "src/api/search.ts:45",
      "sink": "db.query()",
      "payload": "' OR '1'='1",
      "severity": "Critical",
      "description": "User input directly interpolated in SQL query"
    }
  ]
}

Queue validation: src/services/queue-validation.ts

Deliverables

Each agent produces two artifacts:

Analysis report: {type}_analysis_deliverable.md
Exploitation queue: {type}_queue.json (consumed by Phase 4)

Phase 4: Exploitation

Agents: 5 parallel agents
Model Tier: Medium (Claude Sonnet)
Execution: Parallel (pipelined with Phase 3)
Prerequisites: Corresponding vuln agent
Location: src/temporal/workflows.ts:389-428

Pipelined Execution

No synchronization barrier: Each exploit agent starts immediately when its vulnerability analysis completes. This reduces wall-clock time by overlapping phases.

Queue Decision Logic

Before launching an exploit agent, Shannon checks the vulnerability queue:

// src/temporal/activities.ts:checkExploitationQueue
interface ExploitationDecision {
  shouldExploit: boolean;
  vulnerabilityCount: number;
}

// Decision criteria:
if (vulnerabilityCount === 0) {
  return { shouldExploit: false };  // Skip exploit agent
}

if (vulnerabilityCount > 0) {
  return { shouldExploit: true };   // Launch exploit agent
}

Location: src/temporal/workflows.ts:406

Exploitation Methodology

Proof-by-Exploitation
Attack Examples
Browser Automation

“No Exploit, No Report” PolicyShannon only reports vulnerabilities it can successfully exploit:

Load Queue

Read hypothesized vulnerabilities from Phase 3 queue

Execute Attacks

Use browser automation, HTTP clients, and custom scripts to exploit

Verify Impact

Confirm the vulnerability has real-world impact (data exfiltration, privilege escalation, etc.)

Document Evidence

Capture screenshots, HTTP traces, and proof-of-concept code

If exploitation fails, the finding is discarded as a false positive.

Injection Exploitation

# SQL Injection payload
curl 'https://example.com/api/search?q=%27+OR+%271%27%3D%271'

# Command Injection payload
curl 'https://example.com/api/ping?host=127.0.0.1;cat+/etc/passwd'

XSS Exploitation

// Reflected XSS
<script>alert(document.cookie)</script>

// Stored XSS via API
POST /api/comments
{"text": "<img src=x onerror=alert(1)>"}

Auth Bypass

// JWT Algorithm Confusion
{"alg": "none", "typ": "JWT"}

// SQL Injection in login
username: admin'--
password: anything

Playwright IntegrationExploit agents use Playwright MCP to:

Submit malicious payloads via forms
Verify XSS execution in DOM
Test IDOR by switching user contexts
Capture proof-of-concept screenshots
Execute multi-step attack chains

Each exploit agent has a dedicated Playwright instance to prevent conflicts:

// src/session-manager.ts:170
'exploit-injection': 'playwright-agent1',
'exploit-xss': 'playwright-agent2',
'exploit-auth': 'playwright-agent3',
'exploit-ssrf': 'playwright-agent4',
'exploit-authz': 'playwright-agent5',

Deliverables

Each successful exploit produces:

Evidence file: {type}_exploitation_evidence.md
Proof-of-Concept: Copy-paste reproducible exploits
Screenshots: Visual proof (when applicable)
HTTP traces: Request/response logs

Example:

## SQL Injection Exploit: Database Exfiltration

**Severity:** Critical  
**Location:** `/api/search?q=`  
**Impact:** Complete database compromise

### Proof-of-Concept

```bash
curl 'https://example.com/api/search?q=%27+UNION+SELECT+username,password+FROM+users--'

Evidence

[Screenshot: user_database_dump.png] Successfully exfiltrated 1,247 user records including:

Username: admin
Password hash: $2b$ 10$…
Email: [email protected]

## Phase 5: Reporting

**Agent:** `report`  
**Model Tier:** Small (Claude Haiku)  
**Execution:** Sequential  
**Prerequisites:** All 5 exploit agents  
**Location:** `src/temporal/workflows.ts:454-473`

### Report Assembly Process

<Steps>
  <Step title="Artifact Collection">
    Gather all exploitation evidence files from Phase 4
  </Step>
  
  <Step title="Concatenation">
    Merge evidence into a single comprehensive report
    
    **Function:** `assembleFinalReport()` in `src/services/reporting.ts`
  </Step>
  
  <Step title="AI Refinement">
    The report agent adds:
    - Executive summary
    - Risk assessment and prioritization
    - Remediation recommendations
    - Cleanup of hallucinated content
    
    **Prompt:** `prompts/report-executive.txt`
  </Step>
  
  <Step title="Metadata Injection">
    Add model version and timestamp to report footer
    
    **Function:** `injectModelIntoReport()` in `src/services/reporting.ts`
  </Step>
</Steps>

### Final Deliverable

`comprehensive_security_assessment_report.md` contains:

<Accordion title="Executive Summary">
  - High-level findings overview
  - Risk assessment (Critical/High/Medium/Low counts)
  - Business impact analysis
  - Recommended next steps
</Accordion>

<Accordion title="Detailed Findings">
  For each vulnerability:
  - **Title and severity**
  - **Location** (file:line references)
  - **Description** of the flaw
  - **Proof-of-Concept** (copy-paste ready)
  - **Impact** assessment
  - **Remediation** guidance
  - **Evidence** (screenshots, logs)
</Accordion>

<Accordion title="Methodology">
  - Testing scope and limitations
  - Tools and techniques used
  - Coverage summary by OWASP category
</Accordion>

<Accordion title="Appendix">
  - Reconnaissance findings
  - Technology stack analysis
  - Model metadata and timestamps
</Accordion>

### Example Report Structure

```markdown
# Security Assessment Report: example.com

## Executive Summary

Shannon identified **3 Critical** and **2 High** severity vulnerabilities...

## Critical Findings

### [CRITICAL] SQL Injection in Search Endpoint
**Location:** `src/api/search.ts:45`  
**CVE:** Pending  
**CVSS:** 9.8

**Description:**
The search endpoint concatenates user input directly into SQL queries...

**Proof-of-Concept:**
```bash
curl 'https://example.com/api/search?q=%27+UNION+SELECT+*+FROM+users--'

Evidence: [Screenshot showing database dump] Remediation: Use parameterized queries:

db.query('SELECT * FROM posts WHERE title LIKE ?', [`%${query}%`])

## Phase Transition Logging

Workflow logs track phase boundaries at `src/temporal/workflows.ts`:

```typescript
// Activities for phase tracking
await a.logPhaseTransition(input, 'pre-recon', 'start');
// ... agent execution ...
await a.logPhaseTransition(input, 'pre-recon', 'complete');

Output in workflow.log:

[2025-03-03 10:00:00] === PHASE: pre-recon (start) ===
[2025-03-03 10:15:32] Agent: pre-recon | Status: completed
[2025-03-03 10:15:32] === PHASE: pre-recon (complete) ===

[2025-03-03 10:15:33] === PHASE: recon (start) ===
...

Performance Characteristics

Wall-Clock Time

1-1.5 hours for a typical application

Cost

~$50 USD using Claude 4.5 Sonnet

Parallel Agents

Up to 5 concurrent (Phases 3-4)

Sequential Agents

3 agents (Phases 1, 2, 5)

Cost optimization: Phase 1 uses Large (Opus) for deep reasoning, Phase 5 uses Small (Haiku) for summarization, and Phases 2-4 use Medium (Sonnet) for analysis.

Next Steps

Architecture

Understand the underlying system design

Agents

Explore the 13 specialized agents

Workspaces

Learn about resume and checkpointing

Configuration

Customize authentication and retry behavior

Get Started

Core Concepts

Guides

CLI Reference

​Pipeline Overview

​Phase 1: Pre-Reconnaissance

​Purpose

​Activities

​Example Findings

​Phase 2: Reconnaissance

​Purpose

​Activities

​Deliverable

​Phase 3: Vulnerability Analysis

​Parallel Execution Model

Injection

XSS

Authentication

Authorization

SSRF

​Concurrency Control

​Analysis Methodology

​Queue System

​Deliverables

​Phase 4: Exploitation

​Pipelined Execution

​Queue Decision Logic

​Exploitation Methodology

​Deliverables

​Evidence

​Performance Characteristics

Wall-Clock Time

Cost

Parallel Agents

Sequential Agents

​Next Steps

Architecture

Agents

Workspaces

Configuration

Build docs developers (and LLMs) love

Pipeline Overview

Phase 1: Pre-Reconnaissance

Purpose

Activities

Example Findings

Phase 2: Reconnaissance

Purpose

Activities

Deliverable

Phase 3: Vulnerability Analysis

Parallel Execution Model

Concurrency Control

Analysis Methodology

Queue System

Deliverables

Phase 4: Exploitation

Pipelined Execution

Queue Decision Logic

Exploitation Methodology

Deliverables

Evidence

Performance Characteristics

Next Steps