Container Patching, Scanner Blind Spots and a WAF That Blocks the ASV
Ridgeline Travel runs 300 microservices on EKS across 60 nodes, with 1,200 images in ECR pulled from public base images. ECR basic scanning runs on push only, so images deployed eight months ago have never been rescanned for CVEs published since. Policy states critical vulnerabilities must be patched within 30 days; last quarter 47% of criticals exceeded 60 days. Node AMIs are EKS-optimised and updated “when someone remembers” - 14 nodes run an AMI from 14 months ago. Internal scanning uses an agent deployed as a DaemonSet, but a tainted node group of 18 nodes has no toleration and therefore no agent. External ASV scans hit CloudFront and the WAF, which blocks the scanner's source IPs; the last clean external scan pass was seven months ago. The security team has also flagged a critical vulnerability in a Go library used by the search service where the upstream maintainer has published no fix and no timeline.
1. Map the observable symptoms to the requirements being failed, and explain why each is a failure rather than a documentation gap.
Read the worked answer
- 11.3.1 internal scanning: internal vulnerability scans must be performed at least every three months by qualified personnel, with the population defined. Eighteen nodes with no agent means the scan is not covering all system components, so coverage must be evidenced - agent inventory reconciled to the cluster, or agentless scanning for the gap.
- 11.3.2 external ASV scanning: quarterly scans by a PCI SSC Approved Scanning Vendor. Seven months without a passing report is a failure, and a WAF that blocks the scanner is not a mitigation - it produces a false negative and hides real exposure. The scanner's source addresses must be allowlisted, or scanning performed against the origin in a way the ASV can complete and report on.
- 6.3.3 patching: critical and high-risk vulnerabilities must be patched within one month of release. A policy of 30 days is fine; 47% of criticals beyond 60 days is a failed control, and the metric is exactly what the assessor will sample.
- 6.3.1 / 6.3.2: an inventory of system components and a vulnerability ranking process are required. Neither is evidenced here.
- Scan-on-push only: a build-time scan cannot detect CVEs published afterwards, so eight-month-old running images are effectively unassessed. Continuous registry and runtime scanning is needed.
- 6.4.1: public-facing applications require an annual and change-driven review against attacks, which the WAF configuration should support rather than obstruct.
Each item is a failure of operation, not a missing document - the control exists on paper but does not run across the population.
2. What do you do about the critical vulnerability with no vendor fix?
Read the worked answer
Requirement 6.3.3 requires applicable patches to be installed; when no fix exists, the decision must be documented and risk-managed rather than silently deferred.
- Confirm exposure: is the vulnerable function reachable from untrusted input, and is the package loaded at runtime in the deployed binary? Record the analysis - a library present in the SBOM but never invoked is still a finding, but the analysis shapes the response.
- Apply compensating controls: a WAF virtual patch, egress network policy, disabling the affected feature or route, runtime protection, or restricting the service account. Document which control blocks which path.
- Targeted risk analysis (12.3.1): set an owner, review date, acceptance criteria and residual risk statement.
- Management risk acceptance: time-bounded and entered in the risk register, with escalation if the vendor remains silent past the review date.
- Monitor and pre-commit: an SLA to deploy the fix within one month of release, and a test in the pipeline ready to go.
- Feed the assessor: the analysis, the compensating control evidence and the acceptance are what turn an open critical into a managed exception instead of a failed requirement.
Note that exploitability analysis informs the response but does not by itself remove the requirement; the one-month clock starts when a fix ships.
3. Redesign the programme so this state cannot recur. Which controls belong in the pipeline rather than in a monthly report?
Read the worked answer
Move the control points into the build and deploy path, and keep reporting as evidence rather than as the mechanism.
- Scanning: enable enhanced or continuous registry scanning plus runtime scanning on nodes; trigger a rescan of all images when a critical CVE is published; publish a dashboard of open criticals by image, service and owning team.
- Admission control: block deployment of images with known unmitigated criticals or without a signed SBOM; pin images by digest; rebuild from minimal base images weekly and on every base-image release.
- Nodes: managed node groups with automated AMI release updates and surge upgrades; report maximum node age and alert on nodes past the threshold, which prevents 14-month-old AMIs from hiding.
- Coverage assurance: deploy the scanning agent to tainted node groups with tolerations or adopt agentless scanning; alert on any node or workload without coverage and reconcile against the component inventory (12.5.1).
- External scanning: calendar the quarterly ASV scans, allowlist ASV sources at the WAF and CloudFront, scan every external address and hostname, and track remediation to a clean report.
- Evidence pack: a monthly compliance report showing scan coverage percentage, criticals closed within one month, open exceptions with owners and expiry, and ASV results. That pack is exactly what the QSA will sample, and it makes a bad quarter visible before the assessment rather than during it.