Public Container Image Vulnerabilities by the Numbers, 2026

Most popular public container images carry known vulnerabilities. An August 2026 arXiv preprint (not yet peer reviewed) scanned 52,895 high-exposure Docker Hub images and found 96.3% with at least one known vulnerability and 93.4% with at least one critical. The exact share depends on the sample, the scanner, the severity source and the image's age.

Nine years of studies have measured Docker Hub, with headline figures ranging from about half of images with a critical issue to almost all of them. They mostly count different things. Below we line up the measurements, compare their methods, explain what base image family does to the counts, and give you a repeatable method for your own images.

Key takeaways

• An August 2026 arXiv preprint from the Federal University of Pampa (UNIPAMPA), not peer reviewed, scanned 52,895 high-exposure Docker Hub images: 96.3% had a known vulnerability, 93.4% a critical and 95.5% a high.
• The 2017 NC State study (CODASPY 2017, data from April 2016) found a median of 76 vulnerabilities in official and 153 in community :latest images, per a contemporary summary.
• Scanner choice moves the numbers. In the 2026 preprint, 66.8% of distinct findings came from only one of three scanners and 2.7% from all three.
• Severity source matters too. Debian and Ubuntu rate CVEs for their own builds and backport fixes, so distro data and NVD can disagree on severity and on whether a package is fixed.
• Official images scored lower than community images in both the 2017 and 2026 studies, and images updated within the last year had a median of 414 findings against 1,085 for older ones (2026 preprint).
• Vulnerable base layers propagate. The 2026 preprint estimates that each of the most widespread CVEs reaches roughly 1.0 to 1.14 million downstream images.
• Do not quote any of these percentages as "X% of containers are vulnerable" without the sample, the date, the scanner and the severity source next to it.

The studies at a glance

The main public measurements of Docker Hub image vulnerabilities we could read, in date order:

We left out two often quoted figures: a 2020 academic study of about 2.2 million images, which we know only through InfoQ's summary (severe CVEs in around 30% of official images), and a hardened image vendor's claim that Debian based official images average more than 30 high or critical CVEs, whose method is not public.

What each study measured, on what sample

NC State, CODASPY 2017: the first large census

Rui Shu, Xiaohui Gu and William Enck built a framework called DIVA to download and analyse Docker Hub images. The abstract reports more than 180 vulnerabilities on average "when considering all versions", a mean inflated by years of old tags. Adrian Colyer's 2017 summary adds that the scan ran in April 2016 with Clair, and that :latest tags had a median of 76 vulnerabilities for official images and 153 for community images. More than 80% of :latest official images had a high severity vulnerability, about a third of community :latest images were over a year old, and child images inherited 80 or more vulnerabilities from parents on average.

Technical lag and a 4 million image scan

Zerouali and colleagues (SANER 2019) asked how out of date each image was rather than how many CVEs it had, measuring "technical lag" in versions, vulnerabilities and bugs across 7,380 Debian based images. Their conclusion: even the newest packages carry known vulnerabilities, so updating lowers the count without reaching zero.

InfoQ reported in December 2020 on a container security vendor's scan of about 4 million Docker Hub images, excluding Windows and untagged images, combining static analysis with containers run on 800 machines for a month. InfoQ reports almost 51% of images had critical vulnerabilities and 68% were vulnerable to some degree. It is a vendor report that sampled almost everything rather than the most pulled images.

UNIPAMPA, arXiv August 2026: the highest exposure images

The newest and most detailed study is Cristhian Kapelinski, Beatriz Machado and Diego Kreutz's preprint "Vulnerabilities, Secrets and Misconfiguration in the Highest-Exposure Docker Hub Images", posted to arXiv on 2 August 2026. It is not peer reviewed yet, so quote it as a preprint.

The sampling is the key to reading it:

1. The authors crawled 12,716,568 repositories using 2,051,801 prefix queries.
2. They resolved 5,601,045 of them (44.05%), giving 6,399,608 tags and 7,416,671 image digests.
3. They ranked about 6.7 million images by an exposure score: an image's own pulls plus the pulls of downstream images built on it.
4. They scanned the top 52,895 repositories, which together account for 84.7% of 663,779,362,551 recorded pulls.
5. For each repository they took one image, the latest, pulled by digest, for linux/amd64 only. Deduplicating by content digest left 51,751 distinct images, which the authors say does not change the results.

