# sast

> Full SAST analysis — Orchestrates 5 rounds: Recon, Attack Surface, Dataflow, Exploit PoC, and Report.

- Author: Georgios Gousios
- Repository: endorlabs/claude-sast
- Version: 20260206102817
- Stars: 0
- Forks: 0
- Last Updated: 2026-02-06
- Source: https://github.com/endorlabs/claude-sast
- Web: https://mule.run/skillshub/@@endorlabs/claude-sast~sast:20260206102817

---

---
name: sast
description: "Full SAST analysis — Orchestrates 5 rounds: Recon, Attack Surface, Dataflow, Exploit PoC, and Report."
user-invocable: true
disable-model-invocation: true
---

# SAST Orchestrator

Run a complete 5-round Static Application Security Testing (SAST) analysis on a target codebase.

## Usage

```
/sast <target_path>
```

The `<target_path>` argument is **required** — it must be an absolute path to the repository to analyze. If not provided, ask the user for it.

## Rounds

1. **Recon** (`/sast-recon`) — Tech stack, structure, dependencies, entry points
2. **Attack Surface** (`/sast-surface`) — Sources, sinks, vulnerability candidates, auth review
3. **Dataflow** (`/sast-dataflow`) — Source-to-sink taint tracing, sanitization assessment
4. **Exploit** (`/sast-exploit`) — Safe PoC generation for CRITICAL/HIGH findings
5. **Report** (`/sast-report`) — Executive summary, detailed findings, remediation roadmap

## Execution

Follow these steps exactly. Report progress to the user between each round.

### Step 0: Resolve Target Path

1. Parse the argument to get the target path. If no argument was provided, ask the user.
2. Resolve the path to an absolute path (expand `~`, resolve relative paths against the current working directory).
3. Verify the path exists and is a directory using Bash (`test -d <path>`).

All subsequent `.sast/` references are relative to the **target path** (i.e., `<target_path>/.sast/`).

### Step 1: Configure Code Navigation MCP

Automatically configure the code-nav MCP server for the target codebase. This ensures the call graph tools point at the right repository without requiring a separate `/sast-nav` invocation.

1. **Auto-detect language(s)** by checking for files in the target path:
   - `pom.xml`, `build.gradle`, `*.java` → `java`
   - `*.csproj`, `*.sln`, `*.cs` → `csharp`
   - `go.mod`, `*.go` → `go`
   - `requirements.txt`, `pyproject.toml`, `*.py` → `python`
   - `tsconfig.json`, `*.ts` → `typescript`
   - `package.json`, `*.js` → `javascript`
   Use comma-separated values if multiple languages are detected.

2. **Locate the `aitrainingmcp` binary** (check in order):
   - `$MCP_BINARY_PATH` environment variable
   - `aitrainingmcp` on `$PATH` (run `which aitrainingmcp`)
   - `$HOME/bin/aitrainingmcp`
   - The Bazel build output at `$HOME/Developer/monorepo/bazel-bin/src/golang/internal.endor.ai/pkg/x/aitrainingmcp/main/main_/main`
   If not found, skip MCP configuration and warn the user (the pipeline will run in Standard mode).

3. **Read the current `.mcp.json`** in the claude-sast project root. If the `code-nav` server's `--repo-path` already matches the target path, skip to the next step — no change needed.

4. **Update `.mcp.json`**: Write the code-nav server config with the target path and detected language(s). Preserve any other existing MCP server entries.
   ```json
   {
     "mcpServers": {
       "code-nav": {
         "command": "<binary_path>",
         "args": ["--repo-path", "<target_path>", "--languages", "<language>", "--skip-index"]
       }
     }
   }
   ```

5. **Check if restart is needed**: If `.mcp.json` was modified (the repo-path changed), check whether code-nav MCP tools are currently available by attempting to use `searchSymbol`. If code-nav tools are NOT available or they are pointing at a stale repo:
   - Inform the user: `.mcp.json` has been updated to point at `<target_path>`. **Restart Claude Code** to activate the MCP server, then re-run `/sast <target_path>`.
   - **Stop execution** — do not proceed with the rounds until the MCP server is running against the correct target.

   If code-nav tools ARE available and `.mcp.json` was NOT modified (the path already matched), proceed normally.

