How should security teams scan container images without missing base image and globally installed package risks?

Security teams should scan container images as soon as they are introduced into the pipeline, before deployment. The scan needs to cover the application, the base OS image, and globally installed packages, because each layer can introduce open source vulnerabilities. Separating code scanning from container scanning helps teams see what changed, decide whether to remediate, and avoid shipping unknown dependency risk into production.

Scan container images before they become deployment artifacts

Container image scanning works best when it is treated as an early pipeline control, not a post-build cleanup step. The goal is to inspect the image while the build context is still fresh, so teams can see whether risk came from application code, the base image, or packages installed globally into the image layer. That separation matters because each source has a different owner, fix path, and urgency.

A useful scanning program also distinguishes image content from repository metadata. A clean application scan can still miss a vulnerable libc, outdated shell, or language runtime baked into the base layer. Likewise, a dependency report can miss a package installed directly into the container filesystem during build. When scanning is layered this way, teams can decide whether they are remediating code, rebuilding from a safer base, or replacing an image entirely.

Coverage is strongest when the scanner evaluates the final artifact after all build steps have run, then attributes findings to the layer or package source that introduced them. That makes it easier to avoid false confidence from partial scans and to prevent teams from shipping unknown dependency risk into production. The practical question is not simply whether the image has vulnerabilities, but whether the scan can explain where they entered and who must act on them.

Why base images and globally installed packages are easy to miss

Base image risk is often overlooked because it sits beneath the application’s own source tree. If the scanner only looks at application dependencies, it may never inspect the operating system packages, shell utilities, certificate bundles, or shared libraries inherited from the base layer. Those components can carry known vulnerabilities even when the application itself is well maintained. NIST’s container guidance is useful here because it treats the image as a full security object, not just the app payload, and OpenSSF’s supply chain guidance reinforces the need to understand upstream source and dependency risk through projects such as NIST SP 800-190 Container Security and OpenSSF.

Globally installed packages are equally easy to under-scan because they are not always captured by language-native dependency manifests. A build may pin Python, npm, or system packages in one place, then install extras ad hoc during the image build. If the scanner is only reading one package graph, those additions disappear from view. That is why container scanning must inspect the built filesystem and package inventory, not just the declared application dependencies.

The most reliable operational model is to treat the image as the unit of analysis and the build pipeline as the unit of control. That lets teams separate inherited risk from introduced risk, which is the difference between “the app changed” and “the base changed under us.” It also makes ownership clearer when the remediation is to switch base tags, rebuild with patched packages, or change the Dockerfile rather than edit application code.

How to structure scanning so findings are actionable

Scanning should happen at multiple points, but the first meaningful gate is the built image before deployment. That timing catches issues before they are promoted into runtime environments, and it gives security teams the chance to block or quarantine risky artifacts while there is still an easy rebuild path. The scan output should preserve enough context to map a finding to the layer, package manager, or image source that introduced it.

Teams should also separate container scanning from code scanning in reporting, even if they run both in the same pipeline. Code scanning tells you what the developers changed in the application source. Container scanning tells you what the build produced after the base image and installer steps were applied. When those signals are merged too early, ownership gets blurred and teams waste time chasing the wrong fix.

A good workflow is to compare successive image scans so the delta is obvious: what came from the new application build, what came from a refreshed base image, and what was already present in the prior artifact. That makes triage faster and reduces the chance of approving a release because the vulnerability is “known” even though it is still present in the deployed image.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	Container image scanning feeds vulnerability remediation decisions for image components.
	CM-2 — Baseline Configuration	Base images and installed packages should be governed as approved build baselines.
	RA-5 — Vulnerability Monitoring and Scanning	The question is about scanning images to avoid missing vulnerable base and package layers.
Recommendation — Scan built images and track required patches before deployment approval. Baseline approved container images and rebuild when package drift appears. Scan container images continuously and prioritize findings by exploitability and placement.
OWASP ASVS	V13 — Configuration	Image-layer and package composition are configuration concerns that affect deployed security.
Recommendation — Verify deployed containers match approved configuration and exclude unknown packages.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Container image scanning is a vulnerability management control for software artifacts.
Recommendation — Continuously scan artifacts and remediate vulnerable base images before release.

Practitioner Guidance

What to verify: Confirm that your scanner inspects the final image filesystem, not only package manifests, and that it reports OS packages, globally installed language packages, and application dependencies as separate findings. If the tool cannot attribute findings to a base layer or a build step, treat the result as incomplete for release decisions.

Decision rule: If the vulnerability sits in the base image or a globally installed package, fix the image source and rebuild; if it sits in application code, route it to the application owner. That distinction keeps remediation from becoming a generic ticket queue and helps teams avoid patching the wrong layer.

What good looks like: Security teams can answer three questions from one scan result: what in the application is vulnerable, what was inherited from the base image, and what was added during the build. When those three are visible, image risk becomes actionable instead of noisy.

Practitioner takeaway: The safest container scanning programs do not just find vulnerabilities, they preserve layer context so teams can distinguish inherited base-image risk from build-time package risk and fix the right thing first.