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 your repository from My Repo and find the open upgrade pull request for the affected product.
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. Comment /approve to release it. There is one pull request per environment, so release the lower environment first, watch the rollout, then release production. Receiving Managed Upgrades covers the flow in detail, and Approving Changes the commands.

On agent-only clusters, the same information arrives without the automation: the finding's Latest release and the orange Upgrade available marker 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, and the orange upgrade marker disappears.
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 managed upgrades to see what the upgrade pull requests contain and how to stage them across environments.
• 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.