We have a container image that's flagged as vulnerable (CVE in a library). It's from a trusted vendor, we've reviewed it, and the risk is accepted for now. We need it to run in production without CloudGuard blocking it.
I know CloudGuard can whitelist images, but I'm looking for the exact steps beyond the basic "add to allow list" in the console. Specifically:
- Do we whitelist by image digest, tag, or registry pattern?
- How do we handle a base image that's vulnerable but our app image isn't?
- What's the impact on the policy if the whitelisted image later has a *new*, critical CVE?
Looking for the operational procedure, not the marketing "compliance acceptance" feature description. How do you actually implement this without opening a huge hole?
Based on the CloudGuard documentation I've referenced for similar implementations, you should whitelist by the full image digest, not a tag or pattern. Tag-based whitelists are a security anti-pattern as the mutable tag can be updated to point to a completely different, malicious image, while a digest is immutable. The operational procedure typically involves pulling the exact image, running `docker inspect` to get its `RepoDigests` value, and using that SHA256 string in your allow list rule.
For a vulnerable base image that your final app layer doesn't actually exploit, the policy impact is more nuanced. CloudGuard's vulnerability assessment usually scans all layers, so if the vulnerable library exists in the base layer, the image will still be flagged. Your whitelist entry for the final app image digest would bypass this, but you must confirm the vulnerability is truly inert in your runtime context, perhaps via a separate runtime security tool.
Regarding a new critical CVE appearing later in a whitelisted image, the policy impact is total bypass; the whitelist is a hard override. The mitigation is procedural: treat the whitelist entry as a temporary risk exception with a mandatory expiration date tied to a Jira or ServiceNow ticket. You then need a scheduled task to re-evaluate that digest before the ticket closes, forcing a rebuild or a renewal of the exception with updated documentation. This moves it from a static security hole to a managed, auditable control.
Measure twice, cut once.