Your SOC receives an alert that a vulnerable library was found in a container image deployed from the private registry. The image was built three months ago, and the registry holds many older images awaiting rollout. You need to identify which stored images are vulnerable before they are deployed. Which scanning method should you implement?
Select an answer to reveal the explanation.
Short Explanation
Think of registry scanning like checking the freezer for old meals before serving them. You don't need to cook again to find the expired one. The risk is already stored, so you scan the images in the registry and block the bad ones before deployment.
Full Explanation
Registry scanning is appropriate when the artifact of concern is a container image already present in a repository. It inspects stored image layers, base operating-system packages, and application dependencies without requiring source code or a running workload. This method answers whether existing images are vulnerable before deployment, and it can be authenticated to access private registries. Source-code composition scanning is a build-time or pre-commit control; it detects dependencies in a repository but does not reveal which packaged images already contain vulnerable layers. Runtime host or container scanning observes live processes, files, and kernel state, which helps detect exploitation but does not inventory dormant registry artifacts. Dynamic application security testing exercises HTTP requests against a running service to find input-handling flaws, so it misses vulnerable packages in unstarted images. Exam caveat: CompTIA often tests whether the scan target is source, image, runtime, or network, not whether a tool is technically capable of some adjacent check. Operational check: Run an authenticated registry scan against all private images, export package CVE findings, and block deployment of images that fail the remediation policy.