### Step 2: Pre-flight Check

Check if a previous SAST run exists in the target:

```bash
ls <target_path>/.sast/*.md 2>/dev/null
```

If `<target_path>/.sast/` contains files from a previous run, inform the user and ask whether to:
- **Resume**: Skip completed rounds and continue from the next incomplete one
- **Restart**: Delete `<target_path>/.sast/` and start fresh

Determine which rounds are complete by checking for the existence and non-emptiness of:
- `<target_path>/.sast/recon.md` → Round 1 complete
- `<target_path>/.sast/attack-surface.md` → Round 2 complete
- `<target_path>/.sast/dataflow.md` → Round 3 complete
- `<target_path>/.sast/exploits.md` → Round 4 complete
- `<target_path>/.sast/report.md` → Round 5 complete

A round is incomplete if its output file is missing, empty, or starts with `# ERROR:`.

### Step 3: Code Navigation Check

Check if code-nav MCP tools are available by attempting to use `searchSymbol`. Report the analysis mode to the user:

```
## Analysis Mode

Target: <target_path>
Language(s): <detected_languages>
Code navigation MCP: {AVAILABLE / NOT AVAILABLE}
RAG semantic search: {AVAILABLE / NOT AVAILABLE}

Analysis mode: {Standard / Enhanced / Full}
```

- **Standard** (no code-nav): Grep-based analysis only
- **Enhanced** (code-nav without RAG): AST-based call graph traversal for precise dataflow tracing
- **Full** (code-nav with RAG): Call graph + semantic search over function summaries with security annotations

Code-nav is optional — the pipeline runs in all modes. Enhanced/Full modes reduce false positives and improve dataflow trace precision for supported languages (Java, C#, Go, Python, TypeScript, JavaScript).

### Step 4: Round Execution

For each round that needs to run (in order):

1. **Announce** the round to the user:
   ```
   ## Round {N}/5: {Name}
   Starting {description}...
   ```

2. **Invoke** the round skill using the Skill tool, passing the target path as the argument:
   - Round 1: `skill: "sast-recon", args: "<target_path>"`
   - Round 2: `skill: "sast-surface", args: "<target_path>"`
   - Round 3: `skill: "sast-dataflow", args: "<target_path>"`
   - Round 4: `skill: "sast-exploit", args: "<target_path>"`
   - Round 5: `skill: "sast-report", args: "<target_path>"`

3. **Verify** the round output exists and is valid:
   ```bash
   test -s <target_path>/.sast/{output_file} && head -5 <target_path>/.sast/{output_file}
   ```
   If the output is missing or starts with `# ERROR:`, report the failure and stop.

4. **Summarize** key findings from the round to the user (2-3 bullet points).

### Step 5: Post-Run

After all 5 rounds complete:

1. Read `<target_path>/.sast/report.md` and present the executive summary and risk dashboard to the user.

2. Inform the user where to find the full outputs:
   ```
   ## SAST Analysis Complete

   Target: <target_path>

   Full outputs available in `<target_path>/.sast/`:
   - `recon.md` — Technology reconnaissance
   - `attack-surface.md` — Attack surface mapping
   - `dataflow.md` — Dataflow analysis traces
   - `exploits.md` — Proof-of-concept tests
   - `report.md` — Final report with remediation roadmap
   ```

3. Ask if the user wants to:
   - Review any specific finding in detail
   - Generate fixes for specific vulnerabilities
   - Re-run any specific round with different parameters

## Error Handling

- If a round skill fails to produce output, stop and report the error to the user
- Do not skip rounds — each round depends on the previous one (except Round 4 exploit generation is optional if no CRITICAL/HIGH findings exist in Round 3)
- If Round 3 finds no CRITICAL/HIGH vulnerabilities, still run Round 4 (it will handle the empty case) and Round 5