Integrations/Chainguard Libraries

Smarter security with Chainguard Libraries and Cloudsmith.

Made to eliminate supply chain attacks at package build and distribution. Chainguard Libraries is a curated set of high-assurance, open-source packages built entirely from source in a hardened environment. Each package has SLSA Level 2 provenance and is minimal, verifiable, and production-ready. There’s no repackaging and no guesswork. You get secure, reproducible builds with full traceability. These libraries are continuously updated so your dependencies stay current and tamper-resistant.

How we support Chainguard Libraries

Cloudsmith gives your teams a single, governed distribution layer for Chainguard Libraries across Java, Python, and JavaScript. Combine verified, source-built packages with Cloudsmith's upstream proxying, policy enforcement, and global CDN to keep your software supply chain secure and your builds fast.
    Upstream proxying for Chainguard Libraries
    Configure Cloudsmith as your upstream proxy for Chainguard Libraries across Python, Java, and JavaScript. Developers pull from a single Cloudsmith endpoint - Chainguard content is served first, with a governed fallback to public registries like PyPI, Maven Central, or npm for packages not yet in the Chainguard index.
    SLSA provenance and SBOM traceability
    Every package served through Cloudsmith from Chainguard carries full SLSA Level 3 provenance, Sigstore signatures, and signed SBOMs. Cloudsmith logs every pull request, giving you an audit trail that ties each build artefact back to verified source with no gaps.
    Global, high-availability distribution
    Chainguard Libraries cached in Cloudsmith are distributed across 600+ edge PoPs. Teams in any region get low-latency, highly available access to verified packages without reaching out directly to Chainguard on every build - protecting you from upstream outages and rate limits.
    Policy-as-code governance across ecosystems
    Use Cloudsmith's OPA Rego-based policy engine to control which Chainguard Libraries versions are promotable, who can access them, and what happens when a fallback to a public registry is triggered. Apply quarantine or cooldown periods to any package sourced outside the Chainguard index.
    Full consumption visibility and audit logs
    Cloudsmith gives you detailed per-package consumption metrics for all Chainguard Libraries requests, including version in use, download frequency, and team access patterns. Client and audit logs feed directly into your observability stack, so you know exactly what your builds are pulling and from where.

Why teams integrate Cloudsmith with Chainguard Libraries

Pulling directly from Chainguard without an artifact management layer leaves teams exposed to fragmented access controls, no fallback strategy, and zero visibility into what was actually consumed. Cloudsmith closes those gaps.
Without CloudsmithTeams configure Chainguard credentials separately on every developer workstation and CI server. When credentials rotate or a new engineer joins, each environment has to be updated manually - a fragile process that slows onboarding and creates gaps.
With CloudsmithChainguard credentials are configured once in Cloudsmith. All developer tools and CI pipelines point to a single Cloudsmith endpoint. Credential rotation happens centrally, with no changes required across individual machines or pipelines.
Without CloudsmithWhen a package is not yet in the Chainguard index, builds fail. Teams are forced to choose between blocking work and falling back directly to PyPI, Maven Central, or npm with no governance, no quarantine, and no audit trail on what enters the build.
With CloudsmithCloudsmith manages a prioritised dual-upstream: Chainguard Libraries first, public registry as a governed fallback. Packages from public registries are subject to Cloudsmith's policy engine, quarantine controls, and security scanning - so no unverified artefact enters undetected.
Without CloudsmithThere is no centralised record of which Chainguard Library versions were pulled into which build, on which date, by which team. When a vulnerability is disclosed or an audit is requested, reconstructing that picture is manual and incomplete.
With CloudsmithEvery package request through Cloudsmith is logged with full context: package name, version, requesting team, timestamp, and upstream source. SLSA provenance and signed SBOMs are preserved in context, giving compliance and security teams the evidence they need without manual reconstruction.

Frequently asked questions

  1. Cloudsmith supports upstream proxying for Chainguard Libraries across Java (Maven/Gradle), Python (PyPI/pip/uv), and JavaScript (npm). Each ecosystem can be configured as a separate upstream source within a Cloudsmith repository, with priority ordering relative to public registry fallbacks.

  2. You configure two upstream sources in your Cloudsmith repository: Chainguard Libraries at priority 1, and the public registry (PyPI, Maven Central, or npm) at priority 2. Cloudsmith resolves package requests against Chainguard first. If a package is not yet in the Chainguard index, the request falls back to the public registry. Packages from the public registry can be subject to quarantine periods and policy rules you define, so fallback traffic is governed rather than open.

  3. No. Once Cloudsmith is configured as the upstream endpoint for a given ecosystem, developers and CI systems continue using their existing tools: pip, Maven, Gradle, npm, pnpm, Yarn, and so on. Chainguard Libraries appear as a standard upstream repository, so workflows stay identical. The only change is where the packages come from.

  4. This is the most common migration issue. Build systems cache previously downloaded packages, and those caches will reuse old artefacts even after you reconfigure your upstream. Before switching, clear local caches across developer machines and CI environments, and update cache keys in tools like GitHub Actions to force a cache miss. Cloudsmith's audit logs show you exactly what is being served from cache versus fetched fresh, helping you validate a clean migration.

  5. Every Chainguard Library package carries Sigstore signatures, a signed SBOM, and SLSA Level 3 provenance. When served through Cloudsmith, all package metadata and attestation data is preserved. Cloudsmith's audit logs record the pull event with a full timestamp, requesting identity, and package version, giving you an end-to-end chain of custody from Chainguard's build factory to your build environment.

  6. Yes. Cloudsmith's policy engine, powered by OPA Rego, lets you define rules that apply to any package entering your repository, regardless of upstream source. For public registry fallback traffic, you can enforce quarantine or cooldown periods, restrict package versions, and block flagged packages - so packages sourced outside the Chainguard index are still subject to governance before reaching developers.

  7. If you configure a Chainguard-only upstream with no fallback, a build will fail on missing packages until Chainguard adds coverage. If you configure a fallback to a public registry, the request is served from the public registry under whatever governance rules you have set in Cloudsmith. Chainguard logs missing package requests and prioritises them for future builds. For JavaScript, Chainguard's built-in npm fallback handles this more safely than a direct public registry fallback.

  8. Once a package is pulled from Chainguard and cached in Cloudsmith, it is distributed across Cloudsmith's 600+ global edge PoPs. Subsequent requests from any region are served from the nearest edge location, not from Chainguard directly. This means your teams in APAC, EMEA, or the Americas all get low-latency access without hammering the Chainguard origin on every build.

  9. Yes. Cloudsmith's repository-level access controls, token-based authentication, and RBAC let you define exactly which teams or service accounts can pull from a given repository containing Chainguard Libraries upstreams. You can create separate repositories per team or project, each with its own access policy, so that access to verified packages is governed just like any other artefact in your platform.

  10. Yes. The combination is particularly well suited to regulated environments. Chainguard provides SLSA Level 3 provenance, signed SBOMs, and malware-resistant builds. Cloudsmith adds centralised audit logging, policy-as-code enforcement, SAML/SSO integration, and custom storage regions for data residency requirements. Together, they give compliance and security teams the evidence and controls needed to satisfy SOC 2, FedRAMP, and similar frameworks.

Integrations

Discover more Cloudsmith Integrations