Home / Knowledge hub / Container image scanning
Knowledge hub
Container image scanning
Checking a built image for known-vulnerable packages before it ships.
What it means
Container image scanning is the automated check of a container image against databases of known vulnerabilities. The scanner unpacks the image, lists the operating system packages and application libraries inside, and reports any that match a published flaw. The whole check takes seconds and needs no running container.
An image is built in layers, starting from a base image you did not write. A scan reads every layer, so it finds old libraries inherited from the base as well as ones you added. It reports known problems in what is installed. It does not test how your own code behaves.
Why it matters
Images ship into production unchanged, so a vulnerable package in the image is a vulnerable package in production. Scanning catches those before release and tells you which base image or library to update. It is a routine expectation in security questionnaires and in supply chain guidance.
New flaws are published after an image is built, so a clean scan today says nothing about next month. Scanning belongs with software composition analysis and an SBOM, and its results need judging, since many reported flaws sit in code that never runs.
How it shows up
You meet it in the build pipeline, in the container registry, and on running clusters. Repeated problems are very large base images full of unused packages, findings nobody triages so the list only grows, scans run once at build and never again, and images pulled by a floating tag such as latest.
Use a small base image, scan at build and again on a schedule, fail the build on serious fixable findings, and rebuild regularly to pick up updates. Treat findings as input to triage, not as a verdict. A scan does not replace testing the running application.
Questions people ask
Container image scanning, answered
What does an image scanner actually check?
It reads the packages and libraries installed in the image and compares their versions with vulnerability databases. Some scanners also flag exposed secrets and risky configuration. They do not exercise your application's logic.
Why rescan an image that passed?
Because vulnerabilities are published every day against software that already exists. An image that was clean at build can contain a known flaw a week later. Scheduled rescans and registry scans catch that.
Does a clean scan mean the container is secure?
No. It means no known flaw was matched in the packages found. It says nothing about your own code, your configuration, or flaws not yet published, so treat a pass as one input and not as a sign-off.
What is a good base image strategy?
Choose a small, maintained base with only what you need, pin it by version or digest, and rebuild when it updates. Fewer packages means fewer findings and a smaller attack surface.
How is it different from a penetration test?
Scanning lists known-vulnerable components. A penetration test attempts to exploit weaknesses in the running application, including ones in your own code, and proves which findings matter. The two answer different questions.
Sources
Where this comes from
Related
Terms that sit next to this one
Base image
The starting image your container builds on, and the old packages it can bring.
Software composition analysis
Inventorying your open-source parts and flagging the ones with known flaws.
SBOM
A list of every component your application includes, with versions.
Docker
A tool for packaging an app and its dependencies into a portable container.
Container registry
The store that holds your images, which needs its own access control.
Is the vulnerable part even reachable?
A scan tells you what is installed, not what an attacker can reach. We test the running app and report only what we exploited, so you can rank scanner findings by proof. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.