AI Docs Bundle
Join Our Community Slack Contact
Chainguard Libraries

Chainguard Libraries FAQ

Frequently asked questions about Chainguard Libraries, including security benefits, supported ecosystems, and how automated patching protects against supply chain attacks
  7 min read
Chainguard Libraries Overview

What security issues can Chainguard Libraries prevent?

As detailed on the background and introduction pages, Chainguard Libraries are built directly from source in the Chainguard Factory and the resulting binaries are directly provided to you by Chainguard. Chainguard operates the whole supply chain for the package lifecycle as one reliable, secure partner. You can therefore avoid issues from the following software supply chain attack surface points:

  • Build pipeline
  • Build system
  • Dependency injection
  • Bypass of CI/CD systems
  • Library distribution
  • Library consumption

More information about these stages in the software supply chain is available on the Supply chain Levels for Software Artifacts (SLSA) website.

The following examples are issues, attacks, and compromises that affect stages of the software supply chain for libraries across different language ecosystems:

Malicious GlueStack packages
  • This May 2025 attack uploaded compromised packages to PyPI and npm that enable remote shell access and uploading files to compromised machines
  • Chainguard Libraries would have protected against this attack. First, the packages have invalid upstream source URLs so there was no source repository. In the case of the lone exception (a package with a valid source repository link), no code was present for Chainguard to build a valid package.
Ultralytics Python project
  • Attackers compromised the GitHub Actions workflows for the Ultralytics repository, injecting malware into PyPI package releases.
  • Attackers pushed out four malicious versions of the Ultralytics YOLO project over the course of a week (8.3.41, 8.3.42, 8.3.45, 8.3.46).
  • Ultralytics YOLO is a widely-used fast object detection neural network library downloaded about five million times per month. Users affected during this period were infected with cryptomining malware.
  • Chainguard Libraries would have prevented this attack by building the project from clean source. No source code was modified by attackers during this incident.
  • See also PyPI attack analysis and bleepingcomputer blog post.
Lottie Player
  • Hackers gained access to the NPM registry by compromising a developer authentication token.
  • Token used to upload a compromised version of Lottie Player.
  • The malicious package drained crypto wallet funds.
  • Chainguard Libraries would have prevented this attack by building the project from clean source. No source code was modified by attackers during this incident.
  • See also npm package Lottie-Player compromised in supply chain attack, Nov 2024.
MavenGate
  • MavenGate is a proof of concept for exploiting abandoned Java library domains.
  • Vulnerabilities in Maven dependency management allow unauthorized package replacements.
  • All Java build tools using Maven repositories, including Maven, Gradle, and Ant, could be affected.
  • MavenGate relied on the use of multiple repositories and any attack with the proposed mechanism would not publish source code. Chainguard Libraries replace other repositories and the use of Chainguard Libraries, based on building from the original source, would have prevented an attack using this approach
  • See also The Hacker News article, Oversecured blog post, and Sonatype’s take as Maven Central operator.
XZ Utils backdoor
  • Example of a supply chain attack leveraging social engineering by a patient actor
  • Sophisticated backdoor that had remote code execution capability and the potential to affect many systems
  • Vulnerability was patched within hours of disclosure by reverting to a previous version known to be safe.
  • Malicious source tarball and binaries were distributed successfully, but source code repository was not compromised.
  • Since no source code was compromised, a similar attack on a protected library ecosystem would be prevented by Chainguard Libraries
  • XZ Utils is written in C and therefore not available as an ecosystem protected by Chainguard Libraries. However, Chainguard Containers include XZ Utils packages. These are also built from source and are not affected.
  • See also Wikipedia article and official page from the XZ data compression.
Other examples and resources

The following links provide details for other software supply chain attacks. Depending on the exact details some of these attacks and approaches are prevented by use of Chainguard Libraries.

Find pointers to further resources in the Software supply chain reading list.

Why do the Chainguard library checksums differ from those published by upstream repositories?

