The State of Trusted Open Source: New Report Reveals Where Security Risk Really Hides in Modern Software Supply Chains

A comprehensive new analysis called “The State of Trusted Open Source” sheds light on how organizations actually use open source software in production — and where the real security and compliance risks lie. Compiled by Chainguard, a firm focused on secure open source usage and supply-chain hygiene, the quarterly snapshot reveals that modern software ecosystems are far broader and more complex than most engineering teams realize, and that risk tends to accumulate not in the most popular components — but in the long tail of dependencies.

The findings come from an examination of more than 1,800 unique container image projects, 148,000 package versions, 290,000 container images, and almost half a billion builds across the Chainguard user base, coupled with vulnerability data tied to production usage patterns. This massive dataset offers a reality check on assumptions about popularity, risk, compliance, and trust in open source — providing actionable insights for DevSecOps teams, risk managers, and software architects alike.

AI and Open Source: Python Leads the Modern Stack

One of the clearest takeaways from the report is how artificial intelligence (AI) and machine learning are reshaping software stacks. Across every region, Python emerges as the most widely used runtime image in production, being part of over 70% of customer container environments. Python’s dominance reflects its central role in AI model development, data engineering, and inference workloads — from research to production inference services.

Alongside Python, languages and runtimes like Node.js, Go, Redis, and nginx — plus observability and platform tooling such as Grafana, Prometheus, Istio, cert-manager, and Argo CD — form the backbone of typical container portfolios. These foundational building blocks define the most familiar part of the open source stack, yet they represent just a fraction of what ends up running in real environments.

The “Long Tail” Matters More Than You Realize

While top images like Python and nginx are unmistakably critical, Chainguard’s data reveals a striking paradox: the vast majority of security risk resides outside the most popular components.

The report defines the top 20 projects as those most frequently pulled and used in production. Although these represent the components most teams think about and invest effort in securing, they make up only about 1.37% of all available container images.

But when it comes to vulnerabilities, the numbers flip dramatically:

• Only 2% of CVEs remediated by Chainguard occurred in the top 20 images.
• A whopping 98% of vulnerabilities were found in long tail projects — the thousands of less-visible images that collectively power half of production workloads.

This means that while teams might concentrate on high-profile libraries and runtimes, the real security burden accumulates in components they seldom examine or patch proactively. These long tail dependencies tend to be harder to track and secure, resulting in a concentration of risk where teams least expect it.

Why Popularity Doesn’t Map to Risk

This disconnect between popularity and risk exposure is one of the most consequential insights from the report. Developers and security teams naturally focus their attention on the most widely deployed frameworks and images — assuming that this focus will capture the majority of risk. Yet the data tells a different story: the majority of vulnerabilities that get remediated — especially outside the spotlight — exist in those lesser-known parts of the stack.

In practical terms, this means:

• An organization may patch all the common runtimes swiftly, but still be exposed through obscure dependencies quietly woven into their applications.
• Remediation and testing strategies that prioritize only the most popular components may feel comprehensive — but miss the “quiet majority” of risk.
• Attackers targeting less-monitored libraries or container images may find easier entry points because teams do not track or patch those areas as rigorously.

The long tail of software dependencies is not an edge case; it is central to modern open source ecosystems and deserves equal security scrutiny as the core stack.

Compliance Drives Adoption of Trusted Options

Compliance requirements have increasingly shaped how organizations adopt open source. The report highlights that 44% of Chainguard customers run at least one FIPS-compliant image in production. FIPS — the Federal Information Processing Standard used widely in U.S. federal and regulated environments — illustrates how regulatory drivers push teams toward hardened and audited open source alternatives.

Beyond FIPS, compliance frameworks such as PCI DSS, SOC 2, HIPAA, EU Cyber Resilience Act (CRA), FedRAMP, and Essential Eight influence how teams make decisions about what software they deploy and how they secure it. These regulatory frameworks often require strong evidence of vulnerability management, SBOM (Software Bill of Materials) accuracy, and traceability — all of which affect how open source software is evaluated and trusted.

This trend underscores a broader truth: trust in open source is often driven by compliance obligations as much as by engineering judgement. In many production environments, teams adopt hardened or certified images not because they are most convenient, but because they are the safest choice from a regulatory perspective.

Remediation Speed Builds Trust

A key metric for trust — according to the report — is the speed at which vulnerabilities are fixed. Chainguard tracks remediation performance across its catalog and found that:

• Critical CVEs were fixed, on average, in under 20 hours.
• 63.5% of critical issues were resolved within 24 hours.
• 97.6% were remediated within two days, and
• 100% within three days.
• High and Medium risks were resolved in just over two and a half days on average.

This rapid pace of patching — especially outside the top 20 most popular projects — highlights an emerging baseline expectation for trusted open source in enterprise environments. Fast remediation means that teams can react quickly to newly disclosed vulnerabilities, reducing the window of exposure and improving overall supply chain resilience.

A New Baseline for Trust in Open Source

Taken together, these findings point to a fundamental truth: open source trust is not binary — it’s contextual and operational.

It’s not enough to adopt software simply because it is popular; nor can a project be considered secure just because it is widely used. The real challenge is maintaining security and acceleration across the entire supply chain, including lesser-known components used in production.

The “trusted” part of trusted open source depends on:

• Breadth of coverage — ensuring that even long tail images and libraries are monitored, scanned, and patched.
• Velocity of response — minimizing time between vulnerability disclosure and remediation.
• Compliance alignment — integrating regulatory and risk-management requirements into software decisions.
• Visibility and governance — maintaining accurate SBOMs and dependency inventories across containerized and non-containerized workloads.

This comprehensive baseline goes well beyond simple checklist practices and demands continuous investment in open source security tooling and processes.

Implications for DevOps and Security Teams

For DevOps and cybersecurity teams, the State of Trusted Open Source report offers several key lessons:

1. Don’t Ignore the Long Tail

Security policies must explicitly include all dependencies, not just the headline frameworks and images. Ensuring that patching and scanning tools reach deep into the dependency tree is essential to reducing overall risk.

2. Measure and Improve Remediation Time

Organizations should establish metrics for how quickly they can fix vulnerabilities once detected — ideally aligning with or beating industry benchmarks like those shown in the report.

3. Align with Compliance Frameworks

Understanding how frameworks like PCI DSS, HIPAA, CRA, or FIPS influence software choices helps teams make defensible decisions about what they trust in their stacks.

4. Increase Supply Chain Visibility

Maintaining high-fidelity SBOMs, dependency inventories, and risk scoring for every container image in production ensures that the “quiet majority” of risk does not sneak up on teams.

Conclusion: A Wider Lens on Open Source Trust Is Needed

The State of Trusted Open Source report reframes how organizations should think about open source software security and trust. Rather than focusing only on the most popular or visible components, the greatest risk may actually lie in the less obvious parts of the stack — the long tail that powers half of real production workloads.

Understanding this reality — and building tooling, processes, and governance practices that can keep pace — is essential as open source continues to dominate modern software development. With AI reshaping the baseline stack, compliance obligations rising, and the scale of dependencies ballooning, trusted open source is not a one-time certification — it’s a continuous commitment to visibility, speed, and depth of security coverage.