Container and Serverless Gating with a No-Fix Base Image
TravelJet builds about 200 container images per week in GitHub Actions and pushes them to Amazon ECR. It runs three Kubernetes clusters and 40 Lambda functions. A pilot of CloudGuard Workload Protection found 1,200 CVEs across images. Developers now bypass the scan gate with a 'critical exception' label because a base image used by 30 services has a critical CVE with no vendor fix. The security team wants to block deployment of images with critical exploitable vulnerabilities, keep the pipeline under 15 minutes, and avoid a repeat of the bypass. Runtime protection is not yet enabled. The clusters use a managed control plane; the team has cluster-admin but no node SSH, and deployments are reconciled by Argo CD. The audit is in 45 days.
1. Design a CI gating policy that blocks real risk without blocking every critical CVE.
Read the worked answer
Gate on exploitability and fixability, not on the raw count of critical CVEs.
- Build stage: scan the image in GitHub Actions. Fail the build only when an image has a critical-severity vulnerability that is known to be exploitable and has a vendor fix available, or when a secret or malware signature is found. A critical CVE with no fix should not fail the build by itself; it should open a tracked exception automatically.
- Registry stage: rescan images in ECR on a schedule and on base-image updates. This catches drift after the build, because the same image can become vulnerable when new intelligence arrives.
- Admission stage: deploy the supported CloudGuard admission control for the Kubernetes clusters so an image that fails the policy cannot be scheduled, even if Argo CD reconciles it. For Lambda, enforce image digest pinning and use the supported CloudGuard serverless integration if licensed; otherwise compensate with least-privilege IAM and API-level controls.
The 15-minute target is realistic if the scan is incremental and layer-cached. Do not run a full registry-wide scan inside every build; parallelize and cache results.
2. The 30 services depend on a base image with a critical CVE and no vendor fix. What is a defensible handling strategy?
Read the worked answer
A blanket exception label is not defensible because it removes the gate for every image and every CVE. Replace it with a time-bound, scoped exception tied to the specific base image digest.
Steps: create a ticket with the CVE, the affected digest, the 30 services, and an owner. Define compensating controls: run the workload with a non-root user, read-only root filesystem, network policy denying unnecessary egress, and runtime detection for the relevant exploit behavior. Set an expiry date, for example 30 days, and require re-approval. Add a rebuild trigger so that when a patched base image appears, the pipeline rebuilds automatically and the exception closes. If the vendor will not fix it, evaluate replacing the base image or isolating the service.
This preserves the gate: other images with fixable critical vulnerabilities still fail. It also gives the auditor evidence that the exception was a risk decision with an owner and an end date, not a developer workaround.
3. What runtime coverage should be added before the audit, given the managed control plane and no node SSH?
Read the worked answer
Add runtime protection at the workload layer, not by logging into nodes. Use the supported CloudGuard deployment method for Kubernetes, typically an admission controller plus a runtime sensor deployed through Helm or the cluster's package manager. The admission controller enforces the image policy at schedule time; the runtime sensor detects process, file, and network behavior that suggests exploitation of the no-fix CVE. Because the control plane is managed, do not plan on host-level agents that require node SSH.
For Lambda, enable the supported serverless protection if it is licensed; otherwise document the residual risk and add detective controls: CloudTrail anomaly alerts, least-privilege execution roles, and API gateway throttling and WAF rules. Runtime protection should feed the same SIEM as the CI findings so the team can correlate a blocked image with a runtime alert.
Before the audit, prove the admission controller blocks a deliberately noncompliant test image in a non-production namespace, and show that the runtime sensor is healthy on all three clusters. That is stronger evidence than a policy document alone.