Grype "discovered vulnerabilities at or above the severity threshold" in CI

By Daniel Zoghalchali·Latchkey

Grype prints its findings table, then fails because you passed --fail-on high (or critical) and at least one matched. The message "discovered vulnerabilities at or above the severity threshold" means the gate is doing its job; the image has qualifying CVEs.

What this error means

Grype lists vulnerabilities and ends with "1 error occurred ... discovered vulnerabilities at or above the severity threshold", exiting 1 and stopping the pipeline.

Grype

NAME     INSTALLED  FIXED-IN  TYPE  VULNERABILITY   SEVERITY
libssl3  3.0.11-1   3.0.13-1  deb   CVE-2024-XXXX   Critical
1 error occurred:
	* discovered vulnerabilities at or above the severity threshold

Common causes

Findings match your --fail-on level

You set grype myimage --fail-on high, and the image has HIGH or CRITICAL CVEs, so Grype exits non-zero as configured.

Unfixed base-image CVEs count toward the gate

By default Grype includes vulnerabilities without a fix; those can trip the threshold even though you cannot patch them.

How to fix it

Remediate the packages Grype lists, then rescan

Read the FIXED-IN column and bump the base image or packages.
Re-run Grype to confirm the qualifying findings clear.
Keep --fail-on high so new HIGH/CRITICAL CVEs still block.

Terminal

grype myimage:latest --fail-on high

Ignore only unfixed or reviewed CVEs

Use --only-fixed to focus on remediable findings, and a .grype.yaml ignore list (with a reason) for specific reviewed exceptions.

.grype.yaml

# .grype.yaml
ignore:
  - vulnerability: CVE-2024-XXXX
    reason: "no upstream fix; tracked in TICKET-123, review 2026-09-01"

Make the gate meaningful

Fail the build on the severity you actually intend to block, and set it explicitly. A scanner that reports without failing is documentation, not a gate.
Scan the artifact you ship, not the source tree. A vulnerability in a base image will not appear in a source scan.
Pin the scanner version and its database snapshot for reproducibility, then update deliberately; a floating database turns an unrelated push into a red build.
Give the job a way to record accepted risk, or people will disable the gate rather than triage it.

How to prevent it

Keep the base image patched so OS CVEs stay below threshold.
Use --only-fixed so gates block on actionable CVEs.
Record exceptions in .grype.yaml with a reason and review date.

Frequently asked questions

What causes Grype "discovered vulnerabilities at or above the severity threshold" in CI?

There are 2 common causes: findings match your --fail-on level and unfixed base-image cves count toward the gate. You set grype myimage --fail-on high, and the image has HIGH or CRITICAL CVEs, so Grype exits non-zero as configured.

How do I fix Grype "discovered vulnerabilities at or above the severity threshold" in CI?

There are 2 fixes depending on which cause you have: remediate the packages grype lists, then rescan and ignore only unfixed or reviewed cves. Work through them in order, since the first is the most common.

What does Grype "discovered vulnerabilities at or above the severity threshold" in CI actually mean?

Grype lists vulnerabilities and ends with "1 error occurred ...

How do I stop Grype "discovered vulnerabilities at or above the severity threshold" in CI happening again?

Keep the base image patched so OS CVEs stay below threshold. The prevention section lists 3 changes that keep it from recurring.

References

GitHub Actions documentation