Remediating Vulnerabilities

The CVEs view is read-only because Tetrate owns remediation: the fix for a finding is a patched release, shipped by Tetrate and rolled out to your clusters. What is left for you depends entirely on the finding's category, and this page maps each category to the action it implies and shows how the loop closes.

Who Fixes What

Category	What it means	Who acts
actionable	A newer Tetrate release fixes the CVE, and the finding names it as the upgrade target.	You. On the managed data plane, release the upgrade pull request with a comment; on agent-only clusters, upgrade the workload to the named target yourself.
pending	The image is already on the latest release, so the fix has to arrive in Tetrate's next release.	Tetrate. When the fixing release ships, the finding re-categorizes to actionable on its own, so pending findings need watching, not work.
third party	The image is not distributed by Tetrate, so it is outside the catalog and outside Tetrate's remediation path.	Whoever owns that component. The finding is informational, and its fixed version tells you what to look for in that project's own channels.

Acting on Actionable Findings

On the managed data plane, an actionable finding and an open upgrade pull request are two views of the same fact: your cluster runs an image that has a newer release.

1. Open the Upgrades view and find the request waiting on the affected product, or reach the same request on GitHub from My Repo.
2. Review the diff. It touches one version file only, and each chart revision and image is pinned separately, so nothing else moves as a side effect.
3. Approve it to release it, from the panel or with a /approve comment. There is one pull request per environment, so release the lower environment first, watch the rollout, then release production. Receiving and Viewing Upgrades covers how the request arrives, and Approving and Releasing Changes the commands and the console panel that sends them.

On agent-only clusters, the same information arrives without the automation: the finding's Latest release and the container's Upgrade available badge in the Clusters view name the release to move to. Upgrade the workload to that reference with whatever mechanism deploys it today.

Verifying Remediation

Nothing in the Patch Service is marked fixed by hand; the loop closes on evidence:

1. The upgraded workloads roll out, and the agent reports the new images in its next snapshot.
2. The Clusters view flips the image's version badge, its Status cell loses the upgrade badge, and the orange marker beside the cluster's name clears once no image in it is behind.
3. The next scan of the fleet no longer finds the CVE on the new image, so the old finding resolves.

A merged upgrade is not a remediated finding

Until the agent observes the new image running and a scan confirms the CVE is gone, the finding stays open. If a finding stays open after an upgrade, the gap itself is the signal: check the Clusters view for a cluster still running the old tag, usually a rollout that never finished.

Next Steps

• Receive and view upgrades to see what the upgrade pull requests contain and where the console lists the ones waiting on you.
• Monitor vulnerabilities to watch counts fall as remediation lands, with scan freshness alongside.
• Read Release Catalog for where upgrade targets come from and why they never cross build variants.