So this is not a random sample of Docker Hub. It is the slice of Docker Hub that most pulls actually touch, which is arguably the slice that matters most for real exposure.

Headline results from the 2026 preprint

The severity split of those 141.7 million package vulnerability findings looks like this:

Only about 1 in 20 findings is critical, yet more than 9 in 10 images have one. With hundreds of findings per image, a single critical flips the image into the "has a critical" bucket, so this per image yes or no metric is saturated and says little about which images are riskier.

The authors are careful about the other two figures. The 76.9% secrets figure counts raw detector hits; a hand labelled sample of 1,100 detections held 3 plausible credentials. The misconfiguration figure is dominated by content trust being off (98.0%) and no HEALTHCHECK (94.1%), which are checklist items, not vulnerabilities.

Why headline figures differ

You will see this preprint quoted with different numbers. The HTML version of arXiv 2608.02669 gives 93.4% of images with at least one critical. We have seen 89.2% attributed to the same study in some coverage; we could not find 89.2% anywhere in the paper's HTML text. The safest practice is to quote the paper's own figure and link it.

Beyond misquotes, five method choices explain most of the gap between studies:

1. Sample. Every tagged image (2020), every version of every repository found (2017) and the latest image of the most pulled repositories (2026) are three different populations.
2. Unit. A tag moves, a digest does not, and a repository holds many of both.
3. Scanner and database. Each study matched against different databases at different times. Merging three scanners without deduplication, as the 2026 preprint does, raises the count per image.
4. Severity source. A CVE can be critical in NVD and low in a distribution's tracker.
5. Date. Vulnerability databases grow daily, so the same unchanged image scores higher every year.

None of these makes a study wrong; they make the raw percentages incomparable. What survives across all four studies is the direction: official images score lower than community images, older images score far higher, and vulnerabilities flow from base images into everything built on them.

How much scanner choice and distro backports change the count

Scanner disagreement on the same images

The 2026 preprint is unusual because it ran three vulnerability scanners on the same 52,895 images and then compared what each one found. The numbers are striking.

One scanner also completed only 79.9% of its runs (10,614 errors, mostly cache lock timeouts), against 94.6% to 98.8% for the others. A failed scan that returns zero findings makes an image look clean, so check exit codes. The lesson: a vulnerability count is partly a property of the tool. Switch scanners and your trend line jumps without any change in risk.

Distribution backports and severity

Linux distributions often backport a security fix into an older package without moving to the upstream version number. A scanner comparing against the upstream fixed version flags it; one reading the distribution's advisory data does not.

One widely used open source scanner's documentation states the trade off directly. For operating system packages it uses only the distribution's advisory data (Alpine secdb, Debian's tracker and OVAL, Ubuntu's CVE tracker, Red Hat OVAL, Amazon Linux ALAS) because vendors "usually backport upstream fixes, and the fixed version can be different". Its example is a Python library fixed upstream in 2.31.0 but backported by Red Hat to 2.20.0, where flagging it would be a false positive. It warns that late vendor advisories can cause false negatives, and it prefers vendor severity over NVD, citing a CVE NVD rates high and Red Hat rates low.

The distributions describe their own systems:

• Debian's security tracker marks some issues <no-dsa> when they do not justify a security advisory, often because they are minor. These are usually fixed later in a point release or bundled with a bigger update. <postponed> marks issues waiting for a later advisory, <ignored> marks issues with no update planned, and (unimportant) means the problem does not affect Debian's binary packages. A naive scanner reading NVD will still count all of these.
• Ubuntu assigns its own priority (Critical, High, Medium, Low, Negligible) based on severity, likely exposure, configuration and active exploitation, and states on its CVE pages that its priorities are separate from CVSS and NVD ratings, adding that "CVSS is not a measure of risk". Ubuntu statuses include "Vulnerable, fix deferred" and "Not affected", which a version match alone cannot see.

So one Debian based image can show few criticals under distro severity and many more under NVD severity. Neither source is wrong; they answer "how bad is this flaw in general" and "how bad is it in this distribution's build".

Official images versus community images

What the numbers say

