Capabilities
Code analysis
The scan-code skill (Exorcist) performs AI-native static analysis. It traces data flows, checks for mitigations, and only reports findings when all criteria for a genuine vulnerability are met.
Pattern matching is not enough
Pattern-matching SAST catches known vulnerability patterns (like query("SELECT * FROM users WHERE id = " + userId)) but misses everything that doesn't match a signature. Business logic flaws, authorization bypasses, and novel attack vectors are invisible to it.
It also over-reports. Every SQL query with string concatenation gets flagged, even when parameterized queries are used elsewhere in the same handler, or when input validation middleware runs upstream.
Five-phase analysis
Phase 1: Plan attack vectors
Based on the repository context (project type, frameworks, sensitive data types), the planner selects which vulnerability vectors to check. This is informed by structured criteria files that define 89 vulnerability types across backend, frontend, and mobile platforms.
The depth setting controls how many vectors to check:
| Depth | Vectors per project | Best for |
|---|---|---|
| Quick | Top 5 | Fast feedback during development |
| Balanced | Top 15 | Regular security reviews |
| Full | All available | Comprehensive audits |
Phase 2: Nominate candidate files
For each selected vector, a fast triage pass identifies candidate files using pattern matching (Grep/Glob). The goal is to find files that might contain vulnerabilities, not to analyze them.
The nominator looks for signals like SQL query builders, authentication middleware, file upload handlers, or cryptographic function calls.
Phase 3: Deep analysis
Each nominated file gets thorough analysis that traces data flows from user input to dangerous sinks:
- Input tracing -- where does user-controlled data enter this code path?
- Sink identification -- where could that data cause harm (database queries, file operations, response rendering)?
- Mitigation checking -- are there parameterized queries, input validation, escaping functions, or middleware that neutralize the threat?
- Criteria validation -- every finding must satisfy all criteria defined for its vulnerability type. These criteria are specific and auditable (e.g., "User-controlled input reaches SQL query without parameterization" AND "Query uses string concatenation" AND "Input not validated or sanitized" AND "Vulnerable code reachable remotely").
A finding is only reported when all criteria are met. Missing even one criterion (like "input validation is absent") means the vulnerability doesn't exist.
Phase 4: Independent verification
Each finding goes through a second, independent analysis pass. The verifier re-reads the source code, confirms each criterion with specific code evidence, and checks for mitigations the analyzer might have missed.
Findings are classified as verified or rejected, with detailed reasoning. Rejection categories include: theoretical (possible but not practically exploitable), mitigated (protection exists), false positive (criteria not actually met), unreachable (code path can't be triggered), or best-practice-only (not a real vulnerability).
Phase 5: Auto-fix
Every verified finding includes a remediation section with corrected code. Your AI agent can apply these fixes directly.
Vulnerability coverage
Exorcist covers 89 vulnerability types organized by platform:
Backend (48 vectors)
| Category | Vulnerabilities |
|---|---|
| Injection | SQL injection, command injection, NoSQL injection, XPath injection, XML injection, template injection, prompt injection |
| Authorization | BOLA, BFLA, privilege escalation, mass assignment |
| Authentication | Broken auth, weak passwords, missing MFA, insecure sessions, JWT implementation flaws, cookie security, credential stuffing, missing auth |
| Cryptography | Weak encryption, insecure randomness, weak hashing, missing encryption at rest, improper certificate validation |
| Data exposure | Sensitive logging, sensitive errors, stack traces in production, debug endpoints, information disclosure, enumeration |
| Request forgery | SSRF |
| API security | Missing rate limiting, missing input validation, CSRF, excessive data exposure, resource-level rate limiting |
| Serialization | Unsafe deserialization, XXE, 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)
| Category | Vulnerabilities |
|---|---|
| XSS | DOM XSS, mutation XSS |
| Injection | CSS injection |
| Authentication | Insecure token storage, token URL exposure |
| Authorization | Client-side authorization bypass |
| Data exposure | Sensitive client-side code, console data leakage, sourcemap exposure |
| Cryptography | Client-side crypto implementation, weak randomness |
| Third-party risks | Missing subresource integrity |
| Navigation | Client-side open redirect |
| Messaging | Missing postMessage origin validation |
Mobile (26 vectors)
| Category | Vulnerabilities |
|---|---|
| Data storage | Unencrypted local storage, sensitive logs, keychain misuse, SQLite encryption, backup exposure |
| Communication | Missing certificate pinning, cleartext traffic, weak TLS |
| Authentication | Biometric bypass, missing root detection, insecure sessions |
| Cryptography | Weak encryption, insecure key storage, custom crypto |
| Code tampering | Missing obfuscation, debug mode enabled, insecure IPC, exported components |
| Reverse engineering | Hardcoded secrets, API keys in code, logic exposure, missing anti-tamper |
| Platform-specific | Insecure deep links, intent manipulation, URL scheme hijacking, WebView vulnerabilities |
All criteria are defined in YAML files and are fully inspectable in the skills repository.
Example
claude "run a code security analysis on this project"
For a deeper analysis:
claude "/ghost:scan-code depth=full"
A typical finding looks like:
# Finding: SQL Injection in Account Handler
## Metadata
- Type: backend
- Vector: sql-injection
- CWE: CWE-89
- Severity: high
## Location
- File: src/handlers/account.go:87
- Function: GetAccount
## 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)
For full documentation of the analysis engine, criteria format, and finding format, see Exorcist.