Cybersecurity glossary
What is Container Image Scanning?
Learn what container image scanning is, how scanners map packages in layers to CVEs, where they miss risk, and how to gate registries and clusters on scan policy.
Definition
Container image scanning is the automated inspection of image layers, package inventories, and sometimes file contents to detect known vulnerabilities, malware, secrets, and policy violations before or after an image is deployed.
Why container image scanning matters
Clusters pull thousands of images. Humans will not read every Dockerfile or every distro advisory. Container image scanning turns each digest into an inventory: which packages shipped, which known CVEs they carry, and whether secrets or malware rode along in a layer.
Without that inventory, “we use containers” is an untracked software supply chain. With only that inventory, teams still miss runtime misconfig—so scans are necessary, not sufficient.
What a scan actually does
Resolve the digest
The scanner pulls or mounts a specific sha256, not a floating tag that may change mid-job.
Build a package inventory
OS packages, language libraries, and sometimes binaries are listed per layer.
Match known vulnerabilities
CVE and advisory databases score each component; KEV and exploit flags raise priority.
Inspect files and config
Optional checks look for secrets, malware signatures, and risky image metadata such as root user.
Enforce policy
CI, registry, or admission compares results to severity, fix-available, and exception rules.
Findings scanners are built to catch
OS package CVEs
glibc, openssl, and distro packages inherited from the base image.
Application libraries
Language dependencies copied into the image, overlapping with SCA on source.
Embedded secrets
Keys and tokens left in layers, history, or accidentally copied config files.
Policy violations
Root user, extra capabilities in image config, or disallowed base registries.
Where image scanning sits in the pipeline
| Stage | Strength | What it can miss |
|---|---|---|
| CI on build | Fast developer feedback on the digest about to be pushed | Images imported by hand or rebuilt on a laptop |
| Registry on push | Central coverage of every stored digest | Runtime installs and sidecars not in that image |
| Admission / deploy | Blocks unscanned or newly critical digests from the cluster | Workloads that bypass the constrained API path |
| Periodic rescan | New CVEs on old digests still running in production | Nothing if nobody rebuilds after the new finding |
Image scanning program checklist
- Scan by digest in CI and fail on policy, not on raw CVE count alone.
- Rescan stored and running images when new advisories land, especially KEV items.
- Prefer fix-available and reachable/exploitable signals over alerting on every Low.
- Rebuild from updated bases on a cadence so backlogs do not become permanent exceptions.
- Rotate any secret the scanner finds; rebuilding without rotation leaves the old credential valid.
- Record scanner name, database version, and SBOM next to the digest for audit.
- Block public unscanned images at admission; allow only signed internal registries.
- Treat scan-clean as one control beside pod security, network policy, and least-privilege IAM.
The practical takeaway
Container image scanning inventories a digest and maps it to known vulnerabilities, secrets, and policy breaks. It is how you stop shipping yesterday’s CVEs at cluster scale.
Pin scans to digests, enforce them in CI and at admission, and rebuild when findings are real. A green report is not a secure workload—it is a necessary inventory of the bits you chose to run.
Related security terms
Container Image
The layered artifact that scanners inventory and score.
Software Composition Analysis (SCA)
Related analysis of application dependencies; image scans also cover OS packages.
Image Registry
Where scans often run on push and where policy can block promotion.
CI/CD Pipeline
The usual place to fail a build when a scan exceeds severity thresholds.
Kubernetes Admission Controller
A last gate that can reject unsigned or unscanned digests at deploy time.
Frequently asked questions
What is container image scanning in simple terms?
A tool unpacks or indexes the image, lists OS and language packages, matches them to CVE databases, and optionally hunts for secrets or malware—then reports a risk score for that digest.
Does a clean scan mean the image is safe?
No. Scanners miss unknown vulnerabilities, misconfiguration in how the image will run, and most application logic bugs. They also cannot see packages installed at container start.
Should I scan in CI, in the registry, or in the cluster?
All three have a role. CI is fast feedback, registry scanning covers images that bypassed CI, and admission or runtime scans catch drift and newly published CVEs.
Why do two scanners disagree?
They use different SBOMs, distro mappings, severity sources, and ignore lists. Compare on the same digest and document which database and scanner version you trust.
What is a false positive in image scanning?
A CVE that does not apply to how the package is compiled, configured, or reached. Fix real reachable issues first; suppress with expiry and evidence, not a permanent mute.
Do I need to rebuild for every CVE?
Rebuild when the vulnerable package is in your image and is reachable or high severity. Distroless and frequent base updates reduce the rebuild tax.
Can scanners find secrets in layers?
Many can grep for keys and tokens in files and history. They will not catch every secret format, and a finding means the credential must be rotated, not only rebuilt.
References
Explore authoritative guidance and frameworks related to container image scanning.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.