What is the difference between Trivy's vulnerability severity levels (CRITICAL, HIGH, MEDIUM, LOW)?

Severity levels in Trivy are like a hospital triage system. A CRITICAL patient needs immediate surgery, a HIGH priority patient goes to the emergency room, MEDIUM means urgent care, and LOW is a scheduled appointment. Just as hospitals cannot treat every patient simultaneously, DevOps teams use severity levels to decide which vulnerabilities to fix first and which can wait for the next maintenance window.

Trivy assigns severity levels to each detected vulnerability based on the Common Vulnerability Scoring System (CVSS). The mapping follows industry standards: CRITICAL covers CVSS scores from 9.0 to 10.0, HIGH ranges from 7.0 to 8.9, MEDIUM spans 4.0 to 6.9, and LOW covers 0.1 to 3.9. Some vulnerabilities also have an UNKNOWN severity when the CVE entry lacks a CVSS score. Trivy sources its severity data from multiple advisories, and when different sources disagree on the severity of a vulnerability, Trivy prioritizes the distribution-specific advisory (like Red Hat or Debian) over the generic NVD score, because distribution maintainers often adjust severity based on how the package is compiled and configured in their distribution.

Understanding what each level means in practical terms helps teams make informed decisions. A CRITICAL vulnerability in the base image of your payments-api might allow remote code execution without authentication, meaning an attacker could take full control of the container from the network. A HIGH vulnerability in user-auth-service might enable privilege escalation but require the attacker to already have some level of access. MEDIUM vulnerabilities in order-processing-service might allow information disclosure under specific conditions, while LOW vulnerabilities in inventory-sync might require physical access or highly unusual configurations to exploit. Context matters enormously: a MEDIUM vulnerability in a public-facing service is often more urgent than a HIGH vulnerability in an internal batch processing tool with no network exposure.

In production, teams establish severity-based policies for their CI/CD pipelines. A common approach is to block deployments of checkout-service when CRITICAL or HIGH vulnerabilities are detected using trivy image --exit-code 1 --severity CRITICAL,HIGH, while allowing MEDIUM and LOW findings to be tracked as technical debt. Some mature organizations use Trivy's .trivyignore file to acknowledge accepted risks: if a CRITICAL vulnerability has no fix available and the affected component is not reachable in your application, you add its CVE ID to .trivyignore with an expiration date, preventing it from failing the pipeline while ensuring it gets reviewed periodically.

A nuance beginners often miss is that CVSS scores alone do not tell the full story. The Exploit Prediction Scoring System (EPSS) and whether a public exploit exists are equally important factors. A HIGH vulnerability with a known exploit being actively used in the wild is more dangerous than a CRITICAL vulnerability that is purely theoretical. Trivy can show whether a vulnerability has a known fix, which helps prioritize: a CRITICAL with a simple package upgrade is an easy win, while a HIGH with no fix may require architectural changes or compensating controls like network policies.