snyk-fix

# 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**: [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: | 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 to a new version | #### 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):** | Risk | Action | |------|--------| | **LOW** | Auto-apply the upgrade. Proceed to Step 4.4. | | **MEDIUM** | Auto-apply the upgrade. Document the breaking change summary and reasoning in the remediation summary. | | **HIGH** | **Interactive**: present the full trade-off (vulnerability details, breaking change summary, exact proposed changes) and ask the user whether to proceed. **Autonomous**: evaluate the full trade-off, decide whether to apply or produce a Full Advisory (Phase 4a), and document the reasoning. | **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):** | Risk | Action | |------|--------| | **LOW** | Auto-apply the fix. Proceed to Step 4.4. | | **MEDIUM** | Auto-apply the upgrade. Document the breaking change summary and reasoning in the remediation summary. | | **HIGH** | **Interactive**: present the full trade-off and ask the user whether to proceed. If the vulnerability is **Critical severity with a known exploit**, emphasize the urgency. **Autonomous**: evaluate the full trade-off, decide whether to apply or produce a Full Advisory (Phase 4a), and document the reasoning. | ### 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 2. **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. 3. **Combine both signals to derive a substitute risk level:** | Semver Distance | No direct usage | Light usage | Heavy / complex usage | |-----------------|-----------------|-------------|----------------------| | **Patch** | LOW | LOW | LOW | | **Minor** | LOW | MEDIUM | MEDIUM | | **Major** | HIGH | HIGH | HIGH | 4. **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 | Package Manager | Command | |-----------------|---------| | npm (major upgrade) | `npm install <pkg>@<version>` | | npm (minor/patch) | `npm install` | | yarn | `yarn install` or `yarn upgrade <pkg>@<version>` | | pip | `pip install -r requirements.txt` | | maven | `mvn dependency:resolve` | 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