Do not read across rows from different studies. The 2016 medians used one scanner and one severity source; the 2026 medians merge three scanners. Within each study, though, official images come out at roughly half the community count.

What "official" actually means

Docker Official Images are built from a public GitHub repository, docker-library/official-images, where each image has a library file listing its supported tags and the Git commits they build from. The repository's README and its new image checklist describe the review:

• A new image needs an upstream link, an OSI approved license, a documentation pull request, review by two official images maintainers, consideration of an existing official image as its base, and passing tests.
• Dockerfiles should verify downloads over HTTPS, with PGP signatures or embedded checksums. --privileged is generally not allowed.
• The project aims to "actively rebuild for updates and security fixes", and maintainers are expected to handle version bumps and security fixes "in a timely manner". Security releases have their own process, with advance notice to Docker and a [security] prefix on the pull request.

The README does not describe a CVE scanner threshold. Official review is a quality and maintainability review with rebuilds on base updates, not a promise of zero known vulnerabilities. We go through the checklist in more depth in what Docker Official Image review actually checks.

Update cadence

The official images README states that tags are rebuilt only when their library file entry changes or their base image is updated. That means an official image's freshness depends on its base. When debian is rebuilt with a new point release, every official image FROM debian:<tag> that is still listed gets rebuilt. Community images have no such automation unless their maintainers set it up, which is consistent with the 2017 finding that about a third of community :latest images were more than a year old.

Do old tags of official images still get patched?

Only if they are still listed. The official images README says it plainly: only what is in the library file is rebuilt when a base has updates, and tags removed from a library file stay on Docker Hub but are no longer maintained.

So a tag that has left the library file still pulls but quietly accumulates CVEs. The 2026 preprint's age split shows the effect at scale: images updated within the last year had a median of 414 findings, against 1,085 for older images, about 2.6 times as many.

Check that your tag still appears in the image's library file before assuming it is maintained, and track distribution end of life dates; we keep a side by side table in base image support dates for Debian, Ubuntu and Alpine, and a longer look at this question in do old tags of Docker Official Images still get patched.

How base image family changes package count and CVE count

What each family contains, per its own documentation

There is no public dataset of base image market share that we could find. What we can compare is what each family ships, from each project's own docs.

Alpine also says its userland binaries are compiled as position independent executables with stack smashing protection. The distroless README says images contain only an application and its runtime dependencies, are signed with cosign using keyless signing, and need the JSON array form of ENTRYPOINT because there is no shell.

Why fewer packages usually means fewer findings

A vulnerability scanner can only report CVEs in packages it finds. Every package in an image is a lottery ticket in the CVE draw. The 2026 preprint's ranked list of the packages behind the most widespread findings shows the effect of base images clearly: the top five are all core operating system packages.

Few applications chose these; they arrive with the base image. A base without tar or curl cannot be flagged for them. The preprint also reports that most of the 43.1 million critical or high findings sit in operating system packages. So the main effect of base family is package count, while switching distributions also switches the severity source, which can move the critical count without changing real risk.

The trade off: debuggability and libc

Smaller bases cost something, and the trade offs are real:

• No shell, no package manager. You cannot docker exec -it app sh into a distroless image. The distroless project's answer is the :debug tag with a busybox shell, which you use temporarily and never ship. Kubernetes ephemeral debug containers are another route.
• musl versus glibc. Alpine uses musl. Binaries compiled against glibc, including many prebuilt Python wheels and vendor agents, may not run on musl without rebuilding. Distroless, Debian and Ubuntu use glibc.
• Fewer tools for your own scripts. Health checks and entrypoint scripts that call curl, bash or sed need rewriting when those tools are gone.
• Different severity source. Moving from Debian to Alpine changes which advisory feed scores your packages. Do not compare a Debian image's critical count with an Alpine image's critical count as if they were measured on one scale.

For a deeper comparison of the families, see Alpine vs distroless vs Ubuntu base images: security trade offs and our 2026 guide to choosing container base images for security.

How a vulnerable base image propagates downstream

Every FROM line copies the parent's filesystem layers into the child. If the parent ships a vulnerable zlib, every child ships it too unless the child explicitly upgrades it, and most do not.

