Vulnerability scanners and Chainguard Libraries
Details for using vulnerability scanners with Chainguard Libraries.
For the complete documentation index, see llms.txt.
Most supply chain attacks succeed the same way: malicious code is injected into a package after the source is written — either as a backdoored binary with no verifiable source, or as a malicious install-time script that runs the moment a dependency is pulled. Recent attacks on LiteLLM, Telnyx, and Axios all followed this pattern.
Chainguard Libraries are rebuilt from verified source in an isolated build environment, making them malware-resistant by design. When a package is available as a Chainguard-built library, that rebuilt package is served first. When you use the upstream fallback, the same ecosystem endpoint can also serve eligible upstream packages that Chainguard has not yet built, subject to configurable policy controls such as cooldown and malware scanning.
This gives your engineers drop-in replacements for the packages they already use, with no breaking changes.
This guide covers the high-level steps to get up and running. For full reference documentation on any step, follow the links provided.
Before getting started:
If you’re not yet a Chainguard user, you must create an account.
Install chainctl and
log in:
chainctl auth loginEntitle access for yourself to Chainguard Libraries.
chainctl libraries entitlements create --ecosystems=JAVASCRIPTThe available ecosystems are JAVASCRIPT, JAVA, and PYTHON.
Alternatively, you can create an entitlement and pull token in the Chainguard Console: while viewing a library ecosystem page, follow the prompts to create an access token.
There are two ways to access Chainguard Libraries: using an artifact manager or direct access.
Configure credentials once in a tool like JFrog Artifactory, Sonatype Nexus, or Cloudsmith. This centralizes policy, logging, and fallback behavior, and is the safest approach for organizations with multiple teams and applications.
If you configure upstream fallback, the same ecosystem endpoint can serve both:
Upstream packages served through the Chainguard Repository are subject to configurable policy controls such as cooldown and malware protection. It is strongly recommended that you follow this approach.
Alternatively, you can configure your repository manager to fallback to the upstream public repositories for packages not available from Chainguard Libraries, as described in the global configuration docs for each ecosystem. Packages sourced from public registries are not covered by Chainguard’s malware-resistance guarantees. If you choose this option, we strongly recommend configuring a quarantine or cooldown period on your fallback repository so that newly published or updated packages are not immediately available to developers. Chainguard has no control over malware protection for packages sourced from public registries.
Configure authentication directly in each project’s build configuration.
This option is faster to set up initially, but requires per-project and per-workstation configuration. This increases the risk of credentials being committed to source control or going stale.
Learn how to set up direct access in the build configuration documentation for Python, JavaScript, and Java.
Pull tokens
are required for authentication. You can create one using chainctl:
chainctl auth pull-token --repository=java --ttl=720hchainctl auth pull-token --repository=python --ttl=720hchainctl auth pull-token --repository=javascript --ttl=720hThe default TTL is
720h(30 days); the maximum is8760h(365 days).
The command returns a username and password for basic authentication. Store these securely, as they won’t be shown again.
You can also create pull tokens via the Chainguard Console under Overview > Manage pull tokens > Create access token.
Learn more about pull tokens, and using environment variables for pull token credentials, in the Libraries Access documentation.
Once you have a pull token, you can configure your build tool. Configuration steps vary by build tool and ecosystem. See the ecosystem-specific documentation pages for instructions.
If you configure upstream fallback, the same endpoint can serve both Chainguard-built artifacts and upstream arfifacts through the Chainguard Repository.
https://libraries.cgr.dev/java/ as the first repository for artifact
resolution.https://libraries.cgr.dev/java/. Use direct access for
small teams or evaluations, or when you have an existing repository
configuration you can’t change yet.In addition to malware-resistance, Chainguard Libraries for Java includes CVE remediation for select libraries. These patched versions help reduce known risk while you plan your next major version upgrade. You can view which libraries have CVE remediation available in the Chainguard Console.
Check out minimal example projects for Maven and Gradle to understand how to use these repositories.
Note that there are multiple repositories:
https://libraries.cgr.dev/python/ with the simple index at
https://libraries.cgr.dev/python/simplehttps://libraries.cgr.dev/python-remediated with the simple index at
https://libraries.cgr.dev/python-remediated/simple for libraries with CVE
remediationIn addition to malware-resistance, Chainguard Libraries for Python includes CVE remediation for select libraries. These patched versions help reduce known risk while you plan your next major version upgrade. You can view which libraries have CVE remediation available in the Chainguard Console.
Check out minimal example projects for uv and pip to understand how to use these repositories.
Migrating an existing Python project? If you have an existing lockfile with upstream hashes, use
chainctl libraries update-hashesto update checksums to Chainguard’s automatically, without regenerating your lockfile from scratch.
.npmrc to use https://libraries.cgr.dev/javascript/ as the registry.Note on upstream fallback for JavaScript: The npm upstream fallback is available as an opt-in setting for both repository manager or direct access approaches, and is turned off by default. Upstream packages are proxied directly from npm and are not rebuilt or authored by Chainguard as part of our Libraries product. The cooldown period and malware scanning provide a supplemental baseline of protection to your own security practices, but you are solely responsible for independently evaluating and validating all upstream artifacts before use in your environment.
Learn more about upstream fallback policy and controls in the Libraries overview.
Check out minimal example projects for npm, pnpm, Yarn, Yarn Classic, and Bun to understand how to use these repositories.
Migrating an existing Python or JavaScript project? If you have an existing lockfile with upstream hashes, use
chainctl libraries update-hashesto update checksums to Chainguard’s automatically, without regenerating your lockfile from scratch. The command authenticates to Chainguard Libraries; see the authentication options in the Python and JavaScript build configuration guides. Migrating an existing JavaScript project? If you have an existing lockfile with upstream hashes, usechainctl libraries update-hashesto update checksums to Chainguard’s automatically, without regenerating your lockfile from scratch. See the JavaScript migration guide for instructions.
Note on upstream fallback: The upstream fallback is available as an opt-in setting for both repository manager or direct access approaches, and is turned off by default. Learn more about upstream fallback policy and controls in the Libraries overview.
After setup, you can verify which dependencies were built from source by Chainguard:
chainctl libraries verify /path/to/artifactLearn more in Chainguard Libraries verification.
See the Chainguard Libraries FAQ page for common questions and issues.
Last updated: 2025-03-25 00:08