Practice the vocabulary of scanning a container image for a known vulnerability before deployment.
0 / 5 completed
1 / 5
At standup, a dev mentions automatically scanning a built container image's layers for a known vulnerability in an installed package before that image is allowed to be deployed. What is this practice called?
Container image scanning automatically checks a built image's layers for a known vulnerability in an installed package before that image is allowed to be deployed. Deploying an image directly with no scan risks shipping a known, already-published vulnerability straight into production. This automated scanning is a standard, low-friction gate in a container-based deployment pipeline, catching a vulnerable dependency before it ever reaches a running environment.
2 / 5
During a design review, the team wants a scan to block an image from being pushed to the deployment registry if it contains a vulnerability above a defined severity threshold. Which capability supports this?
A severity-based scan gate blocks an image containing a vulnerability above a defined severity threshold from being pushed to the deployment registry in the first place. Scanning only after deployment finds the problem too late, once the vulnerable image is already running. This pre-push gate turns image scanning from a passive report into an active control that actually prevents a risky image from reaching production.
3 / 5
In a code review, a dev notices the base image used across every service is rebuilt and rescanned on a recurring schedule, not just once when the Dockerfile was originally written. What does this represent?
Recurring base image rebuilding and rescanning on a schedule catches a vulnerability disclosed after the Dockerfile was originally written, since a package considered safe at build time can have a new vulnerability published later. Building and scanning only once at creation time misses every vulnerability discovered afterward in that same, unchanged base image. This recurring rebuild-and-rescan cycle is what keeps a container image's security posture current rather than frozen at its original build date.
4 / 5
An incident report shows a container image passed its scan and was deployed months ago, and a newly disclosed critical vulnerability in one of its packages has since gone unnoticed because the image was never rescanned after deployment. What practice would prevent this?
Continuously rescanning a running image's contents against the latest vulnerability database, not only at its original build time, catches a vulnerability disclosed after deployment that the original scan couldn't have known about. Scanning only once at build time leaves a running image's security posture stuck at whatever was known on that original date. This ongoing rescanning is necessary because a container image, once built, doesn't automatically stay aware of a vulnerability published against it later.
5 / 5
During a PR review, a teammate asks why the team continuously rescans a deployed container image instead of trusting the scan result from when it was originally built and pushed. What is the reasoning?
A new vulnerability can be disclosed in a package well after an image containing it was originally scanned and deployed, meaning that one-time scan result inevitably goes stale over time. Ongoing rescanning catches that later-disclosed exposure in an image that's still actively running. The tradeoff is the added ongoing infrastructure cost of continuously rescanning every deployed image rather than treating a single build-time scan as sufficient forever.