An image is a packaged, read-only bundle of filesystem layers and configuration. A container is a running instance created from an image, with its own process and a writable layer. You build, scan and sign images. You run, limit and monitor containers. Mixing them up leads to gaps in patching and security.
What is in an image?
The Open Container Initiative's image format specification defines an OCI image as consisting of an image manifest, an optional image index, a set of filesystem layers and a configuration. Its goal is to let different tools build, transport and prepare a container image to run in an interoperable way.
In plain terms, the layers hold the files, and the configuration says things such as which command to start and which user to run as. The manifest lists the layers by content digest, which means that the same bytes always have the same identifier. An image never changes. A new build creates a new image.
What is a container?
The OCI runtime specification aims to specify the configuration, execution environment and lifecycle of a container. A container's configuration is a file named config.json that lists the fields needed to create it. The execution environment is specified so that applications inside have a consistent environment between runtimes, with common actions defined for the container's lifecycle.
So a container is image content unpacked and started with a configuration: the process to run, mounts, resource limits, namespaces and capabilities. You can start ten containers from one image, and each has its own state while sharing the image layers underneath.
Why does the difference matter for security?
Patching. You cannot patch a running container in a durable way. Changes made inside it vanish when it is replaced. To fix a vulnerable library you rebuild the image, push it and redeploy. A vulnerability scan therefore belongs on images, in the pipeline and in the registry, plus a check that running containers use the fixed image.
Secrets. Anything written into an image layer stays there, even if a later layer deletes it. Secrets should be passed to containers at start from a secrets store, never baked into images.
Provenance. Because images are identified by digest, you can sign them and later verify exactly which bytes are running. A tag such as latest can point to different images over time. A digest cannot.
Runtime limits. Privileges, network access, mounts and resource limits are container settings. An image that runs as a normal user can still be started with extra privileges by its configuration. Review both.
State. A container's writable layer is temporary. Data you want to keep belongs on a mounted volume, which is also something to protect and back up.
A constructed example
A team discovers a vulnerable library in a web service and updates the base image on the build server. Two weeks later the scanner still reports the issue in production. The cause is plain: the running containers were started from the old image, and the deployment pins the old digest. Nothing in the fixed image reached them. The team adds a deploy step that resolves the new digest, and a daily report of running containers whose image digest is older than the latest build.
How to check or apply this
- Treat images as the unit of build, scan, sign and store. Treat containers as the unit of run and monitor.
- Reference images by digest in production deployments, not by tag alone.
- Scan images in the pipeline and again in the registry on a schedule.
- Report which running containers use which image digest, and flag old ones.
- Keep secrets out of image layers. Inject them at start.
- Set container runtime options deliberately: non-root user, dropped capabilities, read-only filesystem where possible.
- Store persistent data in volumes with their own access control and backups.
Quick check
Can one image run as many containers?
Yes. Each container is a separate instance with its own process and writable layer, sharing the image's read-only layers.
If I delete a file in a later layer, is it gone?
It is hidden in the final view, but the earlier layer still contains it. Do not put secrets into any layer.
Sources
- OCI Image Format Specification
- OCI Runtime Specification
- NIST SP 800-190, Application Container Security Guide
Last reviewed: 18 October 2026.
