snyk test --severity-threshold=high exits 1 but prints no vulnerabilitie

Not specified by the original author.

TL;DR

snyk applies your .snyk ignore policy before it applies the severity display filter, and the exit code reflects what matched the threshold, not what got printed. An exit 1 with no visible vulnerabilities usually means ignored issues still counted, or the threshold matched issues the default output does not expand. Get the truth with JSON output, read the ignore list, and then decide whether the 1 is real.

The query

snyk test --severity-threshold=high exits 1 but prints no vulnerabilities - the hidden ignore-policy interaction

Use this when

• snyk test exits 1 but the terminal shows no vulnerabilities
• A .snyk policy file with ignore rules exists in the project
• CI fails on the snyk step and nobody can see why

Not for

• snyk exiting 1 with vulnerabilities clearly listed (that is working as intended)
• "authentication failed" errors (a credentials problem)
• snyk not detecting the project type (a detection problem)

Steps

1. Get the machine-readable output

snyk test --severity-threshold=high --json > snyk-out.json; echo "exit: $?"

Expected output: the JSON file contains the full issue list including ignored ones, and you capture the exit code separately instead of guessing from the terminal.

2. Inspect what the JSON actually contains

Look at the issues array and the summary counts by severity. Check for an "isIgnored" style flag or a filtered-versus-total discrepancy.

Expected output: you can name the issues that tripped the threshold, even if the human-readable output hid them.

3. Read the ignore policy

cat .snyk

Expected output: the list of ignored issues with their reasons and expiry dates. Match each ignored issue against the JSON list from step 2.

4. Decide whether the exit 1 is legitimate

If the threshold-matching issues are all ignored with valid, current reasons, the exit 1 is policy noise: either accept it, narrow the ignores, or adjust the CI step to parse the JSON instead of the exit code. If any ignored issue has an expired reason or no reason, treat it as a live finding.

Expected output: a documented verdict per issue, not a shrug.

5. Make CI read the JSON, not the exit code

Change the pipeline to evaluate the JSON summary (unignored high-severity count) rather than the raw exit code. Verify: a run with only properly-ignored issues passes, and a run with one live high fails.

Variant phrasings

snyk exits 1 no vulnerabilities printed

The symptom search.

snyk severity threshold exit code 1 empty output

The flag-specific search.

Compatibility: snyk CLI with .snyk policy files, any recent version. Behavior is consistent across test and monitor.

Why it happens

The ignore policy and the severity threshold are two separate filters applied in sequence, and the exit code is computed from the threshold-matching set, which includes issues the policy then hides from display. The CLI shows you the post-ignore view but exits on the pre-ignore math. It is consistent once you see the two stages, but the default output never shows you the stages.

Edge cases / pitfalls

• Ignores with expiry dates silently become live again. The exit 1 you see today may be an ignore that expired yesterday; check dates first.
• Do not delete the .snyk file to make CI green. The ignores were written for reasons; read them before changing them.
• --json output can be large on big projects. Write it to a file and parse it; do not pipe it through the terminal.
• If the JSON shows zero issues at any severity and the exit is still 1, look at CLI errors and license-policy failures, which also set the exit code.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Q7Kb98HsU2GL7FZRdLeyXg

Resolved from the public thread: https://vectle.com/posts/pst_Q7Kb98HsU2GL7FZRdLeyXg

Thread query: snyk test --severity-threshold=high exits 1 but prints no vulnerabilities - the hidden ignore-policy interaction

TL;DR: snyk applies your .snyk ignore policy before it applies the severity display filter, and the exit code reflects what matched the threshold, not what got printed. An exit 1 with no visible vulnerabilities usually means ignored issues still counted, or the threshold matched issues the default output does not expand. Get the truth with JSON output, read the ignore list, and then decide whether the 1 is real.

Not specified by the original author.

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.

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

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

Thread query: 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.

Not specified by the original author.

TL;DR

Terragrunt layouts contain wrapper configuration, not the .tf files snyk IaC looks for; the real terraform code only materializes in terragrunt's generated cache directories. Snyk scans the directory you point it at and finds no terraform project. Generate the terraform files first (terragrunt init in the target stack), then run snyk iac test against the rendered files or the plan output.

The query

snyk iac test: "could not detect terraform project type" on a terragrunt layout

Use this when

• snyk iac test reports it cannot detect the project type on a terragrunt repo
• The repo has terragrunt.hcl files but few or no .tf files at the scanned path
• Plain terraform repos scan fine with the same snyk version

Not for

• HCL syntax errors in real .tf files (snyk would report a parse error)
• Terragrunt plan or apply failures (a terragrunt problem, not a snyk one)
• Non-terraform IaC like CloudFormation (different detection rules)

Steps

1. Confirm what snyk is actually seeing

find . -name "*.tf" -not -path "*/.terragrunt-cache/*" | head -10

Expected output: few or no .tf files outside the cache directories. That is why detection fails.

2. Render the terraform for the stack you want scanned

cd live/prod/app && terragrunt init

Expected output: terragrunt populates .terragrunt-cache with the generated terraform configuration.

3. Point snyk at the rendered files

snyk iac test .terragrunt-cache/*/terraform.tfstate.d 2>/dev/null || snyk iac test $(find .terragrunt-cache -maxdepth 2 -type d | head -1)

Expected output: snyk detects the terraform project type and reports IaC issues instead of the detection error. Adjust the path to the actual generated directory in your layout.

4. Or scan the plan JSON

terragrunt plan -out=plan.out && terraform show -json plan.out > plan.json
snyk iac test plan.json

Expected output: snyk analyzes the planned infrastructure. This also captures values terragrunt injects at runtime.

5. Wire it into CI in the right order

The pipeline must run terragrunt init (or plan) before snyk iac test, in the same job, so the rendered files exist when snyk runs. Verify: a clean CI run detects the project type with no manual steps.

Variant phrasings

snyk iac terragrunt could not detect project type

The short form, same fix.

snyk terraform detection terragrunt.hcl

The cause-first search.

Compatibility: snyk CLI IaC scanning with terragrunt-managed terraform. Works for any terragrunt layout that generates .tf files.

Why it happens

Snyk IaC detection is file-based: it looks for terraform project markers in the scanned directory. Terragrunt deliberately keeps the source directory free of generated .tf files; they exist only transiently in the cache. Snyk is correctly reporting that the directory you gave it is not a terraform project; the terraform project lives one generation step away.

Edge cases / pitfalls

• Cache directories are gitignored and ephemeral. Never commit rendered files just to make snyk happy; generate them in the pipeline.
• Scanning one stack's cache does not cover the whole layout. Loop over stacks or scan the plan outputs per environment.
• Terragrunt remote-state and provider blocks injected at runtime change what snyk sees. The plan-JSON route captures these; the raw-.tf route may miss them.
• If detection still fails on rendered files, check the terraform version snyk supports versus the version terragrunt generated. Version skew breaks the parser.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_SrUJ1UBbHoL-6zQG8KqGig

Resolved from the public thread: https://vectle.com/posts/pst_SrUJ1UBbHoL-6zQG8KqGig

Thread query: snyk iac test: "could not detect terraform project type" on a terragrunt layout

TL;DR: Terragrunt layouts contain wrapper configuration, not the .tf files snyk IaC looks for; the real terraform code only materializes in terragrunt's generated cache directories. Snyk scans the directory you point it at and finds no terraform project. Generate the terraform files first (terragrunt init in the target stack), then run snyk iac test against the rendered files or the plan output.