version: "1.0.1" name: snyk-fix description: | Complete security remediation workflow. Scans code for vulnerabilities using Snyk, fixes them, validates the fix, and optionally creates a PR. Supports both single-issue and batch mode for multiple vulnerabilities. Use this skill when:

• User asks to fix security vulnerabilities
• User mentions "snyk fix", "security fix", or "remediate vulnerabilities"
• User wants to fix a specific CVE, Snyk ID, or vulnerability type (XSS, SQL injection, path traversal, etc.)
• User wants to upgrade a vulnerable dependency
• User asks to "fix all" vulnerabilities or "fix all high/critical" issues (batch mode)

allowed-tools: "mcp_snyk_snyk_code_scan mcp_snyk_snyk_sca_scan mcp_snyk_snyk_breakability_check mcp_snyk_snyk_auth mcp_snyk_snyk_send_feedback Read Write Edit Bash Grep" license: Apache-2.0 compatibility: | Requires Snyk MCP server connection and authenticated Snyk account. GitHub CLI (gh) required for PR creation. Git repository required. Supports SAST for 20+ languages and SCA for all major package managers. metadata: author: Snyk version: 1.1.0

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

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.

1. 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.
2. 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

1. 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**: [Direct Upgrade | Parent Upgrade | Transitive Fix]
- **Target package to change**: [package@current → package@target]
- **Parent dependency** (if Parent Upgrade or Transitive Fix): [parent@current]
- **Manifest file**: [path to manifest]

Use this exact string in the strategy field of the Step 6.2 (or Step 6B.2 in batch mode) snyk_send_feedback call.

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:

Breakability Decision Tree

The breakability result (LOW / MEDIUM / HIGH) is a general likelihood assessment — it is not a confirmation of actual breakage in this specific project. Use the result to determine the next action.

Interactive vs. autonomous execution: when a human is in the loop (interactive session), present trade-offs and ask for confirmation at HIGH risk. When running autonomously (background agent, no human available), the agent must evaluate the same evidence a human would — vulnerability severity, breaking change risk, breaking change details — make the decision itself, and document its reasoning in the output. An autonomous agent must never block waiting for input that will not come.

Strategy A (Direct Upgrade) and Strategy B (Parent Upgrade):

Strategy B → fallback to C: If Strategy B gets a HIGH breakability result and the decision (user or agent) is to not proceed, fall back to Strategy C. Re-run mcp_snyk_snyk_breakability_check on the transitive version jump and follow the Strategy C decision tree below. When this fallback happens, re-record the "Document the chosen strategy" template from Step 4.1 with `Transitive Fix` before reaching Step 6.2.

Strategy C (Transitive Fix):

Step 4.2a: Breakability Fallback — Semver + Usage Analysis

This step activates when `mcp_snyk_snyk_breakability_check` is unavailable (tool not found, errors out, times out) OR returns a response without a LOW/MEDIUM/HIGH risk level (e.g., "no additional breakability context available"). If breakability returned a valid risk level, skip this step entirely.

When breakability data is unavailable, derive a substitute risk level by combining semver distance and codebase usage:

1. Determine the semver distance between the current version and the target version:

• Patch bump (e.g., 1.2.3 → 1.2.5): lowest inherent risk
• Minor bump (e.g., 1.2.3 → 1.3.0): moderate inherent risk
• Major bump (e.g., 1.2.3 → 2.0.0): highest inherent risk

1. Search the codebase for direct usages of the package being upgraded. Look for imports, requires, includes, or other dependency references using patterns appropriate to the project's language and ecosystem. The agent determines the correct search patterns based on the ecosystem — do not use hardcoded patterns.

1. Combine both signals to derive a substitute risk level:

1. Feed the substitute risk level into the same Breakability Decision Tree from Step 4.2. No separate code path — the same thresholds and actions apply.

Important: when a substitute risk level is used, note this in the remediation summary (Phase 6) so the user knows the risk assessment was derived from codebase analysis, not from breakability data.

