Libraries without the
hidden malware risk

A malware-resistant library is a software dependency rebuilt from verified source code in a tamper-proof, secure build environment. Chainguard Libraries, for example, proactively blocks malware and supply chain threats before they enter your environment because only packages with verified, buildable source are included—malicious or tampered binaries never make it through. Libraries built this way can reduce malware by 98% compared to packages downloaded from a public registry. We build Chainguard Libraries in SLSA Level 2 infrastructure, providing full provenance and Software Bills of Materials (SBOMs), to mitigate supply chain attacks at the build and distribution stages where attackers typically inject malware.

Chainguard significantly reduces supply chain attack risk by rebuilding every library from verified source code in tamper-proof environment, preventing malicious code injection at the build and distribution stages. In testing against 3,025 known malicious Python packages from the Backstabber's Knife Collection, Chainguard's rebuilt-from-source approach successfully prevented 98% of these compromised packages from reaching users.

Attackers often compromise the build systems where packages are compiled (injecting malicious code before publication, like the XZ-Utils backdoor) or hijack distribution by stealing developer credentials to upload malicious versions to registries like npm, PyPI, or Maven Central. Because trust is often assumed but never verified from public registries, these attacks spread rapidly through automated dependency updates before they are detected.

"Built from source" means Chainguard rebuilds every library from its original source code repository rather than downloading pre-compiled artifacts from public registries. This creates a trusted, verifiable chain of custody and eliminates the risk of consuming packages that were tampered with during the build or upload. Every library comes with with full provenance proving exactly how, when, and where it was built.

Chainguard Libraries currently supports JavaScript (npm), Java (Maven), and Python (PyPI), covering hundreds of thousands of versions of the popular libraries in each ecosystem. Additional language ecosystems are being considered based on customer demand.

Chainguard Libraries integrates with common artifact managers such as JFrog Artifactory, Sonatype Nexus Repository, and Cloudsmith. Once configured as an upstream source, developers pull trusted dependencies through your existing tools automatically, with no change to your workflows.

Every Chainguard Library ships with Sigstore signatures (cryptographic proof of authenticity), a signed SBOM (complete inventory of components), and SLSA Level 2 provenance (attestation documenting how and where it was built). These attestations let you verify the origin and integrity of every package, ensuring no tampering occurred between source code and deployment.

No. Libraries appear as just another upstream repository (just like PyPI, npm, Maven Central, NuGet), so developers can use Chainguard Libraries without any operational change. That means your builds and environments work as the same as before—just with signed, verified packages. No new tooling required.

Chainguard backports upstream fixes for critical and high-severity CVEs in popular and highly request Python libraries. This allows you to stay protected while you plan your next version upgrade, eliminating the pressure to immediately migrate to the latest version just to address security issues.

Yes. Chainguard Libraries can be used standalone in any environment (developer machines, CI/CD pipelines, or production) where your code is developed and deployed. However, combining Libraries with Chainguard Containers or VMs provides complete protection across your entire stack, from OS to application dependencies.

FIPS is offered with Chainguard Containers (and related hardened variants), not as a feature of Chainguard Libraries. Use Libraries for the secure dependencies and pair them with FIPS containers/VMs when FIPS-validated cryptography is required.

SLSA (Supply-chain Levels for Software Artifacts) Level 2 is an industry-standard framework that requires builds to be performed on hardened infrastructure with automated provenance generation. This ensures packages are built in a tamper-resistant, auditable environment. For libraries, this means you get cryptographic proof that each package was built from verified source code without compromise, preventing supply chain attacks at the build and distribution stages where attackers often inject malicious code.