The 2017 study measured this from the bottom up: child images inherited 80 or more vulnerabilities on average from their parents. The 2026 preprint measured it from the top down. Its single highest reach CVE, a 2026 zlib issue, appeared in 23,726 scanned images that together carried 47.3% of the corpus's exposure. Following the layer graph, the authors estimate that each of the most widespread CVEs reaches roughly 1.0 to 1.14 million distinct downstream images, which the authors express as a propagation factor of 39 to 49. They describe these propagation counts as lower bounds, because they resolved only 44% of repositories.

This is why base image hygiene moves the numbers more than almost any other container fix. One rebuild of a base image with a patched zlib fixes nothing downstream until every child is rebuilt from the new digest. Pinning by digest, which is good practice for reproducibility, makes this worse if nobody updates the pin. For a ranked view of which official bases carry the most findings, see top vulnerable base images on Docker Hub.

How many critical and high findings are actually loaded at runtime?

Static scans count packages on disk. Whether a vulnerable function is ever loaded is a separate question, and there is far less public data on it.

A container runtime security vendor's 2025 usage report press release (12 March 2025) says in use vulnerabilities "have declined to less than 6%", and that 60% of containers live for one minute or less and image sizes have quintupled. The release gives no sample size, data window or definition of "in use"; the full report is behind a registration form we did not fill in. We did not use the same vendor's earlier figures, because mixing report years would mislead.

The direction matches what static studies imply: most findings sit in packages the running process never loads, which is why reachability matters for prioritising. It is not a reason to ignore the rest. Code changes can load a package tomorrow, and an attacker with a shell uses whatever tools are on disk.

How we measured

This post is a comparison of other people's measurements. We did not scan Docker Hub ourselves. Here is exactly what we used and why the numbers cannot be combined.

Datasets used. The studies table above lists sample, unit, scanner and date for each study. Three notes on how we handled them:

1. arXiv 2608.02669 (2 August 2026) is a preprint. Its vulnerability counts merge three scanners without deduplication, and each scanner's severity is mapped to a common six level scale.
2. CODASPY 2017 figures come from Adrian Colyer's 2017 summary and the paper's abstract, because the university server refused our connection to the PDF. The abstract gives 356,218 images in total; the authors' poster cites 86,066 repositories.
3. Vendor figures (the 2020 scan via InfoQ and the March 2025 runtime press release) are cited generically and flagged as vendor produced. Neither publishes its full method on the pages we could read.

Platform facts come only from each project's own documentation: the official images README and checklist, Docker's pull counting docs, Debian's security tracker docs, Ubuntu's CVE priority page, Alpine's about page and the distroless README.

Why they cannot be added or averaged. They count different units (all versions, one tag per repository, digests), with different tools, against vulnerability databases frozen at different dates (2016, 2018, 2020, 2026) and with different severity sources. A 2016 median and a 2026 median share a table only to show the official versus community direction within each study, never to compute a trend.

Pull counts are not users. The 2026 preprint ranks by pulls. Docker's documentation says a pull is a manifest request, a multi architecture pull counts once per architecture, and version checks are counted separately. CI systems pull the same image many times a day, so a high pull count signals heavy automation, not necessarily many organisations.

What we could not verify. The 89.2% figure attributed to the 2026 preprint in some coverage; the full text of the 2020 academic study of 2.2 million images; the method behind the hardened image vendor's Debian figure; and the definitions inside the runtime vendor's gated report.

Measure your own images the same way: a step by step method

A number only means something if you can reproduce it next month. This method fixes the variables that made the studies above disagree: the image identity, the platform, the date, the tool and the severity source.

Step 1: Resolve the tag to a digest and record it

Tags move; digests do not. Record both, with the date.

# Resolve a tag to its index digest (multi-arch)
crane digest python:3.13-slim

# Show per-platform manifests inside the index
docker buildx imagetools inspect python:3.13-slim

# Record what you are about to scan
echo "$(date -u +%F) python:3.13-slim $(crane digest python:3.13-slim)" >> scans.log

Step 2: Fix the platform

The 2026 preprint scanned linux/amd64 only. Packages can differ by architecture, so pick one and stick with it.

docker pull --platform linux/amd64 python@sha256:<index-digest>
crane manifest --platform linux/amd64 python:3.13-slim | jq '.layers | length'

