Container Images website (opens in a new tab)Container Images
Ready-made images from Docker Hub and other registries that containers start from.
About
A container image bundles an application with the files of a cut-down operating system and everything else it needs. Most images start from a public base image on Docker Hub or another registry, so they inherit whatever that base contains. Pulling an image by a tag such as latest can give a different image tomorrow.
Nothing runs when an image is pulled. Its code runs every time a container starts from it, with whatever rights, network access and secrets the container is given.
If It Is Malicious
If a container image is malicious, it runs as a container with whatever rights and secrets it is given, on every host that pulls and starts it.
Its code runs inside these technologies.
Examples
These are well-known names from Container Images, written as you would meet them in an inventory, an alert or a lockfile, the file that records every version a build installed.
node- The official Node.js image, a common base for apps.
python- The official Python image.
nginx- The official nginx web server image.
alpine- A tiny Linux base that many other images build on.
postgres- The official PostgreSQL database image.
How Bad Code Gets In
These are the ways bad code can reach your systems through Container Images. None of them needs a flaw in your own code, so outside code needs checking as much as your own.
- An image named like an official one carries a cryptominer or a backdoor.
- A base image carries an old flaw, and every image built on it inherits it.
- A tag is moved to a new image, so the same name pulls different code.
How to Check
These checks show what came from Container Images, whether a known bad version is in use, and how to keep one out next time.
- Pull by digest, the image's fixed fingerprint, not only by tag, so the image cannot change under you.
- Scan images with a tool such as Trivy, Grype or Docker Scout, in the build and in the registry.
- Keep an SBOM for each image you ship, so you can find a named package later.
- Prefer official images, and check signatures with Cosign where the publisher signs them.
- Pull through a private registry or mirror that you control.
Well-Known Incidents
Each incident below is a real case, told at the level of its public advisory. The tag says how the bad code got in, and the link opens the primary source.
Vulnerable DependencyCVE-2019-50212019
Empty Root Password in Alpine Images
Official Alpine Linux images on Docker Hub, from version 3.3 until the flaw was found in 2019, shipped with an empty root password.
Reach Every image built on those bases inherited it. Where a container also used PAM, the Linux sign-in system, or the shadow password file, it could accept an empty password for root.
Affected
Source: talosintelligence.com (opens in a new tab)alpine
In Common Stacks
These common stacks take code from Container Images. Open one to see where that code sits among its layers and who runs each one.