How Should I Handle High and Critical OS Vulnerabilities in My Container?

Just because a CVE has a high or critical rating doesn't mean it's straightforward to exploit. For the CVE-2025-4802, you need to be able to upload a shared object to your environment and manipulate specific paths to run it. If you can prove that these conditions aren't feasible in your scenario, then this CVE might not be directly exploitable.

You've hit the nail on the head with why we run the Trivy scan but allow it to fail. It’s more about auditing than blocking pipeline processes. In our case, we've mostly shifted to using trivy-operator for scanning images in K8s clusters.

Running a scanner is just one part of the equation; making decisions based on those results is where it gets interesting. You’ll encounter a lot of findings, many of which could be false positives. It often becomes a value versus cost decision, and discussions about these tools can become quite... lively.

If you want to address the vulnerability directly, you could build your own container with a newer library version, write a patch, or switch to a different container that doesn't have this issue. Also, I suggest submitting a ticket to the maintainers of the current container, and maybe try to evaluate if accessing the vulnerability is possible in your setup.

You should assess and mitigate the risks involved. For this particular vulnerability, the attacker would likely need some kind of shell access to the container. Are you letting anyone random access your containers? If not, your risk might be manageable.