Step 3: Count packages before counting CVEs

Package count explains most of the difference between base families, so measure it directly.

# Debian or Ubuntu based
docker run --rm --entrypoint sh python:3.13-slim -c 'dpkg-query -W | wc -l'

# Alpine based
docker run --rm --entrypoint sh python:3.13-alpine -c 'apk info | wc -l'

# Distroless has no shell: list the package metadata files instead
crane export gcr.io/distroless/python3-debian13 - | tar -t | grep '^var/lib/dpkg/status.d/' | wc -l

Step 4: Find the base image

Check whether the image declares its base with the OCI annotations org.opencontainers.image.base.name and org.opencontainers.image.base.digest, and look at the layer history.

crane manifest myorg/api:1.4.2 | jq '.annotations'
crane config myorg/api:1.4.2 | jq '.config.Labels'
docker history --no-trunc myorg/api:1.4.2 | head -20

Step 5: Scan with one tool, one database date, one severity source

Use the same scanner and version for every run, and write down which severity source it used. With Safeguard, scan a container image directly:

safeguard scan --image python@sha256:<digest>
# Results are written as JSON under ./output

Whatever scanner you use, report four numbers separately, never as one total:

1. Findings in operating system packages, using the distribution's severity.
2. Findings in language packages (npm, PyPI, Go modules, Maven), using the ecosystem advisory severity.
3. Findings with a fix available versus without one.
4. Findings in packages your application actually loads, if your tool provides reachability.

Step 6: Compare base families with the same application

To see what base family choice changes, build your application on two or three bases and scan each on the same day:

# Dockerfile.slim
FROM python:3.13-slim
COPY app/ /app
RUN pip install --no-cache-dir -r /app/requirements.txt
ENTRYPOINT ["python", "/app/main.py"]

# Dockerfile.distroless (multi-stage)
FROM python:3.13-slim AS build
COPY app/ /app
RUN pip install --no-cache-dir --target=/deps -r /app/requirements.txt

FROM gcr.io/distroless/python3-debian13
COPY --from=build /deps /deps
COPY --from=build /app /app
ENV PYTHONPATH=/deps
ENTRYPOINT ["python3", "/app/main.py"]

Note that the distroless Python version follows Debian 13's packaged Python, not the 3.13 tag on the build stage, so check that versions match before shipping.

docker build -f Dockerfile.slim -t app:slim .
docker build -f Dockerfile.distroless -t app:distroless .
safeguard scan --image app:slim
safeguard scan --image app:distroless

Step 7: Verify signatures where the base publishes them

The distroless README documents keyless cosign signatures:

cosign verify gcr.io/distroless/static-debian13 \
  --certificate-oidc-issuer https://accounts.google.com \
  --certificate-identity keyless@distroless.iam.gserviceaccount.com

Step 8: Run it on a schedule in CI

The image does not change, but the vulnerability databases do. Rescan pinned digests on a schedule so you catch new CVEs in images you already ship.

# .github/workflows/image-scan.yml
name: nightly-image-scan
on:
  schedule:
    - cron: "17 3 * * *"
  workflow_dispatch:
jobs:
  scan:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        image:
          - myorg/api@sha256:<digest>
          - myorg/worker@sha256:<digest>
    steps:
      - name: Install the Safeguard CLI
        run: echo "Install as described at https://docs.safeguard.sh/docs/cli"
      - name: Scan image
        run: safeguard scan --image "${{ matrix.image }}"
      - name: Keep results
        uses: actions/upload-artifact@v4
        with:
          name: scan-${{ strategy.job-index }}
          path: output/

Store the JSON results with the date and digest, and you have your own time series that is comparable with itself, which is the only comparison that really matters.

Where the datasets disagree, and which figures not to quote

Common mistakes

Reading the data

• Treating "has a critical" as a risk score. With a median of 885 findings per image, nearly every image has one.
• Comparing counts across scanners or distros. Scanners differed 1.55 times on identical images, and Alpine and Debian are scored by different feeds.
• Mixing years of one vendor's report series, or reading pulls as users.

Acting on it

• Pinning a digest and never updating it. Reproducibility without rebuilds freezes CVEs in place.
• Staying on a tag that left the library file. It still pulls; it no longer rebuilds.
• Moving to a minimal base without a debug plan, or assuming official review means zero CVEs.

