The State of Trusted Open Source Report: Key Findings for 2025

Chainguard has published the findings of its first-ever State of Trusted Open Source report, drawing on product telemetry and customer data to provide an unprecedented view into how organizations actually consume open source software. The report covers consumption patterns across container image projects, software versions, language libraries, and build artifacts — and exposes where the industry is systemically taking on supply chain risk without knowing it.

Why This Report Matters

Open source supply chain attacks have become one of the defining security threats of the mid-2020s. From the xz-utils backdoor (2024) to the repeated PyPI and npm package poisoning campaigns attributed to nation-state groups, the compromise of trusted open source components has cascading effects across every organization that depends on them.

Despite this, most organizations have limited visibility into what open source they are actually running, which versions, and whether those versions are maintained or vulnerable. The Chainguard report is among the first to provide data-driven benchmarks for these questions at scale.

Key Findings

1. Version Lag Is a Systemic Problem

A significant portion of observed container images and language library deployments are running out-of-date versions — often by months or years. Even within organizations with active security programs, version drift is common in:

• Base container images (OS layers, runtime environments)
• Indirect/transitive dependencies pulled in by language package managers
• Language runtime versions (Python, Node.js, Go, Java) inside containers

Version lag means vulnerabilities disclosed against older versions remain present in production long after patches are available.

2. Rebuild and Provenance Hygiene Is Rare

The report found that most open source artifacts in production cannot be traced to a verified build process. Key gaps include:

PROVENANCE GAPS IDENTIFIED:
- Majority of consumed packages lack SLSA attestations
- Most container images are pulled from registries without
  verified build provenance
- Supply chain integrity controls (Sigstore, in-toto) present
  in less than a minority of observed environments
- SBOMs (Software Bills of Materials) are generated for some
  images but rarely consumed or acted upon downstream

Without provenance, organizations cannot verify that the artifact they downloaded matches what was built from the original source — creating an undetected window for supply chain tampering.

3. Widely Used Images Have Long Vulnerability Tails

For popular container base images (OS distros, language runtimes, web servers), the report documents a pattern where:

• CVEs accumulate over time in images that are not regularly rebuilt
• Images tagged latest or with major version tags (e.g., python:3) may silently trail current security patches
• Organizations using pinned digests for reproducibility may be locking in vulnerable versions without realizing it

The data shows that regularly rebuilt, minimal images (such as distroless or Chainguard's own hardened images) dramatically reduce the CVE surface area compared to traditional distribution-based images.

4. Language Libraries Show Concentrated Risk

Across the surveyed language ecosystems (Python/pip, JavaScript/npm, Java/Maven, Go modules), the report identifies:

CONCENTRATION RISK:
- A small number of high-popularity packages account for a
  disproportionate share of transitive dependency pulls
- These "keystone" packages — if compromised — would affect
  the vast majority of observed environments
- Recent high-profile attacks (Axios npm breach, LiteLLM PyPI
  compromise) confirm active attacker interest in these packages
- Version pinning practices vary widely; many applications
  use loose version specifiers that allow automatic updates
  to potentially malicious releases

5. Patch Adoption Is Slow After Disclosure

For vulnerability disclosures affecting widely used packages, the report tracks patch adoption rates:

• Median time to update a vulnerable dependency after a high-severity CVE disclosure: several weeks to months
• Critical infrastructure and financial services organizations show faster patch adoption but still lag
• Transitive dependencies (vulnerabilities in packages depended on by the direct dependency, not by the application itself) see even slower remediation

Recommendations from the Report

For Security Teams

1. Adopt an SBOM-first approach — generate SBOMs for all production artifacts and consume them in your vulnerability management pipeline
2. Implement continuous container image scanning — point-in-time scans at build time miss vulnerabilities disclosed after the image was built
3. Use minimal, regularly rebuilt base images — prefer distroless or hardened base images that are rebuilt nightly against current package versions
4. Apply version pinning with hash verification — pin to specific digests, not tags, and verify hash integrity in CI/CD pipelines

For Platform and DevOps Teams

PRACTICAL STEPS:
- Integrate Grype, Trivy, or Snyk into your CI/CD pipeline
  for automated vulnerability scanning on every build
- Enable Cosign signature verification for container pulls
  from registries that support it
- Use Dependabot or Renovate to automate dependency updates
  with configurable risk thresholds
- Require SLSA Level 2+ for critical internal packages
  and prefer SLSA-attested external packages

For Procurement and Vendor Risk

• Require SBOMs from software vendors as part of procurement
• Include supply chain security requirements in vendor contracts
• Audit vendor container images and libraries against CVE databases before deployment

Context: The Supply Chain Security Imperative

The findings come at a time of heightened regulatory pressure on software supply chain security:

The Chainguard report's findings align with the intent behind these frameworks: organizations need systematic, continuous visibility into their open source consumption, not periodic manual audits.

Bottom Line

The State of Trusted Open Source report delivers a data-backed reality check: most organizations are running open source they cannot fully account for, at versions they have not verified, from builds whose provenance they cannot trace. As supply chain attacks become more frequent and more sophisticated, the gap between assumed and actual software trustworthiness represents a material and growing risk.

Source: The Hacker News — April 2, 2026 · Chainguard State of Trusted Open Source Report