Understanding CVE Scanning and Findings
Tetrate Patch Service scans every container image observed running in your clusters for known Common Vulnerabilities and Exposures (CVE) and reports each match as a finding in the CVEs view. What you see is the live exposure of your own fleet, not a generic advisory feed: every finding names an image one of your clusters runs right now and closes only on scan evidence. This page explains how scanning works, what the categories, severities, risk scores, and statuses mean, and why the view is read-only.
How Scanning Works
The agent in each cluster reports the container images Tetrate publishes that are actually running there, recognized against the release catalog rather than by anything you label, and Tetrate scans every distinct observed image for known CVEs each night. Deduplication is fleet-wide: an image running in ten clusters is scanned once, and the result applies to every cluster that runs it.
Two events trigger scans outside the nightly run:
- Immediately after Tetrate publishes a release. A new release changes which findings are actionable and what they upgrade to, so the fleet is re-scanned right away rather than waiting for the next night.
- The first time a new image is observed, most often just after an upgrade rolls out. The Patch Service scans that single image immediately, so its exposure appears without waiting for the nightly run.
Each image is checked by more than one vulnerability scanner, drawing on different advisory sources, and their results are merged into one finding per CVE, so a vulnerability only one source knows about is still reported.
Scans report vulnerabilities of every graded severity, CRITICAL, HIGH, MEDIUM, and LOW, that have a fixed version available. Upgrading is the remediation path in the Patch Service, and a CVE with no fixed version cannot be closed by upgrading, so reporting it would add noise without adding an action.
Finding Categories
Every finding carries a category that answers one question: who acts on it. The category comes from comparing the finding's image against the release catalog, the single source of truth for what counts as a Tetrate image: an image that appears in no release manifest is third party.
| Category | What it means | Who acts |
|---|---|---|
| actionable | The image is a Tetrate image and a newer release fixes the CVE. The finding carries the upgrade target, the release that resolves it. | You, by upgrading the affected clusters. On the managed data plane, the upgrade arrives as a pull request for you to release. |
| pending | The image is already on the latest release, so the fix has to arrive in Tetrate's next release. When that release ships, the finding re-categorizes to actionable automatically. | Tetrate, by shipping the release. |
| third party | The image is not distributed by Tetrate, for example a metrics exporter running alongside a Tetrate product. | No one in the Patch Service. The finding is informational. |
Severity and Risk
A finding carries two complementary signals about how urgent it is.
Severity says how bad the vulnerability would be if exploited: CRITICAL, HIGH, MEDIUM, or LOW, as graded by the advisory that published it. A CVE the advisories have not graded shows as Ungraded.
Risk says how likely that is to happen. It is a score from 0 to 100 that weighs the probability of the vulnerability being exploited against its impact. The probability comes from the Exploit Prediction Scoring System (EPSS), and a vulnerability in the CISA Known Exploited Vulnerabilities catalog, one confirmed to be exploited in the wild, is treated as a certainty, so it scores at the top of the scale.
The two disagree often enough to matter. A MEDIUM vulnerability being actively exploited today can be more urgent than a CRITICAL one nobody has ever exploited, and the risk score is how you see it. Severity tells you how much damage is possible; risk tells you where attackers are actually looking.
The console shows the score as a number, tinted by the band it falls in:
| Band | Score | What it usually means |
|---|---|---|
| Critical risk | 50 and above | Known to be exploited in the wild, or very likely to be. |
| High risk | 10 to 49.9 | A meaningful chance of exploitation. |
| Medium risk | 1 to 9.9 | Exploitation is possible but unlikely. |
| Low risk | Below 1 | Exploitation is very unlikely. |
The bands are not even quarters of the scale on purpose. Exploitation probabilities are small for almost every vulnerability: a typical CRITICAL that nobody is exploiting scores well under 10, and only known-exploited vulnerabilities approach 100. Cutting the bands to that distribution keeps the color meaningful.
Not every vulnerability has exploit-prediction data yet. Findings without it have no risk score, and the console shows a dash with not scored rather than a zero: an unscored finding has not been measured, which is not the same as being safe. Judge it by its severity until a score appears.
Severity is fixed by the advisory, but risk moves with the threat landscape: exploit predictions are republished daily, and a vulnerability can be added to the known-exploited catalog at any time. Each scan refreshes the score, so risk always reflects the latest scan, and a score that no longer exists is cleared rather than left standing.
Status and Lifecycle
A finding carries one of two statuses: open or resolved. Only a scan moves a finding between them. A finding opens the first time a scan reports the CVE on an image you run, and it resolves when a later scan of the same image no longer reports it. There is no manual transition and no dismiss action.
In the All findings tab the status filter defaults to Open; switch it to Resolved or All to include closed findings, which render dimmed and struck through. A finding disappears entirely once no cluster of yours runs the affected image, because the view shows your current exposure, not your history.
Each CVE ID links to its entry in the National Vulnerability Database (NVD), where you can read the full advisory.
How Findings Are Prioritized
Four things on a finding tell you where it belongs in the queue:
- Severity says how bad the vulnerability would be, from CRITICAL down to LOW.
- Risk says how likely it is to be exploited. A high score on a lower-severity finding is a reason to move it up the queue; a CRITICAL with a low score is still serious, but less likely to be attacked first.
- Category says who acts: actionable is yours to fix now, pending is Tetrate's to ship, third party is informational.
- First detected is the age of the problem. It is fixed for the finding's lifetime: re-reporting refreshes the details but never moves it, so an old finding is genuinely old rather than recently re-noticed.
The All findings tab opens in triage order: most severe first, and oldest first within a severity. Sort by Risk instead to put the findings most likely to be exploited on top, whatever their severity; unscored findings always sort last. Reading both orders is the quickest way to catch a lower-severity finding that is being exploited.
Scan Freshness
Scan freshness is shown alongside the results themselves. A banner warns you when the newest scan is more than 48 hours old, and a distinct message appears when no scan has ever completed. An image that has never been scanned shows No scan data, never a green badge.
An unscanned image has not been checked, which is not the same as having nothing to find. The Patch Service fails visibly by design: missing or stale scan data always shows as missing or stale, so a view without warnings is one backed by a recent scan, never one hiding an outage.
Why the View Is Read-Only
The CVEs view has no dismiss or accept-risk button by design: Tetrate owns remediation, so findings close on evidence, not judgment. Tetrate ships the patched release, categorizes your findings against it, and, on the managed data plane, opens the upgrade pull request in your GitOps repository.
Your part is visibility and, on the managed data plane, approval. Watch the CVEs view for actionable findings, and release the upgrade pull request when it arrives. Once the new images are observed running, the old image's findings resolve at the next scan without anyone touching them.
Next Steps
- Monitor your vulnerabilities when you want to track open findings and categories across clusters.
- Remediate a vulnerability when an actionable finding names an upgrade target for one of your clusters.
- Read about the release catalog when you want the mechanics behind categorization, upgrade targets, and the Upgrade available markers.