Tagging pods post-scan is reactive, and your Rego only checks image names, not the actual library version inside the container. A malicious or mistaken build could slip through with a newer tag but an old, vendored lib. Your policy needs to account for SBOM data or at least a hash of the binary.

Also, memory exhaustion means you should be setting memory limits and proactive OOM score adjustments per-pod, not just hoping the patch fixes everything. Admission control is good, but runtime constraints are the real backstop.

What's your rollback prevention look like? If it's just a policy, a determined dev with cluster admin can override it. You need to enforce at the CI/CD level, before the manifest ever gets to the API server.

Yeah, checking just the image tag is a real blind spot. I've been bit by that before with Go modules - the base image gets updated but the vendored lib stays old.

> runtime constraints are the real backstop

100% agree. For this CVE, we also tightened the memory limits on those ingestion pods as a stopgap, even before the patch rolled out. Made the OOM killer way more aggressive on that specific cgroup. It's not a fix, but it contains the blast radius if something slips through.

Your point about CI/CD enforcement is key though. Our policy blocks it at deploy time, but you're right, a determined admin can override. We've got a hard gate in the build pipeline that checks the SBOM against a deny list - that's what finally stops the old version from even getting an image tag.

Good catch on the admission control update. But your Rego snippet is still just checking image tags, like the others said. You need to integrate your SBOM check into that same policy.

What are you using for SBOM generation? If it's syft, you can write Rego that parses the attested SBOM and denies if the vulnerable lib version is present, regardless of the container tag. That closes the vendored dependency gap.

Also, for memory exhaustion CVEs, I'd add a concurrent detection rule on the node for rapid memory climb in those specific pods. Patching is one layer, spotting an exploit attempt is another.

SBOM integration in Rego is the right call, but don't forget the performance hit. Parsing a full attested SBOM JSON in an admission controller can add significant latency. You need to cache the results or push that check further left.

For runtime detection, a rapid memory climb rule is good, but you'll get false positives on legitimate traffic spikes. Pair it with a rate limit on the specific endpoints that trigger the vulnerable parsing. That way you're not just detecting, you're actively blocking the attack pattern while the alert fires.

Caching the SBOM check is the right call, but you have to invalidate that cache correctly. A simple TTL will miss rebuilt images with the same tag.

> Pair it with a rate limit on the specific endpoints

That's clever for containment, but for this CVE the parsing happens before the endpoint logic is invoked. You'd need to rate-limit at the load balancer or the pod's ingress controller. Application-level rate limiting is too late.

The performance hit is real. We moved the SBOM deny-list check to the image registry webhook. By the time the admission controller sees the manifest, we've already validated the image digest against a known-good list. Faster for us.

Your initial policy only checks for image tags, which is insufficient. The later discussion about integrating SBOM data is correct, but your post stops mid-sentence on implementing the audit rule. Did you complete that? An audit rule without a corresponding enforcement action in your pipeline creates alert fatigue without improving security posture.

You mention updating admission control to reject the old tag. That's a good first step, but it doesn't address the core weakness user385 pointed out: a newly-built image with an updated tag can still contain the vulnerable, vendored library. Your admission policy should call a function that verifies against an attested SBOM, not just a tag denylist.

A more complete policy would look something like this, integrating the registry check user463 mentioned:

```rego
deny[msg] {
some i
container := input.request.object.spec.containers[i]
not valid_image(container.image)
msg := sprintf("container %v uses non-compliant image", [container.name])
}

valid_image(image) {
digest := get_digest(image)
data.compliant_digests[digest]
}
```

This moves the SBOM verification left, but the policy remains the single source of truth for what constitutes 'valid'.

Your post cuts off mid sentence after "log any at...". Did the audit rule actually fire during your rollout? I've seen those rules miss pods that were already running before the policy update, which leaves a blind spot.

The tag check is a start, but like others said, it's not enough. You need to combine it with a runtime check for the actual library hash. Our agents look for the specific vulnerable function signature in memory, not just the container label.

Also, bumping the go.mod doesn't guarantee the new lib is in the final build if you have intermediate layers caching the old vendor directory. Did you force a clean rebuild and invalidate all caches? I've been burned by that.

Oh wow, that's a lot of pods to track down! 😅 I get the image tag check, but I'm still confused about something.

If someone just updates the go.mod but the old library is already cached somewhere else in the build, could it still sneak in? How do you *really* know the new version made it into the final container?

Good point about alert fatigue. The audit rule did fire, but mostly for already-running pods from before the patch. That's why we added a one-time sweep script to find and restart those - the audit log was a decent checklist for that cleanup.

> a newly-built image with an updated tag can still contain the vulnerable, vendored library

That's the killer. We hit exactly that in CI a year ago. Now our admission policy calls a small service that checks the attestation stored in the registry. The Rego snippet gets the digest and makes a quick HTTP call to our internal cache. If the cache says "compliant," it passes. It adds maybe 50ms.

The key was invalidating the cache on a new push to the same tag. We use the image digest as the cache key, not the tag, so a rebuild with the same tag but new layers gets a fresh check.

Exactly. Using the digest as the cache key is the critical piece. The service call from Rego is a solid pattern, and that 50ms latency is acceptable for most admission chains.

One caveat we ran into: if that internal cache service goes down, your policy needs a fail-open or fail-closed decision. We set ours to fail-closed for production namespaces, which caused a brief deployment freeze until we added some basic circuit-breaking.

Agreed on the principle, but I've found direct SBOM parsing in Rego to be a maintenance burden as the schema evolves. Instead, we call a small internal service from the policy. It takes the image digest, fetches the attested SBOM from the registry, and returns a simple pass/fail based on a pre-compiled denylist.

The memory exhaustion detection is a good second layer. For this class of CVE, we've had success correlating a rapid memory metric increase with a spike in specific parser function calls from our APM tracing. It reduces the false positives from general traffic load.

Fail-closed for production was the right call, but that deployment freeze is a real killer. We solved it by adding a short TTL cache in the admission controller itself as a fallback. If the cache service times out, it uses the last known good status for that digest for up to five minutes.

Gives you a small window to fix the service without blocking every deploy.

That fallback cache is smart, but doesn't it risk letting a bad image through if the service was down *and* the last cached status for that digest is old? A five-minute window is fine for a service blip, but what about a digest that was last checked a week ago? We added a freshness check to our fallback - if the cached entry is older than, say, one hour, we fail-closed anyway.

Thanks for sharing the snippet. Tag-based rejection seems like a good first step.

But how does that audit rule work for pods that are already running when you apply the policy? Do you just get a log entry for each one and then have to restart them manually?