snyk test fails PR with 3 high severity issues: how to fix

TL;DR

Upgrade each flagged package to the fixed version snyk names, then re-run snyk test to confirm the count hits zero. Most of these are a version bump away - transitive dependencies drag in old vulnerable releases and the gate exists so they cannot merge silently. Only suppress an issue with a .snyk policy entry when you have verified the vulnerable code path is unreachable, and always set an expiry.

The error

Tested 142 dependencies for known issues, found 3 issues, 3 vulnerable paths.

High severity: 3

(Each issue in the full output names the package, the CVE, and the version that fixes it.)

Fix it

1. Read the details. Run snyk test locally and note each issue's package, CVE, and fixed version.

Expected: 3 entries, each pointing at a specific upgrade target.

1. Upgrade the packages. Bump each one to at least the fixed version in your manifest (package.json, requirements.txt, go.mod, or equivalent) and reinstall so the lockfile updates.

Expected: the lockfile no longer contains the vulnerable versions.

1. Optionally let snyk do it: run snyk fix and review the proposed diff before applying.

Expected: a PR-ready diff of version bumps you can inspect.

1. Re-scan. Run snyk test again.

Expected: no issues found, exit code 0, and the CI check goes green on push.

1. For an issue with no available fix that you have verified is unreachable (dev-only dependency, dead code path), add an ignore entry to the .snyk policy file with an expiry date and a reason.

Expected: the check passes with the exception documented and time-boxed.

Use this when

• snyk test fails the PR on vulnerable dependencies
• You see high-severity issue counts in the Snyk step
• You need the upgrade path for a specific flagged CVE

Not for this skill when

• The vulnerabilities are in the base image's OS packages - that is a trivy problem, not a snyk one
• Snyk fails to authenticate or cannot reach its API - fix auth or network first
• The project does not use snyk - use osv-scanner or dependabot instead

Variant phrasings

• snyk test high severity issues
• snyk fix vulnerabilities
• snyk ignore vulnerability .snyk
• snyk PR check failed

Why it happens

Transitive dependencies pull in old releases with known CVEs, and the manifest rarely pins them directly, so the vulnerable version arrives invisibly. Snyk compares your resolved dependency tree against its vulnerability database and fails the gate so the CVE cannot merge without someone looking at it.

Edge cases

• An ignore without an expiry becomes permanent - always set one and re-evaluate
• Scan the lockfile, not just the manifest, or the gate and your local run can disagree
• Major-version bumps can break the build - run the full test suite after upgrading, not just the scan
• Snyk's automated fix PRs and your manual bumps can conflict - pick one flow per repo and stick to it

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_fLNbOB-m8rk1YENQSiKGvg