Docker Image Vulnerability Checklist: 8 Checks (2026)

An image built six months ago has more known vulnerabilities today than it did on the day it shipped, and nothing about it changed. Secrets baked into a layer during the build stay readable even after a later layer deletes them. This page documents the 8 checks in the CtrlOps Image Vulnerabilities audit, in the order the audit runs them.

This audit reads the images stored on the host, not the containers started from them. Every threshold below is transcribed from the audit script itself. Three of these checks depend on tooling being installed, and the audit is explicit about the difference between "clean" and "nothing scanned it", which is the distinction that makes an image audit worth reading.

Key takeaways

Eight checks, and the three that matter most are the three that need a scanner on the host to answer properly.

• Three are rated HIGH: the CVE scan, the secrets scan and end-of-life base images. Three are MEDIUM and two are LOW.
• Six need root, or docker group membership, because they query the daemon for the image list. Signature verification and the SBOM check read the environment and PATH instead.
• The audit uses what is installed rather than installing anything. trivy drives checks 1 and 3, dockle drives check 7, syft drives check 8. Where the tool is missing, the check says so in the finding instead of quietly passing.
• Scan depth is capped on purpose. Checks 1 and 3 scan the first 5 images, check 4 reads 10, check 7 reads 3 with dockle or 10 without, and check 6 pattern-matches every image tag. A full CVE scan of every image on a busy host is a build-pipeline job, not a 16-second audit.
• The whole audit takes about 16 seconds when CtrlOps runs it over your existing SSH connection.

Check 1: Do any local images contain critical or high CVEs?

A CVE scan compares every package inside an image against the vulnerability databases. Critical and high severity findings are known, published and in many cases have public proof-of-concept code. An image running a critical CVE in production is a door somebody already wrote the instructions for.

The audit takes the first 5 local images, excluding untagged ones, and scans them with trivy for CRITICAL and HIGH findings. If trivy is absent it reports what else is available, because a scan nobody ran is not a pass.

How to check manually

# Scan one image
trivy image --severity CRITICAL,HIGH your-image:tag

# Or the first five local images, the way the audit does
docker images --format '{{.Repository}}:{{.Tag}}' | grep -v '<none>' | head -5 | while read img; do
  echo "=== $img ==="
  trivy image --quiet --severity CRITICAL,HIGH "$img"
done

The distinction to hold on to is warning versus skip. A warning means the audit knows something and wants action. A skip means the audit could not evaluate, and treating it as a pass is exactly the mistake the branch exists to prevent.

How to fix it

# Pin to a specific, patched version and refresh the OS packages
FROM node:20.15.1-alpine3.20
RUN apk update && apk upgrade --no-cache

# For images you do not build, pull a patched tag and rebuild on top
docker pull nginx:1.27.1-alpine
docker build --no-cache -t your-app:1.4.2 .

Then move the gate into CI so a vulnerable image never reaches a server:

- name: Scan image for CVEs
  run: trivy image --exit-code 1 --severity CRITICAL your-image:${{ github.sha }}

Check 2: Are any images using a floating latest tag?

The latest tag is a pointer that moves every time the publisher pushes. Two hosts that pulled it a week apart are running different code with the same name. A deployment on latest can change underneath you on the next pull, with no version in the audit trail to roll back to.

The audit lists local image tags, excluding untagged ones, and reports up to five that end in latest.

How to check manually

docker images --format '{{.Repository}}:{{.Tag}}' | grep -v '<none>' | grep -E ':latest$'

How to fix it

# Not this
FROM python:latest

# A specific version
FROM python:3.12.4-slim-bookworm

# Or a digest, for builds that must be byte-identical
FROM python@sha256:...

services:
  app:
    image: postgres:16.3-alpine

Check 3: Are there secrets embedded in image layers?

Secrets baked into image layers persist forever, even when a later layer deletes the file. Every COPY, ADD and RUN creates a layer, and layers are additive: an API key added in layer 3 and removed in layer 4 is still readable with docker history --no-trunc or by unpacking the layer tarball.

The audit uses trivy's secret scanner across the first 5 local images when trivy is installed. Without trivy it falls back to grepping build history text for AWS_SECRET, PRIVATE KEY, PASSWORD=, API_KEY and SECRET_KEY, and it is explicit that this is a weaker check.

How to check manually

# With trivy, which reads the layer contents
trivy image --scanners secret your-image:tag

# Without trivy, which only reads the build commands
docker history --no-trunc your-image:tag | grep -iE 'AWS_SECRET|PRIVATE KEY|PASSWORD=|API_KEY|SECRET_KEY'

The two warnings are the point of this check. Without trivy, the audit can only read the text of the build commands, which catches RUN export API_KEY=... and misses a key that was copied in as a file. Reading that warning as "no secrets found" is precisely the wrong conclusion.

How to fix it

Use build secrets so the credential never becomes a layer:

FROM node:20-alpine AS builder
RUN --mount=type=secret,id=npm_token \
    NPM_TOKEN=$(cat /run/secrets/npm_token) npm install

FROM node:20-alpine
COPY --from=builder /app /app
USER node

