## 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

```text
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.
2. 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.
3. 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.
4. Re-scan. Run `snyk test` again.
   Expected: no issues found, exit code 0, and the CI check goes green on push.
5. 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