# Chainguard Libraries overview

URL: https://deploy-preview-3420--ornate-narwhal-088216.netlify.app/chainguard/libraries/overview.md
Last Modified: July 23, 2025
Tags: Chainguard Libraries, Overview

Learn about Chainguard Libraries, providing enhanced security for Java, JavaScript, and Python dependencies through automated patching and comprehensive supply chain protection.

Chainguard Libraries provide enhanced security for open source dependencies in the Java, JavaScript, and Python ecosystems, addressing critical supply chain vulnerabilities through automated patching and continuous monitoring. Modern applications rely heavily on libraries from public repositories like Maven Central, npm Registry, and PyPI, but using these repositories introduces supply chain risks that could expose your applications and system to compromise.
Background Open source libraries distributed through public repositories face several security challenges: maintainers may not promptly address vulnerabilities, binary artifacts can be compromised, and the sheer volume of transitive dependencies makes manual security management impractical. While these repositories enable rapid development, they also introduce supply chain risks that traditional security approaches struggle to address.
While convenient, these services remove the direct link from your application to the source code of a specific project, and create a potential risk for quality issues with the artifacts, man-in-the-middle attacks, removal or override of libraries with vulnerable or malicious versions, and other issues. The Supply-chain Levels for Software Artifacts (SLSA) specification describes these risks and how to protect your software against them.
Although this is a common way of accessing open source binaries, it requires you to put tremendous trust into the following aspects for the dozen or even hundreds of open source libraries you typically use for each application:
Maintainers and especially release managers of the projects Local workstation or CI setup used for the release build Release process mechanisms to create the binaries Transport of the binaries from the build system to the public repositories Management of access to the repositories Monitoring of repositories for attacks as well as harmful or malicious binaries Traffic to public repositories and attacks on the transport to your infrastructure There are no real guarantees as to the actual provenance of the software code. Repositories also vary greatly in quality and there is no guarantee that the upstream source of a project is available in a repository. In addition, these repositories also hold non-open source binaries of libraries.
All these factors create uncertainty. Using these public repositories can feel as opaque as picking up a USB drive off of the sidewalk and plugging it into your laptop.
Introduction Chainguard Libraries builds all available libraries from source code in the Chainguard Factory and makes them available for you. The Chainguard Factory is Chainguard’s internal tooling that enables a more secure, dedicated, private, and SLSA-certified build infrastructure for building software from source and publishing the binaries to customers.
Chainguard Libraries and the use of the Chainguard Factory remove many software supply chain problems for libraries:
All binary libraries and library versions are built within the trusted Chainguard infrastructure directly from the source code of the official project. Binaries are handled and managed only by Chainguard and made exclusively available for your consumption. Any supply chain attacks at build and distribution are eliminated, since all steps from the source to your use are handled by Chainguard. If there is no open source code available, no binaries are made available by Chainguard. This eliminates any license-related risks from commercial libraries. The policy and process to have no binaries without source also removes the danger from malicious artifacts, since these artifacts do not provide source code in public code repositories. Chainguard Libraries is available for the following library ecosystems:
Java and the larger Java Virtual Machine (JVM) ecosystem with Chainguard Libraries for Java JavaScript and the larger ecosystem around JavaScript, TypeScript, npm, React, and others with Chainguard Libraries for JavaScript Python and the larger ecosystem with Chainguard Libraries for Python Chainguard criteria for building a library Chainguard Libraries includes thousands of Java, JavaScript, and Python libraries, and coverage is continuously growing as we add more packages and versions over time. Chainguard aims to build libraries that are relevant to our customers and that support broader software supply chain security goals. However, it is not always feasible or safe to rebuild and redistribute every package from public registries such as Maven Central, npm, or PyPI.
Licensing and source availability Chainguard Libraries are rebuilt from upstream source code, not mirrored binaries from public registries. For a library to be in scope:
Source code must be available and verifiable The project’s source must be available in a source code manager (such as GitHub or GitLab). Packages that do not provide a valid or verifiable source URL cannot be rebuilt in the Chainguard Factory and are out of scope. Licensing must allow rebuild and redistribution The project must be licensed in a way that allows Chainguard to rebuild and redistribute it to customers. Library version support Chainguard builds libraries using supported language toolchains in our hardened build environment. We do not aim to replicate all historical runtime environments exactly, but we do attempt to preserve runtime compatibility where it is safe to do so. For older or EOL projects, our ability to build and remediate issues is constrained by runtime compatibility and by upstream maintenance practices.
Our current minimum supported toolchains are:
Python: Python 3.10 and higher. Java: Java 8 and higher. JavaScript: Any supported, non-EOL version of Node.js. We will attempt to rebuild any libraries that meet the licensing and source availability criteria using the supported toolchains.
EOL version support When a library version reaches end of life (EOL) upstream, Chainguard Libraries continues to build packages and provide security fixes for that version for six months beyond the upstream EOL date.
After that six-month window closes, Chainguard Libraries will:
No longer build new packages that require the EOL version No longer provide security fixes for packages built against the EOL version Continue to serve previously built packages Malware and greyware detection Chainguard’s source code and maintainer behavior scanning identifies and blocks malicious and greyware packages in Chainguard Libraries for JavaScript. This includes packages that are publicly reported as malicious (including packages associated with OSV malware IDs) and packages that Chainguard determines are unsafe, even when no public malware advisory exists yet. If a package is flagged as malicious, Chainguard does not build that package from source or serve it through upstream fallback for JavaScript. Python and Java upstream package blocking is coming soon.
The scanner evaluates multiple signal types, including:
Maintainer behavior: Flags anomalies in publisher accounts, release history, and package metadata, checking to see if a maintainer account was recently transferred, if a version was quietly yanked and republished, or if a publish timestamp falls outside any normal window. It also monitors for changes in publishing policy, process, or toolchain as these updates can be an indicator of ownership takeover. Package contents: Downloads and scans the actual package that was published for obfuscated code, embedded C2 domains, modified binaries, and other indicators that something fishy was inserted into the package before it hit the registry. It also triggers on newly added dependencies and significant changes in code or binary size. Publishing signals: Compares the published package against its source code, providing extra protection for all of the packages served via Chainguard’s upstream fallback. It also monitors for items such as a release not being tagged or being signed with an unknown key. Other publish signals include force pushing a tag or a commit hash not being in the event log. Dynamic execution: Runs install scripts in a sandboxed, network-blocked environment to see if there are attempts to call out to an external server, read system files, or execute hidden payloads. Other resources Chainguard Libraries product page Learning Lab for October 2025 on Chainguard Libraries for JavaScript and CVE remediation for Python libraries Learning Lab for June 2025 on Chainguard Libraries for Python Learning Lab for May 2025 about Chainguard Libraries for Java Blog posts
Mitigating Malware in the npm Ecosystem with Chainguard Libraries Announcing Chainguard Libraries for JavaScript: Malware-Resistant Dependencies Built Securely from Source Registries and the npm Breach: Securing the Weakest Link in the Software Supply Chain Malware-Resistant Python without the Guesswork This Shit is Hard: Java Archeology at a Massive Scale Mitigating Malware in the Python Ecosystem with Chainguard Libraries Announcing Chainguard Libraries for Python: Malware-Resistant Dependencies Built Securely from Source Announcing Chainguard Libraries: Guarded Java Language Dependencies Built from Source