98% of Container Vulnerabilities Hide Where You're Not Looking

You've invested in container scanning. You're monitoring the big names—Python, Node, nginx. Your security dashboard shows green. But according to new research from Chainguard, you're probably missing 98% of your actual vulnerability exposure.

The data is stark: in a study of more than 1,800 container image projects and 10,100 vulnerability instances observed between September and November 2025, Chainguard found that only 2% of CVEs occurred in the top 20 most popular container images. The remaining 98%—10,785 CVE instances—were hiding in the long tail of less popular images that still run critical production workloads.

This isn't just an academic finding. It's a fundamental challenge to how most engineering teams approach container security.

The Visibility Paradox

The numbers tell a counterintuitive story. According to Chainguard's telemetry from 290,000 images and nearly half a billion builds, the top 20 images account for roughly half of all container pulls. Python appears in 72% of customer environments, Node in 57%, nginx in 40%. These are the images your security tools are optimized to scan, the ones with the most eyeballs and the fastest patches.

But the other half of production usage comes from 1,436 long-tail images that make up more than 61% of the average customer's manifest. These aren't experimental or throwaway containers—they're core components absolutely required for live services and infrastructure.

For every CVE fixed in a top-20 image, Chainguard resolved 50 CVEs in less popular images. That 50:1 ratio should make any engineering leader pause.

The Long Tail Problem Isn't New—But It's Getting Worse

This pattern extends beyond Chainguard's research. A 2024 study by NetRise found that commonly used Docker Hub containers contained an average of 604 known vulnerabilities, with more than 45% of them being two to ten years old. A small but significant fraction of critical and high-severity vulnerabilities had known exploits and active links to ransomware campaigns.

Sonatype's 2024 State of the Software Supply Chain report added another troubling dimension: in 95% of cases where a vulnerable component was used, a fixed version was already available. The problem isn't that patches don't exist—it's that teams don't know what they're running or don't have processes to update the long tail of dependencies.

Academic research has reached similar conclusions through different methods. An analysis published in GigaScience examining scientific container images reported a mean of 460 vulnerabilities per image, largely because images included full operating system distributions and unnecessary packages that were rarely updated.

Why Traditional Scanning Falls Short

Most container security strategies are built around vulnerability scanning in CI/CD pipelines. You scan the base image, check for known CVEs, maybe block deployment if critical issues are found. This works well for the images everyone knows about.

But the long tail operates differently. These images often have:

The structural issue is that security investment follows popularity, but risk doesn't. Your Python base image might get patched within hours. That obscure data processing library three layers deep in your stack? It might sit unpatched for months.

The Compliance Dimension

Regulatory pressure is forcing this issue into the open. Chainguard's report notes that 44% of its customers now run at least one FIPS-compliant image in production to satisfy requirements from frameworks like FedRAMP, DoD IL 5, PCI DSS, SOC 2, the EU Cyber Resilience Act, and HIPAA.

Compliance frameworks increasingly demand cryptographically verified components, signed artifacts, and Software Bills of Materials (SBOMs) that can be matched against vulnerability intelligence. The European Union Agency for Cybersecurity (ENISA) has emphasized the importance of verifiable build provenance—essentially, proving you know what's in your containers and where it came from.

This isn't just box-checking. When you can't enumerate what's running in your production environment, you can't assess risk, plan remediation, or respond to zero-days.

What Actually Works

The research points to several practices that separate teams managing this effectively from those drowning in CVE alerts:

Use minimal base images. The more you include in a container, the larger your attack surface. Stripping out unnecessary packages and OS components can dramatically reduce vulnerability counts. Multiple studies show this is one of the highest-leverage changes you can make.

Rebuild frequently. Even if your application code hasn't changed, dependencies have. Automated rebuilds ensure you pick up patches without manual intervention. This matters more for long-tail images that don't get active development attention.

Generate and maintain SBOMs. You can't patch what you can't inventory. An SBOM gives you a machine-readable manifest of every component in your container, making it possible to quickly identify exposure when new vulnerabilities are disclosed.

Implement policy-as-code. Security vendors report that leading organizations link vulnerability scans to automated policies that can block images with unpatched critical CVEs, missing signatures, or incomplete SBOMs. This moves security left without creating manual bottlenecks.

Track remediation velocity across your entire portfolio. Chainguard's data showed an average remediation time under 20 hours for critical CVEs, with 63.5% addressed within 24 hours—well ahead of their stated SLO of seven days. But this speed applied across both popular and long-tail images because they had systems to identify and patch everything, not just the obvious targets.

The Real Takeaway

If you're only monitoring the top 20 container images in your environment, you've secured 2% of your vulnerability surface. The other 98% is sitting in the long tail, accumulating risk while your security dashboard shows green.

This isn't a problem you can solve by scanning harder. It requires rethinking your entire approach: minimal images, automated rebuilds, comprehensive SBOMs, and remediation processes that cover your full dependency graph, not just the popular packages.

The uncomfortable reality is that modern software runs on a wide, shifting portfolio of open-source components. Most of them live outside the spotlight. That's not where developers spend their time, but it's exactly where security and compliance risk accumulates.

Your container security strategy needs to account for that—or you're protecting the wrong 2%.