Container Image Scanning and Software Supply Chain Security

A container image is rarely code your own team wrote. It's a base OS layer maintained by someone else, a language runtime maintained by someone else, and a stack of package dependencies each maintained by someone else, and by the time your application's own few hundred lines get added on top, the resulting image can easily be 95% other people's code. Nothing about writing secure application logic protects against a known, unpatched CVE sitting in the base layer underneath it.

What image scanning checks

Container image scanning inspects every layer of a built image against known-vulnerability databases, the same CVE data that powers our own CVE Lookup tool, flagging outdated packages, known-exploitable library versions, and (in more thorough scanners) hardcoded secrets or credentials accidentally baked into a layer during the build. The critical distinction from application-level SAST: image scanning inspects what actually gets deployed, which includes the OS packages, language runtime, and every transitive dependency pulled in at build time, code your team never wrote and, without a scan, never reviewed.

Why this is different from Kubernetes hardening

It's easy to conflate this with runtime container security, but they're different problems at different stages. Kubernetes and container misconfigurations, privileged pods, exposed API servers, missing network policies, are about how a container is run. Image scanning is about what's inside the container before it ever runs anywhere. A perfectly hardened Kubernetes cluster running a container built from an image with a known-exploitable CVE in its base layer is still exposed; the runtime configuration doesn't fix vulnerable code sitting inside the container itself.

What an SBOM gives you

A Software Bill of Materials, a structured, complete inventory of every component and dependency that went into a piece of software, is what makes "are we affected by this new CVE" answerable in minutes instead of days. CISA's SBOM guidance frames it as a foundational supply-chain transparency tool for exactly this reason: when a new critical vulnerability is disclosed in a widely-used library, the kind of event that triggers an all-hands scramble, an organization with real SBOMs across its container images can search that inventory directly, instead of manually auditing every running service to find out if it's affected.

Where this connects to a broader supply-chain risk

Container image scanning is the technical, automatable slice of a much larger problem our piece on third-party and supply chain risk covers more broadly, every dependency, vendor, and integration an organization relies on inherits into its actual attack surface, whether or not anyone's specifically reviewing it. Images pulled from public registries carry the same trust question as any other third-party component: who built this, what's actually inside it, and is anyone tracking when a component inside it gets a CVE disclosed against it later.

Closing the gap

• Scanning images at build time in CI, not just periodically in a running registry, so a vulnerable image never reaches deployment in the first place, the same "belongs at build stage" principle covered in our DevSecOps piece
• Generating and retaining a real SBOM for every deployed image, not just for the ones a compliance requirement specifically names
• Pinning base images to specific, reviewed digests rather than a floating latest tag, so what actually deploys doesn't silently change underneath a supposedly-unchanged Dockerfile
• Re-scanning already-deployed images against newly disclosed CVEs on a schedule, since a component that was clean at build time isn't guaranteed to stay that way

This is a standard part of the scope in our Cloud Security engagements, reviewing the actual build pipeline and image provenance, not just the running infrastructure on top of it.