Efficient CVE Resolution in Containers: A Practical Approach

Resolving CVEs in containers is a necessary but often soul-crushing task. You’re not alone in drowning under a deluge of alerts from tools like BlackDuck. The key is to focus on what matters, automate the rest, and stop playing whack-a-mole. Here’s how to do it.

Diagnosis: Triage with Context

Not all CVEs are created equal. Start by filtering noise:

1. Prioritize by EPSS Score

   • Use EPSS (Exploit Prediction Scoring System) to sort CVEs by exploit likelihood.
   • Example: If 50 CVEs are reported, sort by EPSS probability. Focus on those above 10% first (adjust threshold based on your risk appetite).

2. Attack Path Analysis

   • Tools like ARMO Kubescape or Snyk analyze your container runtime context to identify which CVEs are actually exploitable.
   • A CVE in a dependency that’s never imported or executed? Deprioritize it.

3. Check Exploitability in Your Environment

   • Does the vulnerable package run as root? Is it exposed to the network? Use this context to refine priority.

Repair: Fix What Matters

Minimize toil with automation and smart updates:

1. Start with Minimal Base Images

   • Smaller attack surface = fewer CVEs. Use distroless, alpine, or minimal Ubuntu images.
   • Example: Replace ubuntu:latest with ubuntu:22.04-minimal.

2. Pin Dependencies and Automate Updates

   • Use tools like Renovate or Dependabot to auto-update dependencies.
   • Pin versions in package-lock.json or requirements.txt to avoid surprise breaks.

3. Rebuild and Scan

   • After updating, rebuild images and re-scan. Use CI/CD pipelines to block builds with critical CVEs.
   • Example: Fail the pipeline if Trivy detects a CVE with CVSS ≥ 7.0.

4. Use Vulnerability Scanners in CI

   • Integrate Trivy, Clair, or Grype into your build process.

Prevention: Stop the Bleed

Prevent CVEs from piling up in the first place:

1. Policy as Code

   • Enforce image policies at build/registry time using Open Policy Agent (OPA) or Anchore.
   • Example policy: Block images with critical CVEs or outdated base images.

   package kubernetes.admission  
      
   deny[msg] {  
     input.review.object.kind == "Pod"  
     vuln := [v | v in snyk.vulnerabilities | v.cves[_].cvssScore >= 7.0]  
     some vuln  
     msg := "Pod denied: Critical CVEs detected in image"  
   }
   

2. Shift Left

   • Scan code and dependencies during development, not just at build time.
   • Use SAST tools (e.g., Semgrep) to catch issues early.

3. Regular Image Rotation

   • Set a max image age (e.g., 90 days) and rebuild periodically to inherit upstream fixes.

4. Maintain SBOMs

   • Generate Software Bill of Materials (SBOMs) with Syft to track dependencies and speed up triage.

Tooling

Keep it simple and effective:

• Scanners: Trivy (speed), Clair (Kubernetes-native), Grype (user-friendly).
• Orchestration: Renovate (auto-updates), Dependabot (GitHub-native).
• Prioritization: EPSS, Kubescape (attack paths).
• Policy Enforcement: OPA/Gatekeeper, Anchore.

Conclusion

CVE resolution doesn’t have to be a lost cause. Focus on:

1. Triage with EPSS and context (not just CVSS).
2. Automate updates and scans to reduce toil.
3. Prevent issues with minimal images, policies, and SBOMs.

The goal isn’t to eliminate all CVEs—it’s to fix what’s exploitable and make the process sustainable. Stop chasing ghosts; start managing risk.

Source thread: How do you resolve CVEs in containers efficiently?