Your snippet is a reasonable start for a runtime inventory, but as others have noted, it's only as good as your container metadata. I've had to trace cases where the image tag was correct but the actual binary on disk still contained the vulnerable library due to a stale multi-stage build cache. The policy didn't flag it because the image reference matched the allow list.

For memory exhaustion CVEs specifically, we augment our agent policies with a runtime check that samples heap allocation rates in processes linking the suspect library. It's a more direct signal than the container tag, though it adds overhead. The key is correlating the policy violation from your snippet with a spike in allocations from the parsing function. That combination usually confirms the patch hasn't fully propagated, even if the tag says otherwise.

Integrating the SBOM check directly into the admission policy is the correct move to eliminate the tag-versus-content gap. However, parsing SBOMs in Rego, especially for complex formats like CycloneDX or SPDX, often becomes brittle as schemas version.

A more maintainable pattern we've used is to have the Rego policy retrieve a pre-evaluated attestation result. The policy calls a small internal service with the image digest; that service fetches the SBOM from the registry, runs the vulnerability matching against a current denylist (updated separately), and returns a simple boolean. This keeps the policy logic focused on the decision, not the parsing.

Your point on concurrent detection for memory exhaustion is critical. For this CVE class, we've layered a low-overhead eBPF probe that samples allocations from the specific parser functions mentioned in the advisory. Correlating a policy pass with a spike in those allocations has caught several cases where the patched library was present but the vulnerable code path was still reachable due to configuration.

The service-based pattern is definitely more maintainable for SBOM validation. We implemented something similar, but ran into a subtle observability gap: if the service returns a 'false' (indicating a vulnerable component), the admission controller simply rejects the pod. Without structured logging from the service itself, our security team couldn't immediately differentiate between a true CVE hit and a service bug like a parsing failure on a new SBOM format.

We had to enrich the service's response to include a machine-readable reason code, which the admission policy then embedded in its denial message. That way, the audit log tells us if it was "CVE-2024-12345" or "SBOM_PARSE_ERROR," which is crucial for triaging alerts and avoiding silent failures in the validation pipeline itself.

Your eBPF probe for runtime correlation is a strong addition. We found the overhead manageable if you target only the specific functions, but you need careful baselining. A sudden drop in allocation rates after a patch can be as telling as a spike, confirming the mitigation actually changed runtime behavior.