docker build --secret id=npm_token,src=.npm_token .

If a secret is already in a published image, the order matters:

1. Rotate the credential first. It is compromised from the moment the image was pushed or shared.
2. Rebuild from scratch. Do not add a layer that deletes it, because the earlier layer still carries it.
3. Delete the old image everywhere, locally and in every registry that holds a copy.

Check 4: Do images define a non-root default user?

With no USER instruction in the Dockerfile, an image runs as root by default. Every container started from it runs as root unless somebody remembers -u at runtime, which turns a build-time property into a per-deployment discipline problem.

The audit reads Config.User on the first 10 local images and treats empty, root and 0 as root.

How to check manually

docker images --format '{{.Repository}}:{{.Tag}}' | grep -v '<none>' | head -10 | while read img; do
  user=$(docker inspect -f '{{.Config.User}}' "$img" 2>/dev/null)
  echo "$img -> User=${user:-root (default)}"
done

This is the image-side counterpart to check 3 of the Container Hardening audit. Fixing it here fixes it for every container started from the image, which is why it is worth doing even when the runtime override is already in place.

How to fix it

FROM node:20-alpine

RUN addgroup -S appgroup && adduser -S appuser -G appgroup
COPY --chown=appuser:appgroup . /app
WORKDIR /app
USER appuser

CMD ["node", "server.js"]

# For images you do not control
docker run -u 1000:1000 nginx:1.27-alpine

Check 5: Is image signature verification enabled?

Without signature verification, Docker pulls and runs images without confirming who published them. A compromised registry, a typosquatted image name or a manipulated mirror all produce a running container with no warning anywhere in the process.

The audit reads DOCKER_CONTENT_TRUST from the environment and checks whether cosign is on the PATH. It needs no daemon access, which is why this is the one image check that does not need root.

How to check manually

echo "DOCKER_CONTENT_TRUST=${DOCKER_CONTENT_TRUST:-not set}"
command -v cosign >/dev/null && echo "cosign available" || echo "cosign not found"

One caveat worth knowing: the check reads the environment of the audit session. A DOCKER_CONTENT_TRUST=1 exported only inside a CI job, or only in one user's shell profile, is not the same as enforcement, and this check will report it accordingly depending on where it runs.

How to fix it

Adopt cosign, and do not set DOCKER_CONTENT_TRUST:

# Verify a signature before the image runs anywhere
cosign verify --key cosign.pub your-registry.com/your-image:tag

# Enforce it in the pipeline rather than on the host
- name: Verify image signature
  run: |
    cosign verify --certificate-identity-regexp '.*' \
      --certificate-oidc-issuer-regexp '.*' \
      your-image:${{ github.sha }}

If the variable is already exported somewhere on the host, unset it. Leaving it set is now a way to break pulls of Docker Official Images, not a way to secure them.

Check 6: Are any images built on end-of-life base images?

An end-of-life base image no longer receives security patches. Every future CVE in that distribution is permanent for as long as the image is in use, and the only fix is migrating to a supported base rather than updating packages.

The audit pattern-matches every local image tag against a known EOL list: Ubuntu 14.04, 16.04 and 18.04 including the codenames, Debian 7 to 9 including wheezy, jessie and stretch, CentOS 6 to 8, Alpine 3.9 to 3.12, Node 10, 12 and 14, and Python 2.7, 3.5 and 3.6.

How to check manually

docker images --format '{{.Repository}}:{{.Tag}}' | grep -v '<none>' | \
  grep -E 'ubuntu:(14|16|18)\.04|debian:(7|8|9)($|-)|centos:(6|7|8)|alpine:3\.(9|10|11|12)|node:(10|12|14)($|-)|python:(2\.7|3\.5|3\.6)'

The check reads tags, not layer contents. An image built FROM ubuntu:18.04 and retagged as myapp:2.1 will not match, which is a deliberate trade: pattern-matching tags is instant and has no false positives, while proving the actual base means unpacking every image.

How to fix it

Then test properly. EOL to current is usually several releases at once, so expect renamed packages, moved paths and library version bumps rather than a clean swap.

Check 7: Do images follow build best practices?

Build best practices reduce attack surface and make containers operable. A missing HEALTHCHECK means Docker cannot distinguish a healthy container from one that is hung, so a process that stopped responding keeps receiving traffic indefinitely.

The audit prefers dockle, scanning the first 3 images and counting fatal-level findings. Without dockle it falls back to reading Config.Healthcheck on the first 10 images, which is a much narrower question and the finding says so.

How to check manually

# With dockle
dockle your-image:tag

# Without dockle, the fallback the audit uses
docker images --format '{{.Repository}}:{{.Tag}}' | grep -v '<none>' | head -10 | while read img; do
  hc=$(docker inspect -f '{{.Config.Healthcheck}}' "$img" 2>/dev/null)
  echo "$img -> Healthcheck=${hc:-<nil>}"
done

The heuristic pass is a low bar by design: one image with a healthcheck out of ten passes it. This check is LOW severity and exists to tell you whether anyone has thought about build hygiene at all, not to grade it.

