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.

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.