Fix it without waiting for upstream

Every study above points at the same root: most findings arrive with the base image and stay until someone rebuilds. The fastest way to shrink them is to start from base images that are already patched, and to keep patching the application layers on top.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

For images specifically: Safeguard scans container images (safeguard scan --image <name>) with reachability context and evaluates results against policies and gates, so an image that breaks your rules can be held back. Swapping a Dockerfile's base image remains your team's change to review and merge.

FAQ

What percentage of Docker Hub images have vulnerabilities?

It depends on the sample. An August 2026 arXiv preprint (not peer reviewed) found 96.3% of 52,895 high exposure images had a known vulnerability and 93.4% a critical. A 2020 vendor scan of about 4 million images, reported by InfoQ, found almost 51% with criticals.

Are Docker Official Images safe to use?

They are reviewed, built from public Dockerfiles and rebuilt when their base updates, and carried about half the findings of community images in both studies. They are not CVE free: the 2026 preprint reports a median of 455 merged findings.

Why does my scanner show different results from another scanner on the same image?

Different databases, matching logic and severity sources. In the 2026 preprint, two thirds of distinct findings came from only one of three scanners.

Why does a scanner flag a Debian package that Debian says is fixed?

Debian often backports security fixes without changing to the upstream version number. A scanner that compares against upstream fixed versions will still flag the package; one that reads Debian's security tracker will not.

Is Alpine more secure than Debian slim?

Alpine images usually ship fewer packages, so scanners usually report fewer findings. Alpine uses musl rather than glibc, which can break prebuilt binaries, and its findings are scored by a different advisory feed, so the counts are not on one scale. Test your own application on both.

Does distroless mean zero vulnerabilities?

No. Distroless images drop the shell and package manager and ship far fewer packages, but what remains comes from Debian and inherits Debian's vulnerabilities.

Do old Docker image tags get security updates?

Only while they are listed in the image's library file in the official images repository. Tags removed from the file stay pullable but are no longer rebuilt.

How many container vulnerabilities are actually exploitable at runtime?

Public data is thin. A runtime security vendor's March 2025 report says in use vulnerabilities fell below 6%, but its definitions are in a gated report. Static studies, including the 2026 preprint, explicitly say their findings are not confirmed exploitable.

See how Safeguard would help

The first demo is a real Safeguard CLI session: it is asked to fix the lodash CVE in a repository, reads the finding, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval and pushes nothing. The same CLI scans images with --image, so fixes to the application layers above your base follow the same approval flow.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with its device code and scans from the terminal. It is the setup step for rescanning pinned digests on your own hardware.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and shows how to choose which tools Claude can use. Once connected, you can ask about the findings in your scanned projects in plain language, for example which images share a vulnerable base package.

Click through it at your own pace, or open it full screen.

You can download Safeguard at safeguard.sh/download and read the CLI documentation at docs.safeguard.sh/docs/cli. For survey data on how teams run container security, see our state of container security 2026 survey summary, and for real incidents involving images, container image supply chain incidents in 2026.

Quick check

Sources

• Kapelinski, Machado and Kreutz: Vulnerabilities, Secrets and Misconfiguration in the Highest-Exposure Docker Hub Images (arXiv 2608.02669, preprint)
• Adrian Colyer, The Morning Paper: A study of security vulnerabilities on Docker Hub (summary of Shu, Gu and Enck, CODASPY 2017)
• Zerouali, Mens, Robles and Gonzalez-Barahona: On the Relation Between Outdated Docker Containers, Severity Vulnerabilities and Bugs (arXiv 1811.12874, SANER 2019)
• InfoQ: Docker Hub image vulnerabilities (December 2020)
• docker-library/official-images README
• docker-library/official-images new image checklist
• Docker docs: Docker Hub usage and pulls
• Debian security tracker documentation
• Ubuntu: About CVE priorities
• Alpine Linux: About
• GoogleContainerTools distroless README
• A container runtime security vendor's 2025 cloud native security and usage report press release (12 March 2025)
• One open source scanner's vulnerability scanning documentation (severity and backport handling)

Last reviewed: 23 October 2026. Figures are as published by each source on the dates shown; check the linked studies for later versions.