What's Actually in Your Container? The Case for Image Scanning

Containers made shipping software wonderfully reproducible by packaging an application with everything it needs to run. That same convenience hides a security reality many teams never confront: a container image is not just your code. It is your code layered on top of a base operating system, system libraries, language runtimes and dozens or hundreds of dependencies — each of which may carry known vulnerabilities you never chose and often do not know are there.

Image scanning is the practice of finding out what is actually inside the images you build and run, so you are not shipping known holes to production unaware.

The hidden inventory

When you build from a base image and install dependencies, you inherit everything in that stack. A vulnerability disclosed last month in a common system library is present in your image if that library is present, whether or not your code uses it directly. Multiply this across every image and every dependency, and the average container carries a surprising number of known vulnerabilities the moment it is built — not because anyone was careless, but because that is the nature of assembling software from layers.

You cannot manage what you cannot see. The first value of scanning is simply the inventory: a clear list of what is inside and which components have known issues.

Scan across the lifecycle

Scanning is most powerful when it happens at several points. Scanning base images before adopting them lets you choose lean, well-maintained foundations over bloated, stale ones. Scanning in the build pipeline catches vulnerabilities before an image ever ships, and can block a release that introduces a critical, fixable flaw. Scanning images already running in production catches newly disclosed vulnerabilities in things you deployed before they were known to be vulnerable — because yesterday's clean image is today's vulnerable one the moment a new CVE lands.

That last point matters: image scanning is not a one-time gate but an ongoing watch, because the vulnerabilities change even when your image does not.

Turning findings into action

A scan that produces a giant list nobody acts on is theater. The value comes from prioritization and response: focus on vulnerabilities that are critical, have a fix available, and are actually reachable, rather than drowning in every low-severity finding. Many issues are resolved simply by rebuilding on an updated base image or bumping a dependency version. Choosing minimal base images shrinks the attack surface dramatically — fewer components means fewer vulnerabilities to begin with.

The broader discipline this feeds is supply-chain security: knowing your ingredients, keeping them current, and being able to answer "are we affected?" quickly when the next widespread vulnerability is announced. Scan your images, keep the bases lean and current, prioritize the fixable and reachable, and you replace the alarming question "what are we running?" with a confident, current answer.

How scanners actually work

Most image scanners work in two steps. First they build an inventory by reading the image layers: operating system package databases, language manifests and lock files, and sometimes binaries whose versions can be fingerprinted. Then they compare that inventory against vulnerability databases maintained by distributions, language ecosystems and public advisories. Understanding this explains their blind spots. Software copied into an image by hand, compiled from source or downloaded with a script may not be recognized at all, and a scanner cannot report a vulnerability in a component it does not know is there.

Software bills of materials

A software bill of materials, usually shortened to SBOM, is a machine-readable list of the components in an image together with their versions. Generating one at build time and storing it next to the image changes how quickly you can respond to news. When a serious vulnerability is announced in a popular library, you can search your stored inventories in minutes instead of re-scanning every image or asking every team. Standard formats exist, and many build tools and registries can produce and attach them automatically, so the cost of starting is low.

Choosing base images deliberately

The base image is the largest single source of inherited vulnerabilities, and the choice is often made once and never revisited. Prefer official or well-maintained images that receive regular security updates, and check how quickly the maintainers publish fixes. Minimal images, such as slim distributions or distroless images that contain only the runtime your application needs, remove shells, package managers and utilities that attackers find useful and that scanners would otherwise flag. Standardizing on a small set of approved bases across teams also means one rebuild fixes many services at once.

Multi-stage builds

Build tools, compilers and test dependencies are needed to produce an application but not to run it. Multi-stage builds use one image to compile and a second, clean image to run, copying across only the finished artifacts. The final image is smaller, starts faster and carries far fewer components that could be vulnerable. This single technique often removes the majority of findings from a scan report without changing a line of application code, which makes it one of the most cost-effective improvements available.

Pinning, digests and rebuilds

Tags like "latest" are moving targets: the same tag can point to different contents tomorrow, which makes builds unpredictable and scanning results hard to interpret. Pin base images to specific versions or, better, to content digests, so that what you scanned is exactly what you run. Then update those pins deliberately and frequently, using automated pull requests that bump the base and trigger a rebuild and scan. Pinning without updating is its own trap, because it freezes an image at the vulnerability level of the day it was pinned.

Severity is not the same as risk

Scanners report severity scores computed for the vulnerability in general, not for your environment. A critical flaw in a library function your application never calls may matter less than a medium one in an internet-facing parser. Add context when prioritizing: is the component used at runtime, is the service exposed to the internet, does it handle untrusted input, does it run with high privileges, and is the vulnerability being actively exploited in the wild? Public catalogues of known exploited vulnerabilities and exploit-prediction scores help separate urgent findings from theoretical ones.

Policies that do not block everything

A pipeline gate that fails every build with any vulnerability will be disabled within a week, because almost every image has some. Set policies teams can live with: block new critical and high vulnerabilities that have a fix available, warn on the rest, and require a documented exception with an expiry date when a fix cannot be applied yet. Track exceptions centrally so they do not become permanent. The aim is steady improvement and fast response to serious issues, not a perfect report that nobody believes.

Registries and admission control

Scanning at build time is not enough if anything can be deployed from anywhere. Use a private registry as the single source of images for production, scan images there continuously, and configure the cluster or platform to accept only images from approved registries. Image signing lets the platform verify that an image was produced by your own pipeline and has not been altered since. Together these controls close the gap through which an unscanned image pulled from a public source could reach production.

Secrets and configuration in images

Scanners increasingly look for more than vulnerable packages. Images sometimes contain secrets baked in during the build — API keys, certificates, cloud credentials — which anyone with access to the image can extract, even if a later layer deletes the file. Keep secrets out of images entirely and inject them at runtime from a secrets manager. Also check configuration: containers running as root, unnecessary open ports and writable file systems increase the damage an attacker can do if they find a way in.

Runtime context and defense in depth

Scanning reduces known vulnerabilities but cannot eliminate unknown ones, so limit what a compromised container can do. Run as a non-root user, drop unnecessary Linux capabilities, use read-only file systems where possible, restrict network access between services and apply resource limits. Runtime monitoring can flag unexpected behavior such as a shell spawning inside a web container. These measures mean that when a vulnerability is exploited before anyone knew about it, the attacker finds a cramped, closely watched space rather than a launchpad.

A workable rollout

Start by scanning images in your registry to see where you stand, without blocking anything. Fix the easy wins: switch to minimal bases, adopt multi-stage builds and rebuild stale images. Add scanning to the pipeline with a gate for fixable critical issues, generate SBOMs for every build and schedule automatic base-image updates. Finally, add admission control and runtime hardening. Measured over a few months, the number of known vulnerabilities in production typically falls sharply, and the answer to "are we affected?" arrives in minutes. Share those figures with the teams that own each service, so that progress is visible and celebrated.