Chainguard rebuilds libraries from source in a controlled environment to improve supply-chain security. As a result, while functionality remains the same, build metadata and generated content, such as SBOMs, differs from upstream distributions. Whether Chainguard library checksums match upstream depends on the ecosystem and build process.

During initial migration to Chainguard Libraries, some common causes of checksum errors include:

  • Artifacts were previously cached from upstream repositories
    • Example: Maven’s .m2 or Gradle’s cache.
  • Dependencies are pinned to upstream checksums or hashes
    • Example: JavaScript’s package-lock.json or yarn.lock.
  • Repository managers or build tools enforce strict verification
    • Example: Artifactory validating against Maven Central.

Does Chainguard Libraries for Java include CVE remediation fixes?

Short answer:

No. Libraries are built from source code in the secured and hardened Chainguard infrastructure. This eliminates any build and distribution stage vulnerabilities.

More details:

Chainguard cannot patch Java libraries and create binaries with the same identifier because the complete behavior and API surface of every library affects the use. That use however is part of the application development of each customer. It varies widely and any change potentially creates incompatibilities, different behavior or even new security issues.

Chainguard collaborates with many upstream projects and can collaborate with customers to increase and accelerate the creation and adoption of fixes and the work towards new releases.

Importantly, over 95% of all known vulnerable components have a fixed version available and, by adopting those newer versions in your application, you can remediate most CVEs. Chainguard Libraries for Java includes those newest versions and adds the build and distribution channel security.

What’s the difference between malware‑hardened libraries and CVE remediation?

Malware‑hardened libraries are the baseline Chainguard Libraries experience: Chainguard rebuilds open source Java, JavaScript, and Python dependencies from upstream source in the Chainguard Factory, a controlled, SLSA‑aligned build environment, and publishes them to hardened registries for customers to consume. This closes off most supply chain malware vectors compared to pulling directly from public registries like Maven Central, npm, and PyPI.

CVE remediation is an additional feature (currently focused on a subset of Python libraries) where Chainguard backports High and Critical vulnerability fixes from newer upstream releases to older versions that customers are still using, particularly when upstream maintainers no longer ship patches for those older versions. Remediated versions are:

  • Published in a separate Python index (e.g., https://libraries.cgr.dev/python-remediated/simple/).
  • Given a local version suffix like +cgr.N (for example, 2.0.0+cgr.1) so dependency resolvers can distinguish them from non‑remediated upstream versions while still preferring the remediated build during resolution.

Why might I still see 404s with fallback enabled for Chainguard Libraries for JavaScript?

For JavaScript, Chainguard offers the Chainguard Repository as a unified, managed endpoint at https://libraries.cgr.dev/javascript/. This single endpoint:

  • Serves Chainguard‑built packages first, rebuilt from source.
  • Optionally falls back to upstream npm for packages or versions that are not yet available from Chainguard.
  • Applies security controls on the upstream fallback, including a cooldown window and malware detection that blocks packages associated with known malware IDs from public OSV feeds.

Because of those controls, you can still see 404s or failed fetches even when fallback is enabled, for example when:

  • A package or version is blocked by malware detection and therefore intentionally not served from upstream.
  • A recently published version is still in the cooldown period, so the repository will not yet proxy it from npm.
  • The requested package/version truly does not exist in either Chainguard’s catalog or upstream.

Fallback respects security policies first, then mirrors safe content from npm. For customers, this can surface as a 404 from the Chainguard endpoint even though a version appears in the public registry.

What are Chibbies?

Chibbies is the internal codename for the Chainguard Libraries. It evolved from Chainguard Libraries being shortened to Chainguard Libbies, and then finally to Chibbies.

Related Articles

Chainguard Libraries overview

Learn about Chainguard Libraries, providing enhanced security for Java, JavaScript, and Python dependencies through …

  4 min read

Last updated: 2025-07-23 15:09

Browsing Chainguard Libraries Prev   How does Chainguard Libraries plug into a developer's workflow?   Next