Exorcist

Exorcist is Ghost Security Agent's code analysis engine. It reads code like a security engineer: planning attack vectors, tracing data flows, checking for mitigations, and verifying findings independently.

How it works

Exorcist is implemented entirely as the scan-code skill. There's no standalone binary. Code vulnerability analysis requires understanding intent, context, and business logic, so the "tool" is the AI itself, guided by structured criteria and a multi-phase pipeline.

Phase 1: Plan attack vectors

Based on your repository context (project type, frameworks, sensitive data types, business criticality), the planner selects which vulnerability vectors to check.

The selection is informed by structured criteria files that define 89 vulnerability types, organized by platform:

Three depth modes control the scope:

Phase 2: Nominate candidate files

For each selected vector, a fast triage pass identifies files that might contain vulnerabilities. This is pattern matching (searching for SQL query builders, authentication handlers, file upload code, cryptographic function calls).

The nominator identifies candidates quickly so the analyzer can focus on files most likely to contain real issues.

File limits per vector scale with depth: 3 (quick), 8 (balanced), 20 (full).

Phase 3: Deep analysis

Each nominated file gets thorough analysis:

1. Read the candidate file in full and understand its purpose
2. Trace data flows -- where does user-controlled input enter? Where could it cause harm?
3. Check for mitigations -- parameterized queries, input validation, escaping, middleware, framework protections
4. Follow imports -- read up to 5 related files to understand the full context
5. Validate against criteria -- every finding must satisfy ALL defined criteria for its vulnerability type

A finding is only created when every criterion is met. For SQL injection, that means:

• User-controlled input reaches a SQL query
• The query uses string concatenation instead of parameterized queries
• Input is not validated or sanitized
• The vulnerable code is reachable from external input (HTTP, API, WebSocket)

If any criterion fails, no finding is reported.

Phase 4: Independent verification

Each finding goes through a second, independent analysis. The verifier re-reads the source code, confirms every criterion with specific code evidence, and checks for mitigations the analyzer might have missed.

Findings are classified as:

Phase 5: Auto-fix

Every verified finding includes:

• A description of the vulnerability
• The vulnerable code snippet
• Remediation guidance
• A corrected code snippet ready to apply

Your AI agent can apply these fixes directly.

Vulnerability coverage

Backend (48 vectors)

Injection -- SQL injection, command injection, NoSQL injection, XPath injection, XML injection, template injection, prompt injection

Authorization -- Broken Object Level Authorization (BOLA), Broken Function Level Authorization (BFLA), privilege escalation, mass assignment

Authentication -- broken authentication, weak password requirements, missing MFA, insecure session management, JWT implementation flaws, cookie security issues, credential stuffing vulnerabilities, missing authentication

Cryptography -- weak encryption algorithms, insecure random number generation, weak hashing, missing encryption at rest, improper certificate validation

Data exposure -- sensitive data in logs, sensitive error messages, stack traces in production, exposed debug endpoints, information disclosure, user enumeration

Request forgery -- Server-Side Request Forgery (SSRF)

API security -- missing rate limiting, missing input validation, CSRF, excessive data exposure, resource-level rate limiting gaps

Serialization -- unsafe deserialization, XML External Entity (XXE) injection, object injection

File handling -- path traversal, arbitrary file upload, unrestricted file types, file inclusion

Business logic -- race conditions, workflow bypasses, signup flow abuse, password reset vulnerabilities, weak verification tokens

Frontend (15 vectors)

Cross-site scripting -- DOM XSS, mutation XSS, CSS injection

Data exposure -- insecure token storage, token URL exposure, console data leakage, sourcemap exposure, sensitive client-side code

Authorization -- client-side authorization bypass, missing postMessage origin validation, client-side open redirect

Cryptography -- client-side crypto implementation, weak randomness

Integrity -- missing subresource integrity, prototype pollution

Mobile (26 vectors)

Data storage -- unencrypted local storage, sensitive logs, keychain misuse, SQLite encryption gaps, backup exposure

Network security -- missing certificate pinning, cleartext traffic, weak TLS

Authentication -- biometric bypass, missing root/jailbreak detection, insecure sessions

Cryptography -- weak encryption, insecure key storage, custom crypto implementations

Code protection -- missing obfuscation, debug mode enabled, hardcoded secrets, API keys in code, missing anti-tamper, logic exposure

Inter-process communication -- insecure IPC, exported components, insecure deep links, intent manipulation, URL scheme hijacking, WebView vulnerabilities

Criteria format

All vulnerability criteria are defined in YAML and fully inspectable. Each vector specifies:

• Candidate patterns -- what to look for when nominating files
• CWE mapping -- Common Weakness Enumeration identifier
• Severity descriptions -- what constitutes high, medium, and low severity for this specific vulnerability
• Validation criteria -- the specific conditions that must ALL be true for a finding to be genuine

Example (SQL injection):

vector: sql-injection
cwe: CWE-89
candidates: "SQL query builders, database access layers, ORM raw queries"
criteria:
  - User-controlled input reaches SQL query without parameterization
  - Query uses string concatenation instead of parameterized queries
  - Input not validated or sanitized before use in query
  - Vulnerable code reachable remotely (HTTP/S, API, gRPC, WebSocket)

These criteria are atomic and auditable.

Finding format

Each finding is a Markdown file with a standard structure:

# Finding: SQL Injection in Account Handler

## Metadata
- ID: root--injection--sql-injection--account-handler--get-account
- Project: backend
- Type: backend
- Agent: injection
- Vector: sql-injection
- CWE: CWE-89
- Severity: high
- Status: verified

## Location
- File: src/handlers/account.go
- Line: 87
- Function: GetAccount

## Description
The GetAccount handler constructs a SQL query using string
concatenation with user-supplied input from the URL parameter.

## Vulnerable Code
  rows, err := db.Query("SELECT * FROM accounts WHERE id = " + accountId)

## Remediation
Use parameterized queries to prevent SQL injection.

## Fixed Code
  rows, err := db.Query("SELECT * FROM accounts WHERE id = ?", accountId)

## Validation Evidence
| # | Criterion | Evidence |
|---|-----------|---------|
| 1 | User input reaches query | accountId from URL param (line 82) |
| 2 | String concatenation used | Direct concat on line 87 |
| 3 | No input validation | No sanitization between param and query |
| 4 | Remotely reachable | GET /api/accounts/:id route (router.go:45) |

## Verification
- Verdict: verified
- Reason: All criteria confirmed with code evidence

Running Exorcist

Through Claude Code:

# Quick scan (top 5 vectors per project)
claude "/ghost:scan-code"

# Balanced scan (top 15 vectors)
claude "/ghost:scan-code depth=balanced"

# Full audit (all vectors)
claude "/ghost:scan-code depth=full"

Results are written to ~/.ghost/repos/<repo_id>/scans/<commit_sha>/code/findings/.

For workflow details on how code analysis fits into the full pipeline, see Code analysis.

Adding/Modifying vulnerability criteria

Exorcist's vulnerability criteria are defined in YAML files at skills/plugins/ghost/skills/scan-code/criteria/:

• backend.yaml -- backend vulnerability vectors
• frontend.yaml -- frontend vulnerability vectors
• mobile.yaml -- mobile vulnerability vectors
• index.yaml -- auto-generated index of valid agent-vector combinations

Each vector defines candidates (what to look for), CWE mapping, severity descriptions, and validation criteria (conditions that must all be true for a genuine finding).

To add a new vulnerability type:

1. Add the vector definition to the appropriate platform YAML file
2. Update index.yaml with the new agent-vector mapping
3. Test by running /ghost:scan-code against a project with known instances of the vulnerability