A development team stores container images in a registry before deployment. Security wants to reduce the chance of shipping vulnerable libraries or packages inside the image. What should the team do before release?
Scanning the image with a CVE-aware tool (e.g., Trivy, Grype) identifies known vulnerable packages before deployment, while rebuilding from an approved, hardened base image ensures the image starts from a patched and trusted foundation, eliminating many supply-chain risks. This is a preventive control that reduces the likelihood of an attacker exploiting a known flaw in runtime dependencies. The combination of automated scanning and trusted base images is a core DevSecOps practice.
Why this answer
Scanning the image for known vulnerabilities (CVEs) and rebuilding it from an approved, hardened base image ensures that only trusted, patched libraries and packages are included. This directly reduces the attack surface by eliminating vulnerable components before the image is deployed to production.
Exam trap
The trap here is that candidates may confuse operational practices (like running as root or opening ports) with security controls that directly address software supply chain risks, or mistakenly think that adding resources can compensate for insecure image content.
How to eliminate wrong answers
Option A is wrong because running containers as root violates the principle of least privilege and increases the risk of privilege escalation if the container is compromised. Option C is wrong because opening a container port on the host firewall does not affect the security of the image's contents; it only changes network accessibility and may increase exposure. Option D is wrong because adding CPU and memory resources does not address software vulnerabilities; resource allocation has no impact on the security of libraries or packages within the image.