Step 4.3: Version Selection

When multiple versions fix the vulnerability, do NOT blindly pick the lowest version number. Optimize for:

1. Fixes the target vulnerability
2. Lowest breakability risk (run mcp_snyk_snyk_breakability_check on candidates if needed)
3. Lowest version number (tiebreaker only)

Step 4.4: Apply Fix

Only reach this step if the breakability decision allows it (auto-apply or user/agent confirmed).

Strategy A (Direct Upgrade): Update the version in the manifest and run the ecosystem's install command (npm install pkg@version, yarn upgrade, go get, pip install, mvn dependency:resolve, etc.). Preserve file formatting and comments.

Strategy B (Parent Upgrade): Update the parent dependency version in the manifest and run the ecosystem's install command. After installation, verify that the resolved transitive is now the fixed version.

Strategy C (Transitive Fix): Use the lowest-impact mechanism that makes the resolver choose a fixed version of the transitive. The exact mechanism is ecosystem-dependent — do not assume one universal ordering.

1. Resolver-only update first: Refresh the lockfile or run the ecosystem's update/resolve command for the vulnerable package. This is appropriate when the fixed version is already allowed by the existing constraints.
2. If that fails, inspect the ecosystem and repo layout, then choose the appropriate native resolver-control mechanism: top-level constraint/declaration, central dependency-management entry, force/override/resolution, exclusion, or replacement.
3. Prefer the narrowest effective scope. Use a stronger override/force/replace only when a normal declaration or narrower exclusion cannot make the resolver choose the fixed version.
4. Hard pin only as a last resort.

Reference: common install/resolve commands

This table is not exhaustive — use the appropriate command for the project's ecosystem.

If installation fails:

• If sandbox/permission issue: retry with elevated permissions
• If dependency conflict: try a different version or note as unfixable
• Revert manifest changes if resolution completely fails
• Document the failure reason

Phase 4a: Full Advisory — SCA No-Apply Path

Enter this phase when the decision is to NOT apply an SCA fix — whether because the user declined, or because the agent (in autonomous mode) determined the risk outweighs the benefit.

Produce an advisory instead of making changes.

Advisory Output Format

## Security Advisory — Manual Action Required
 
### Vulnerability
- **ID**: [Snyk Issue ID]
- **Severity**: [Critical | High | Medium | Low]
- **Package**: [vulnerable_package@current_version]
- **Title**: [vulnerability title]
 
