snyk-fix

What this skill does

# Snyk Fix (All-in-One)

Complete security remediation workflow: Parse → Scan → Analyze → Fix → Validate → Summary → (Optional) PR

**Modes**:
- **Single Mode** (default): Fix one vulnerability type at a time (all instances in same file)
- **Batch Mode**: Fix multiple vulnerabilities in priority order (triggered by "all", "batch", severity filter, or count)

---

## Phase 1: Input Parsing

Parse user input to extract:
- **mode**: Single (default) or Batch
- **scan_type**: `code`, `sca`, or `both` (inferred from context)
- **target_vulnerability**: Specific issue ID, CVE, package name, file, or vuln type
- **target_path**: File or directory (defaults to project root)
- **severity_filter** / **max_fixes**: For batch mode (default max: 20)

### Mode & Scan Type Detection

| Signal | Mode | Scan Type |
|--------|------|-----------|
| "all", severity filter, count ("top 5"), or "batch" | Batch | both |
| Specific vuln ID, single type, file reference, or no batch indicators | Single (default) | — |
| Explicit "code"/"sast"/"static" | — | code |
| Explicit "sca"/"dependency"/"package"/package manager name | — | sca |
| `SNYK-` or `CVE-` ID provided | — | both |
| Vulnerability type (XSS, SQL injection, path traversal, etc.) or file reference | — | code |
| Package name reference | — | sca |
| No hints | — | both (highest priority issue) |

---

## Phase 1B: Batch Mode Planning (Skip if Single Mode)

1. Run both `mcp_snyk_snyk_code_scan` and `mcp_snyk_snyk_sca_scan` on project root.
2. Filter by user-specified severity, type, path, or count.
3. Group by vulnerability type (same ID + file for code; same package for SCA). Sort Critical → High → Medium → Low; within same priority, prefer issues with available fixes.
4. Display fix plan as a numbered table (index, type, severity, target, instance count) with estimated file/package changes. **Wait for user confirmation before proceeding.**
   - If user says "adjust": allow plan modification.
5. Execute fixes in order (Phase 3 or 4 per item → Phase 5 validate → track result). On failure: stop if `stop_on_failure=true`, else continue.
6. Proceed to Phase 6B after all attempts.

**Batch limits**: max 20 vulnerabilities, max 15 files modified, max 3 fix attempts per item.

---

## Phase 2: Discovery

### Step 2.1: Run Scan(s)

Invoke scans with the target path. Examples:

```
# Code scan
mcp_snyk_snyk_code_scan:
  path: "/absolute/path/to/project"   # or subdirectory for targeted scans

# SCA scan
mcp_snyk_snyk_sca_scan:
  path: "/absolute/path/to/project"   # always project root (manifest location)
```

- Code: `mcp_snyk_snyk_code_scan` on target path
- SCA: `mcp_snyk_snyk_sca_scan` on project root
- Both: run in parallel

### Step 2.2: Select Target
- If user specified: find matching issue. If not found: report and STOP.
- If not specified: select highest priority type using: Critical+exploit > Critical > High+exploit > High > Medium > Low. Prefer issues with available fixes.

### Step 2.3: Group Instances (Code Only)
After selecting vulnerability type, collect ALL instances of that same Snyk ID in the same file. Fix all of them together.

### Step 2.4: Document Target
Display a brief summary: type (Code/SCA), ID, severity, title, and for Code — instance count + file/line table; for SCA — package, fix version, dependency path.

### Step 2.5: Check for Fix Path (SCA Only)

**⚠️ If the scan results do not report any fix version or upgrade path for the selected SCA vulnerability, do NOT proceed to Phase 4.** The agent must not attempt to discover or invent a fix on its own when Snyk has no recommended remediation.

Instead, produce a **No Fix Available Report** and STOP:

