# Snyk

> Runs Snyk dependency and code security scans, prioritizes findings by severity and exploitability, and proposes minimal-breakage remediations. Use when auditing vulnerabilities or validating fixes.

- Skill: `poly-gents/snyk` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add poly-gents/snyk`
- Raw SKILL.md: https://api.skillmd.com/api/skills/poly-gents/snyk/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: poly-gents (https://skillmd.com/u/poly-gents)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/poly-gents/snyk

---


# Snyk

## Purpose

Run Snyk scans (dependencies, containers, code where supported), prioritize findings by risk, and propose upgrades or patches with re-scan verification.

## When to Use

- User asks for vulnerability scan, Snyk report, or dependency audit.
- Prioritizing CVEs before release or after alert.
- Planning upgrades/patches with minimal breakage.
- Verifying fixes with a follow-up scan.

## When NOT to Use

- Non-Snyk DAST/IaC-only tools without Snyk in scope.
- Threat modeling or design review → **threat-modeling**.
- General code review without security tooling → **shadow-code-reviewer**.

## Expected Outcome

- Scan summary with counts by severity and top exploitable issues.
- Concrete remediation paths (upgrade version, patch, ignore with justification only if user requests).
- Re-scan confirmation after fixes when tools allow.

## Inputs to Gather

- Repository path, manifest/lockfiles, and target branch.
- Snyk org/project IDs if using Snyk API/MCP.
- Severity threshold and SLA context (blocker vs backlog).
- Whether container or IaC scans are in scope.

## Workflow

1. Confirm Snyk CLI or `snyk` / `security-scanner` tools are available.
2. Run appropriate test (`test`, `code test`, `container test` per project type).
3. Sort by severity and exploitability; deprioritize unreachable dev-only noise when evidence supports it.
4. Propose minimal-change upgrades; note breaking major bumps separately.
5. Apply fixes only when user approves write access.
6. Re-scan and diff issue counts.

## Domain guidance

Use Snyk CLI or IDE integration to scan dependencies and code for known vulnerabilities. Prioritize by severity and exploitability; propose upgrades or patches with minimal breakage. Re-scan after fixes.

- Prefer upgrading direct dependencies before transitive overrides.
- Document any ignore with expiry and owner if the user explicitly accepts risk.
- Never fabricate CVE lists or scan exit codes.

## Tool Availability Rules

| Access | Behavior |
|--------|----------|
| Full tool access | Run scans and apply approved manifest/lockfile updates. |
| Read-only | Run read-only scan; output patch commands. |
| No integration | Provide exact `snyk test` commands; do not invent findings. |

### Related tool sets

- `snyk`
- `security-scanner`

## Review / Decision / Execution Criteria

- Distinguish fixable vs accepted risk vs false positive.
- Call out reachable exploit paths when Snyk provides them.
- Confirm major upgrades that affect API compatibility.

## Output Format

1. Scan scope and command(s) run.
2. Table: issue, severity, package, fixed in version.
3. Recommended actions (ordered).
4. Re-scan delta if performed.
5. Blockers (auth, missing files).

## Quality Bar

- Actionable for developers; avoid dumping raw JSON without prioritization.
- Evidence from Snyk output only.

## Safety and Boundaries

- Do not commit Snyk tokens or `.snyk` policy changes without approval.
- Do not fabricate vulnerability counts.

## Escalation / Dispatch Rules

- Architecture-level security design → **threat-modeling**.
- CI integration → **optimize-pipelines**, **add-tests**.

## References

- `skills/old_skills.json` (`snyk`).
- `skills/skill.instruction.md`, `skills/meta.instructions.md`