### Why This Was Not Auto-Applied
[1-2 sentences: e.g., "The required transitive fix from pkg@1.0 to pkg@2.0 has a HIGH
breaking change risk. The changelog indicates removed APIs and changed default behavior
that may affect consumers."]
 
### Breaking Change Details
[Summary from mcp_snyk_snyk_breakability_check — what changed between versions, which APIs were
removed/renamed/modified, migration notes if available]
 
### Exact Changes Required
To apply this fix manually, make the following changes:
 
**1. Manifest change** ([path/to/manifest]):
[Exact content to add or modify — the override/resolution entry or version bump]
 
**2. Regenerate lockfile**:
[Exact command to run]
 
**3. Validate**:
[Command to re-run SCA scan and tests]
 
### Alternatives
- Wait for [parent_package] to release a version that includes the fixed transitive
- Evaluate replacing [vulnerable_package] with an alternative
- Accept the risk and document in your security policy

After producing the advisory:

• Do NOT make any file changes
• Do NOT proceed to Phase 5
• Send mcp_snyk_snyk_send_feedback with fixedExistingIssuesCount: 0
• STOP

Phase 5: Validation

Step 5.1: Re-run Scan

Run same scan as Phase 2 (using identical path parameter). Verify ALL targeted instances are resolved.

For Code vulnerabilities - If any instances still present:

• Review the fix attempt for that specific instance
• Try alternative approach
• Maximum 3 total attempts per instance, then report partial success/failure
• If new vulnerabilities introduced: fix them (iterate, max 3 total). If unable to produce clean fix: revert ALL changes and report failure

For SCA vulnerabilities - If vulnerability still present:

• Check if lockfile was properly updated
• Try explicit version install using the package manager's exact-version syntax
• Maximum 3 attempts, then STOP and report failure

If NEW vulnerabilities introduced by an SCA upgrade:

• New severity LOWER than fixed: Accept (net security improvement)
• New severity EQUAL OR HIGHER: Try an alternative version. Run mcp_snyk_snyk_breakability_check on each candidate before attempting — do not blindly try higher versions without assessing their risk. Up to 3 iterations.
• If no clean version exists: Revert and report as unfixable

Step 5.1a: Additional Issues Fixed (SCA Only)

Compare pre/post scan. Record all additional vulnerabilities resolved by the upgrade (ID, severity, title).

Step 5.2: Run Tests

Run project tests (npm test, pytest, etc.).

For Code vulnerabilities:

• On failure: prefer adjusting fix over changing tests; only modify tests for legitimate behavioral changes. Max 2 attempts.

For SCA vulnerabilities:

• On failure: prefer adjusting code to match the new API over downgrading. Apply mechanical fixes only (renamed imports, signature changes). Max 2 attempts.

Step 5.3: Run Linting

Run project linter if configured; fix any formatting issues introduced.

Phase 6: Summary & PR Prompt

Step 6.1: Display Summary

Display a concise remediation summary including:

• Vulnerability ID, severity, title, CWE (code) or package upgrade (SCA)
• Instance/fix count and per-instance status (✅ Fixed / ⚠️ Partial / ❌ Failed)
• "What Was Fixed": 2–3 plain-English sentences, no code snippets
• Validation table: Snyk re-scan, build, lint, tests (✅/⚠️/❌)
• For SCA: strategy (Direct/Parent/Transitive), breaking change risk (LOW/MEDIUM/HIGH), risk source (Breakability Check / Codebase Usage Analysis), breaking change summary, and list additional issues fixed by the upgrade

End with a visually separated PR prompt:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
## Should I create a PR for this fix? (yes / no)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Step 6.2: Send Feedback

Use the data already gathered in Step 6.1's summary:

mcp_snyk_snyk_send_feedback:
  fixedExistingIssuesCount: [total issues fixed]
  fixedIssueIds: [array of prefixed IDs fixed — "sast:<ID>" once per Code instance fixed,
    or "sca:<ID>" for the SCA vulnerability plus each additional issue fixed by the same
    upgrade (Step 5.1a)]
  fixedIssuesBySeverity: {critical: [count], high: [count], medium: [count], low: [count]}
  fixedIssuesByScanType: {sast: [count], sca: [count]} (Code fixes report sast only; SCA
    fixes report sca only)
  outcome: "applied"
  breakabilityRisk: [LOW | MEDIUM | HIGH | unknown] (SCA only, from Step 4.2/4.2a — omit for Code)
  breakabilityRiskSource: [api | heuristic] (SCA only — omit for Code)
  strategy: [Direct Upgrade | Parent Upgrade | Transitive Fix] (SCA only, from Step 4.1 — omit for Code)
  testsPassed: [true | false] (from Step 5.2)
  preventedIssuesCount: 0
  path: [absolute project path]

Step 6.3: Wait for User Response

IMPORTANT: Do NOT proceed until the user explicitly confirms.

Phase 6B: Batch Summary (Batch Mode Only)

Step 6B.1: Summary

Display overall results (attempted/fixed/partial/failed/skipped), breakdown by severity (fixed vs remaining), detailed per-item results for code and SCA vulns, files modified, validation results, and a table of issues NOT fixed with reasons.

End with:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
## Should I create a single PR for all these fixes? (yes / no)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Step 6B.2: Send Batch Feedback

mcp_snyk_snyk_send_feedback:
  path: [project root]
  fixedExistingIssuesCount: [total across all vulns]
  fixedIssueIds: [prefixed ID of every fixed item — "sast:<ID>" for each fixed Code item,
    "sca:<ID>" for each fixed SCA item; array length matches fixedExistingIssuesCount]
  fixedIssuesBySeverity: {critical: [count], high: [count], medium: [count], low: [count]}
  fixedIssuesByScanType: {sast: [count], sca: [count]}
  outcome: "applied"
  testsPassed: [true | false] (overall batch test result)
  breakabilityRisk / breakabilityRiskSource / strategy: include only if exactly one SCA
    item was fixed in this batch (so a single value applies); omit if zero or multiple SCA
    items were fixed, since these are single-value fields and a mixed batch can span
    different risks/strategies per item
  preventedIssuesCount: 0

Step 6B.3: Batch PR

Branch: fix/security-batch-YYYYMMDD or fix/security-critical-high-batch. Default: single commit with all changes (offer per-vuln commits if user prefers). PR body: summary table of code fixes (vuln, file, CWE, severity), dependency upgrades (package, old→new, CVEs fixed), validation checklist, note that each fix was validated independently.

Phase 7: Create PR (If Confirmed)

Step 7.1: Check Git Status

git status

Verify uncommitted changes exist and are security-fix related. If none: report and STOP.

Step 7.2: Create Branch

Format: fix/security-<identifier> (e.g., fix/security-SNYK-JS-LODASH-1018905, fix/security-cwe-79-xss, fix/security-path-traversal-server).

git checkout -b fix/security-<identifier>

Step 7.3: Stage and Commit

Stage only security-fix related files. Do NOT stage unrelated changes, IDE files, or build artifacts.

git add <files>
git commit -m "fix(security): <description>
 
Resolves: [Snyk ID or CVE]
Severity: [Critical/High/Medium/Low]"

Step 7.4: Push and Create PR

git push -u origin fix/security-<identifier>
gh pr create --title "Security: <title>" --body "<body>" --base main

Do NOT use --label flags.

PR body should include: vulnerability details (ID, severity, type), changes made, files changed, and validation checklist (Snyk scan passes, tests pass, no new vulnerabilities introduced).

Step 7.5: Output Confirmation

Display PR URL, branch, title, and next steps (review, request reviews, merge when approved).

Error Handling

Rollback triggers (revert ALL changes if):

• Cannot produce clean code fix after 3 attempts (or new vulnerabilities introduced)
• Tests fail and cannot be reasonably fixed after 2 mechanical fix attempts
• Fix would require changing business logic
• Dependency resolution completely fails

Constraints

Single Mode: Fix one vulnerability TYPE per run (all instances). Minimal changes only. No new vulnerabilities. Tests must pass. No scope creep or refactoring. Always prompt for PR.

SCA-specific (Single and Batch):

• Breakability gates all SCA fixes — Do NOT apply any SCA upgrade without first running mcp_snyk_snyk_breakability_check and following the risk-based decision tree
• Confirmation for HIGH risk — In interactive sessions, HIGH risk fixes require explicit user confirmation. MEDIUM auto-applies with documented reasoning. See Step 4.2.
• Version selection considers breakability — When multiple versions fix a vulnerability, prefer lowest breakability risk, not just lowest version number
• No fix path means no fix attempt — See Step 2.5

Batch Mode adds: User must approve plan before starting. Max 20 vulnerabilities, 15 files. Validate each fix before proceeding. Partial success allowed. Single PR for all batch fixes (unless user requests otherwise).

Completion Checklist

Single Mode: vulnerability documented → fix path verified for SCA (or No Fix Available Report) → remediation strategy determined for SCA (A/B/C) → breaking change assessment for SCA → fix applied (or Full Advisory) → re-scan clean → tests pass → summary shown → Snyk feedback sent → PR prompt asked (if fix applied) → PR created if confirmed.

Batch Mode: full scan done → plan shown and approved → all items attempted → each fix validated → results tracked → batch summary shown → Snyk feedback sent → PR prompt asked → single PR created if confirmed.