```
## No Fix Available

| Vulnerability | [Title] |
|---------------|---------|
| **ID** | [Snyk Issue ID] |
| **Severity** | [Critical / High / Medium / Low] |
| **Package** | [package@current_version] |
| **Dependency Path** | [direct / transitive via X → Y → Z] |

### Why No Fix Was Applied
Snyk does not report a fix version or upgrade path for this vulnerability.
The agent will not attempt to resolve issues where no known fix exists.

### Alternatives to Consider
- Monitor for a future fix release from the package maintainer
- Evaluate replacing the package with a maintained alternative
- Apply a manual workaround if the vulnerability context allows it
- Accept the risk and document in your security policy
```

After producing this report:
- Send `mcp_snyk_snyk_send_feedback` with `fixedExistingIssuesCount: 0`
- Do NOT make any file changes
- STOP

---

## Phase 3: Remediation (Code Vulnerabilities)

### Step 3.1: Understand
Read all vulnerable locations. Identify type (SQL injection, XSS, path traversal, command injection, sensitive data exposure, hardcoded secrets, crypto issues, etc.). Review Snyk's remediation guidance.

### Step 3.2: Plan
Document: vulnerability type, root cause, fix approach, security mechanism, instance count.

Common patterns:
- SQL Injection → parameterized queries
- Command Injection → input validation + escaping or avoid shell
- Path Traversal → canonicalize + validate against allowed base
- XSS → output encoding/sanitization for context
- Hardcoded Secrets → move to env vars / secrets manager

### Step 3.3: Apply Fix to ALL Instances
- Fix from bottom to top of file (avoid line number shifts)
- Minimal change; use standard library/framework security features
- Create shared helper if 3+ instances share identical fix pattern
- Add security-relevant comments where non-obvious
- Do NOT refactor unrelated code or change business logic

---

## Phase 4: Remediation (SCA Vulnerabilities)

**Skip to Phase 5 if this is a Code vulnerability (already handled in Phase 3).**

### Step 4.1: Determine Remediation Strategy

Analyze the dependency path and determine which strategy applies. Exactly one of these three strategies must be selected before proceeding:

**Strategy A — Direct Upgrade**
The vulnerable package is a direct dependency in the project manifest. Upgrade it to a version where the vulnerability is fixed.

**Strategy B — Parent Upgrade**
The vulnerable package is a transitive dependency. A newer version of the direct (parent) dependency pulls in a fixed version of the transitive. Upgrade the parent.

**Strategy C — Transitive Fix**
The vulnerable package is a transitive dependency, but no available version of the parent pulls in a fixed transitive. Resolve the transitive to a fixed version using the lowest-impact mechanism available in the ecosystem.

#### How to choose:

1. Is the vulnerable package declared directly in the project manifest?
   - **Yes** → **Strategy A**
   - **No** → Continue to step 2

2. Identify the direct dependency (parent) that pulls in the vulnerable transitive. Does any available version of the parent resolve the vulnerable transitive to a fixed version?
   - **Yes** → **Strategy B** (upgrade the parent)
   - **No** → **Strategy C** (transitive fix)

If the application directly imports or uses the transitive dependency (not just via the parent), note this — it affects breaking change analysis for Strategy C.

Document the chosen strategy:
```
## Remediation Strategy
- **Strategy**: [A: Direct Upgrade | B: Parent Upgrade | C: Transitive Fix]
- **Target package to change**: [package@current → package@target]
- **Parent dependency** (if B/C): [parent@current]
- **Manifest file**: [path to manifest]
```

### Step 4.2: Breaking Change Assessment

**⚠️ ALWAYS run `mcp_snyk_snyk_breakability_check` BEFORE applying any changes.** If the tool is unavailable, errors out, or does not return a LOW/MEDIUM/HIGH risk level, proceed to Step 4.2a.

Call `mcp_snyk_snyk_breakability_check` with the package that will actually change in the manifest:

| Strategy | Check breakability on |
|----------|----------------------|
| A (Direct Upgrade) | The direct dependency being upgraded |
| B (Parent Upgrade) | The parent dependency being upgraded |
| C (Transitive Fix) | The transitive dependency being resolved