Home / Knowledge hub / Base image
Knowledge hub
Base image
The starting image your container builds on, and the old packages it can bring.
What it means
A base image is the image named in the FROM line of a Dockerfile. Your application is layered on top of it. The base brings an operating system layer, system libraries, and sometimes a language runtime.
Everything in it ships with your app, whether you use it or not. A full distribution image may include a shell, a package manager and hundreds of packages. A minimal one may contain only what the app needs to start.
Why it matters
Each extra package is something that can carry a known flaw. When a new vulnerability appears in a system library, every image built on a base that includes it is affected, even though you never wrote that code. This is a form of known vulnerable component risk.
Old bases are the common problem. An image built a year ago and never rebuilt keeps a year of unpatched packages, so a service that has not changed can still become less safe.
How it shows up
Choose a small base from a source you trust, such as an official image, and pin it by digest so a tag cannot silently change underneath you. Rebuild on a schedule to pick up fixes, and scan the result with image scanning.
Repeating mistakes include using latest, copying a base from an unknown publisher, leaving build tools in the final image, and running as root. Multi-stage builds keep compilers out of what you ship, and distroless images go further.
Questions people ask
Base image, answered
What is the safest base image?
There is no single answer, but smaller is better. Fewer packages mean fewer flaws and less for an intruder to use.
Why pin by digest?
A tag such as 1.2 can be moved to a different image later. A digest identifies exact content, so your build is repeatable.
Is the latest tag a problem?
Yes. It changes without notice, so builds are not repeatable and a surprise change can break or weaken your app.
How often should we rebuild?
Often enough to pick up security fixes, and immediately when a serious flaw is published in something your image includes.
Are official images always safe?
They are maintained and a sensible start, but they still age and still contain packages with flaws. Scan them like any other.
Sources
Where this comes from
Related
Terms that sit next to this one
Container image scanning
Checking a built image for known-vulnerable packages before it ships.
Distroless image
A minimal container image with no shell or package manager for an attacker to use.
Docker
A tool for packaging an app and its dependencies into a portable container.
Known-vulnerable component
A library or runtime with a published flaw that you are still shipping.
Package pinning
Fixing a dependency to one exact version rather than accepting any newer release.
How old is your starting point?
Old packages matter when they can be reached. We test the running application and report what we actually exploited. Ask us to run it on one of your applications.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.