How to fix it

HEALTHCHECK --interval=30s --timeout=5s --retries=3 \
  CMD curl -f http://localhost:8080/health || exit 1

# Install dockle for the real audit
VERSION=$(curl -s "https://api.github.com/repos/goodwithtech/dockle/releases/latest" | grep '"tag_name"' | sed -E 's/.*"v([^"]+)".*/\1/')
curl -sfL "https://github.com/goodwithtech/dockle/releases/download/v${VERSION}/dockle_${VERSION}_Linux-64bit.tar.gz" | sudo tar xz -C /usr/local/bin dockle
dockle your-image:tag

Check 8: Is an SBOM generator available?

A Software Bill of Materials is a machine-readable inventory of every package and dependency inside an image. When the next widely exploited CVE is published, an SBOM turns "which of our images are affected" from a scanning project into a query.

The audit checks for syft, then the docker sbom plugin, then trivy's SBOM capability. It reports availability rather than whether SBOMs have actually been produced, which is why this is LOW severity.

How to check manually

command -v syft && echo "syft available"
docker sbom --help >/dev/null 2>&1 && echo "docker sbom available"
command -v trivy && echo "trivy can generate SBOMs"

Like the docker group check, this one has no SKIP branch: the absence of every tool is itself the answer, whether or not Docker is installed.

How to fix it

curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

# CycloneDX is the most widely consumed format
syft your-image:tag -o cyclonedx-json > sbom.json

# Or with trivy, if that is already in your pipeline
trivy image --format cyclonedx your-image:tag > sbom.json

Store the SBOM alongside the image in your registry and index it, so the question "which images contain this package" is answerable in seconds rather than hours.

What this audit does not cover

This audit reads the images stored on the host. It does not check:

• Container runtime hardening. Privileged mode, capabilities, the runtime user and read-only filesystems are the Container Hardening audit.
• Daemon-level controls. Socket exposure, rootless mode and user namespace remapping are the Daemon and Socket audit.
• Network isolation and running-image hygiene. Port publishing, inter-container connectivity and secrets in environment variables are the Network and Supply Chain audit.
• Registry-level scanning. Continuous scanning inside Harbor, ECR or GCR happens where the images live, not on the host that pulled them.
• Application-level vulnerabilities. Logic flaws in the code you built the image around are not visible to a package scanner.

The manual audit problem at scale

Scanning images by hand means installing a scanner, running it per image, reading the output and deciding what each finding means. On one host with five images that is about ten minutes. On ten hosts with different image sets it is an hour, and by the end you have lost track of which host had which finding.

The harder problem is coverage. Manual scans miss images pulled since the last audit, miss hosts that were not on the list, and produce results that live in terminal scrollback rather than in a report anyone compares.

How CtrlOps runs all 8 checks in one click

Instead of running these commands on every server by hand, CtrlOps runs the whole Image Vulnerabilities audit over the SSH connection you already have open. Nothing is installed on the server: no agent, no daemon, no package, no new credentials. The checks are read-only POSIX shell that executes, streams its results back, and leaves nothing behind.

Watch it run

The recording below walks through the SSH and Access audit rather than this one, but the flow is identical for every audit in the catalog: pick it, watch the checks stream in, read the score, send the failures to the AI Terminal.

Step 1: Open the Audit tab

Connect to your server in CtrlOps and open the Audit tab in the left sidebar.

Step 2: Select Image Vulnerabilities

Choose it from the Docker category. All 8 checks are listed with their descriptions, severity levels and the estimated run time, about 16 seconds in total. This is the longest Docker audit, because checks 1 and 3 hand work to trivy.

Step 3: Run it

The audit runs over your existing SSH session. Results stream in as they complete, so you watch each check pass, warn or fail rather than waiting on a final report.

Step 4: Read the report

You get a summary containing:

• A hardening score out of 100
• A severity breakdown: how many HIGH, MEDIUM and LOW findings
• Pass, warning, failed and skipped counts
• A findings table naming the specific images, CVE counts and EOL tags

Step 5: Fix what failed

Select the failed findings and send them to the AI Terminal. Each proposed fix command appears with an explanation of what it changes. Nothing runs until you review and approve it. Most fixes on this page are rebuilds rather than commands on the host, so the useful output here is often the exact Dockerfile change.

Step 6: Re-run and compare

Run the same audit again after rebuilding and watch the score move. Check 1 is the one to re-run on a schedule rather than after changes, because it can go from pass to fail with nothing on the host changing at all.

Conclusion

Image security is the layer where time works against you. A container hardening flag stays set until somebody changes it. A clean CVE scan degrades on its own, quietly, while the image sits in a registry doing exactly what it did last month.

Three of these eight are HIGH severity, and they describe three different versions of the same problem: something inside the image that you cannot see from docker ps. The CtrlOps Security Audit runs the set in about 16 seconds per server and uses whichever scanner the host already has.

The neighbouring checklists cover the other container layers: container hardening, daemon and socket, volume permissions, runtime and resources and network and supply chain.

Frequently asked questions