The latest State of Trusted Open Source report from Chainguard gives details on current industry thinking about vulnerabilities in container images and the long tail of open-source dependencies. The report offers a data-driven view of production environments based on more than 1,800 container image projects and 10,100 vulnerability instances observed between September and November 2025.
Chainguard draws on telemetry from 290,000 images and almost half a billion builds to examine how customers actually consume and maintain open source components. It finds that foundational language and infrastructure images such as Python, Node, nginx, Go and Redis dominate production usage, forming what it describes as the baseline stack for the modern AI-driven software ecosystem. Python appears in about 72% of customer environments, with Node in 57% and nginx in 40%. These images are associated with model development, data processing, and inference workloads, as well as with surrounding observability and platform tooling.
However, the report warns that this visible layer of popular images is only a small part of the real landscape. The top 20 images account for about 1.37% of Chainguard’s catalogued images and roughly half of all container pulls. 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. Chainguard stresses that these long-tail images are often core components that are absolutely required for live services and infrastructure, rather than being short-lived experiments.
The distribution of vulnerabilities is highly skewed toward this long tail. Chainguard reports that only 214 of the CVE instances it remediated in the period, around 2%, occurred in the top 20 images. The remaining 98% (10,785 CVE instances) were in images outside that set. This finding suggests that the worst exposure sits in the parts of the stack where patching and governance are hardest to apply. For every CVE fixed in a top-20 image, the company says it resolved 50 CVEs in less popular images, a ratio it uses to illustrate the importance of working on the long tail of security. While the majority of these issues are medium severity, the report argues that organisations care most about how quickly critical and high-severity issues are resolved across their range of images.
On this measure, Chainguard emphasises how quickly they can fix security issues. During the three-month window, the company says it achieved an average remediation time of under 20 hours for critical CVEs, with 63.5% addressed within 24 hours, 97.6% within two days and all of them within three days. Chainguard fixed high-severity vulnerabilities in just over two days, medium-severity ones in about two and a half days, and low-severity issues in just over three days. These times are notably faster than Chainguard’s stated service-level objectives of seven days for critical CVEs and 14 days for others, and they apply across both popular and long-tail images.
Across our data, one takeaway stands out: modern software is powered by a wide, shifting portfolio of open source components, most of which live outside the top 20 most popular images. That’s not where developers spend their time, but it’s where the bulk of security and compliance risk accumulates.
The report also identifies compliance as a major driver of change in container security. It notes that 44% of its customers run at least one FIPS-compliant image in production, often to satisfy requirements from frameworks such as FedRAMP, DoD IL 5, PCI DSS, SOC 2, the EU Cyber Resilience Act, Australia’s Essential Eight and HIPAA. The most widely used FIPS images mirror the non-FIPS portfolio, with Python, Node, nginx, Go, Redis, Istio components, and cert-manager. Chainguard suggests that this pattern shows how regulatory pressure encourages the use of hardened, cryptographically verified open-source components that closely align with existing workloads.
The idea that risk is concentrated beyond the most familiar projects is not unique to Chainguard’s work. 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 more than two years old. The same research indicated that a small but significant fraction of critical and high-severity vulnerabilities in these containers had known exploits and links to active ransomware campaigns. NetRise’s study also suggests that long-lived, unpatched components in images pose a persistent risk, even when those images aren’t the most widely used.
Academic work has reached similar conclusions using different methods. An analysis of scientific container images published in GigaScience reported a mean of 460 vulnerabilities per image. The authors of this analysis noted that many images included full operating system distributions and additional unnecessary packages that were rarely updated, thereby creating a much larger attack surface. They also showed that carefully reducing image size and contents, and rebuilding them regularly, could significantly reduce vulnerability counts. This reflects the current industry best practice of using minimal base images and rebuilding container images frequently.
Sonatype’s State of the Software Supply Chain report adds another layer by tracking how often vulnerable components are used when patched versions already exist. The 2024 edition highlighted a rise in malicious open-source packages and reported that in 95% of cases where a vulnerable component has been used, a fixed version is already available. Sonatype also highlighted that a large number of dependencies remain unpatched for long periods, particularly for lower-severity issues. This combination of available fixes and slow uptake supports Chainguard’s argument that managed remediation and long-tail coverage can fill a gap left by the realities of open source maintenance.
Industry responses, such as from Checkmarx and Faith Forge, have highlighted some standard patterns. Security vendors describe image scanning as a standard part of continuous integration and deployment processes, with organisations increasingly linking these scans to policy-as-code rules that can block images with unpatched critical CVEs, missing signatures, or missing software bills of materials. In an analysis of the SBOM landscape, the European Union Agency for Cybersecurity (ENISA) also highlights guidance from agencies and regulators. It emphasises the importance of signed artefacts, verifiable build provenance and the ability to match SBOM contents against vulnerability intelligence. These trends all respond to the same structural issue that Chainguard highlights: the need to manage vulnerabilities not just in the most popular images, but across all containerised components used in contemporary software systems.
