Chainguard Libraries vs Safeguard Gold and Package Firewall: Rebuilt Java, Python and JavaScript Dependencies Compared

Every team that depends on npm, PyPI or Maven Central is trusting a long chain of maintainers, release machines and registries. Chainguard Libraries and Safeguard both shorten that chain, in different ways. As of 28 Oct 2026, Chainguard Libraries rebuilds supported Java, JavaScript and Python dependencies from verified source in its own build infrastructure and, by default, serves only those rebuilt packages from its repository, with optional controls for anything else. Safeguard's side, in its canonical form: Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. Everything not in Gold passes through unchanged, and the Package Firewall evaluates npm and pip installs and blocks malicious, typosquatted and dependency confusion packages before they land. One approach replaces the supply by default. The other fixes what is vulnerable and guards the door. This guide compares them fairly, says where Chainguard is clearly ahead, and ends with a bake-off you can run on your own repositories.

Chainguard facts come from its documentation, product and pricing pages, CVE policy and one press report, each linked and accessed on 28 Oct 2026. Safeguard facts come from its registry page, documentation, launch post and pricing page. Where a vendor page is silent or inconsistent, the post says so. For the container image side (Chainguard Images and Wolfi against Safeguard Gold), see the sibling guide, Chainguard Images and Wolfi vs Safeguard Gold.

Key takeaways

• Different defaults. Chainguard's docs say its library endpoints serve only Chainguard built packages by default, with upstream fallback an option you switch on. Safeguard's registry page says anything not in Gold passes through unchanged from the public source, with Package Firewall as the install time control.
• Chainguard has the more developed rebuilt library catalog. Its overview says it has "thousands" of Java, JavaScript and Python libraries, with malware and greyware scanning, cooldowns, CVE backports for a subset, and a verification command. Safeguard's registry page lists many ecosystems but no coverage counts.
• No source, no binary. Chainguard builds only where verifiable source exists and the licence allows redistribution. That is a strong rule against packages with no source, and it also means some artifacts are simply absent, for example closed source Java libraries and JDBC drivers.
• Rebuilds change checksums. Chainguard's FAQ says checksums can differ from upstream, which affects lockfiles and repository managers that pin upstream hashes. Plan for it.
• Both do backports, with different scope. Chainguard publishes remediated versions (+cgr.N, -0.cgr.N, -cgr.N) for a subset of libraries, Java in beta. Safeguard's Gold Live tier describes backports to older lines.
• They answer the malware question differently. Chainguard scans source and maintainer behavior and applies a cooldown to upstream fallback. Safeguard's Package Firewall evaluates installs for npm and pip.
• The two can sit side by side. Chainguard's endpoint can feed a repository manager. Safeguard scans and gates what comes out of it and fixes your own code and dependencies.

Scope: libraries, not containers

Chainguard sells four products as of 28 Oct 2026: Containers, Libraries, VMs and Actions (pricing). This post is about Chainguard Libraries, its catalog of rebuilt language dependencies at libraries.cgr.dev, against the parts of Safeguard that serve and guard the same packages: Gold Registry for fixed builds, Package Firewall for install time decisions, and the platform's fix pull requests. The ecosystems compared are the three Chainguard lists as available: Java (Maven and Gradle), JavaScript (npm, pnpm and Yarn) and Python (pip, uv and Poetry).

What Chainguard Libraries is (as of 28 Oct 2026)

The model

Chainguard's overview describes Libraries as "a secure catalog of language dependencies that replaces your team's reliance on npm, PyPI, and Maven Central". Every package pulled by your team or AI agents, it says, passes through layers of defense: malicious behavior scanning, building from source, and cooldowns (overview). The core mechanism is that Chainguard rebuilds supported dependencies from verified upstream source in the Chainguard Factory, its build infrastructure that the docs describe as a hardened, SLSA certified environment, and distributes the artifacts with provenance and SBOMs. The FAQ explains why that matters: public registries remove the direct link between the code you run and the source of a specific project, so the binary on the registry may not correspond to the code in the repository. Rebuilding restores that link.

Consumption is through the Chainguard Repository. You authenticate with a pull token created through chainctl, and most organizations configure a repository manager (the docs name JFrog Artifactory, Sonatype Nexus Repository and Cloudsmith) with the Chainguard endpoint as the first upstream, so developers' build tools do not change. The docs say the Python and Java endpoints use the standard PyPI and Maven repository formats, and the JavaScript endpoint speaks the npm protocol. The URLs are libraries.cgr.dev/python/, /java/ and /javascript/.

Which ecosystems

The overview page lists Java, JavaScript and Python as available. The documentation also has Go and .NET sections, and both are labeled in beta, with enablement through your account team (Go, .NET). Chainguard's pricing page feature table says "Currently Python only" for Libraries, while its Libraries product page FAQ says it supports Java, Python and JavaScript. The pages do not reconcile this. The docs are the more detailed source, and you should still ask your account team which ecosystems and which remediation features your order includes.

What gets built, and what does not

Chainguard states its criteria. Source code must be available and verifiable in a source code manager, and the licence must allow Chainguard to rebuild and redistribute. Packages without a valid source URL are out of scope, and the docs say that "if there is no open source code available, no binaries are made available by Chainguard", which also removes licensing risk from commercial libraries. Minimum toolchains are Python 3.10 or higher, Java 8 or higher and any supported non end of life Node.js. For libraries whose runtime reaches end of life upstream, Chainguard continues to build and fix for six months beyond the upstream end of life date, then stops building new packages that need it while continuing to serve what it built.

Coverage is described as "thousands" of libraries and growing, and "not exhaustive". For Java, the docs say the repository includes only release artifacts that Chainguard built from source, excludes snapshots, and does not include closed source libraries such as JDBC drivers for proprietary databases. A request for a missing library or version triggers a process to provision it where sources allow. The docs tell you to configure Chainguard as the first point of contact and keep Maven Central, or another repository, available for what Chainguard does not carry (Java overview). Python adds CUDA specific indexes for GPU wheels, such as cu128 for torch built against CUDA 12.8 (Python overview).

Upstream fallback, cooldown and build pinning

By default the Chainguard library endpoints serve only Chainguard built packages. You can enable a protected upstream fallback per ecosystem. Upstream packages then pass malware scanning and a cooldown before they are served. The cooldown defaults to 7 days, can be set from 1 to 30 days or disabled with 0, and applies to Chainguard built and fallback packages alike so dependency trees resolve consistently. Malware and greyware scanning still applies when the cooldown is off. A version inside the cooldown window is withheld from metadata, and npm gets a 403 with a reason. Build pinning keeps a package version you pulled from upstream stable even after Chainguard later publishes its own build of that version. The docs also say plainly that the Chainguard Repository "is not a full mirror" of upstream.

Malware controls

Chainguard's docs describe scanning that blocks malicious and greyware packages. It covers packages reported as malicious, including those with OSV malware identifiers (the OSV database includes the OpenSSF Malicious Packages feed), and packages Chainguard itself judges unsafe through source code and maintainer behavior scanning, even when no public advisory exists yet. Signals include credential and data theft, backdoors and obfuscated payloads, install time script execution, typosquatting and impersonation, and compromised or untrusted releases. Detection is continuous, so a previously cached version later found malicious is added to a block list, and there is a malware blocklist API for querying what Chainguard blocked.

The Libraries product page adds vendor claims worth reading as claims: that in testing against 3,025 known malicious Python packages Chainguard "successfully prevented 98%" of them from reaching users, and that its libraries "are safe from the malware compromises that have made headlines over the last few months", naming several incidents. The page gives no independent methodology beyond that single Python benchmark, so treat the figures as a reason to run your own test.

An important distinction for evaluators: rebuilding from source defends against an artifact that differs from its source, such as a stolen publish token pushing a tampered package. A malicious change committed to the source repository is a different case, which is why Chainguard layers source and maintainer behavior scanning and cooldowns on top of the rebuild.

CVE remediation and the Athena coalition

Chainguard's remediation feature backports fixes for critical and high CVEs from newer upstream releases to older versions that maintainers no longer support, validates that no regressions are introduced by running the upstream test suites before and after the fix, and publishes the result as an incremental patch version (CVE remediation docs). The docs say it is available for a subset of libraries for Python, for Java in private preview (the Java overview says beta for Spring Boot) and for JavaScript, and that other libraries can be requested through your account team.

Version naming is ecosystem specific: Python uses a local version such as flask==1.1.2+cgr.1, Java uses a suffix such as 3.18.0-0.cgr.1, and JavaScript uses a prerelease style suffix such as 4.17.21-cgr.1. Remediated Python and Java artifacts are served from dedicated repositories (python-remediated and java-remediated), so you opt in by configuring them. For JavaScript, chainctl libraries remediate previews and --apply writes exact versions or overrides into package.json and the lockfile. Transitive coverage depends on the ecosystem: for Python, resolution through the Chainguard index picks up a higher precedence +cgr build wherever one exists, for Java a best effort BOM update may roll dependencies forward, and for JavaScript only the exact resolved versions with a remediated build are changed.

Chainguard also describes the Athena coalition, an industry group that pools findings and fixes open source vulnerabilities under embargo before disclosure. Help Net Security reported on 17 June 2026 that members receive private forks and rebuilt, hardened libraries through Chainguard Libraries before public disclosure, and quoted Chainguard's CEO as saying more than 20,000 findings had been processed and 2,000 patches issued across 500 projects. Those are company reported numbers, and the article names a founding member list (Help Net Security). If pre disclosure access matters to you, that is a distinctive Chainguard offering to evaluate on its own.

Verification, pricing and the SLA

chainctl libraries verify checks which of your dependencies were built by Chainguard, for JAR, WAR, wheels and npm tarballs and for directories and container images, with text, JSON, YAML and CSV output, and --output-attestations saves SBOMs and attestations for verified packages. It uses Sigstore trust roots, so the machine running it needs network access to the Sigstore TUF repository (verification docs).

On commercial terms, the pricing page says Libraries are priced by quote ("Get a free quote"), licensed per language ecosystem based on the number of developers using that language, with unlimited applications per ecosystem and no metering, and includes backported patches for certain critical and high severity CVEs in popular Python dependencies (pricing, accessed 28 Oct 2026). Chainguard's CVE policy covers Libraries with efforts based commitments and states no timelines (CVE policy). Contractual day counts exist for Containers and VMs, not for Libraries, so ask what you will get in writing.

Checksums will differ

Chainguard's FAQ is direct about a practical effect: because it rebuilds, build metadata and generated content differ from upstream, and whether checksums match upstream depends on the ecosystem and build process. Common causes of errors during migration are artifacts cached from upstream (Maven's .m2 or Gradle's cache), dependencies pinned to upstream hashes (such as package-lock.json or yarn.lock), and repository managers that enforce strict verification against Maven Central (FAQ). That is manageable, and it is a real part of the migration plan.

What Safeguard offers for the same packages

Gold Registry: fixed builds, same names, pass through the rest

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization.

The registry page lists the ecosystems it serves: npm (npm, pnpm, Yarn), PyPI (pip, uv, Poetry), Maven (Maven, Gradle), Go modules, NuGet, Composer, RubyGems, Cargo, Helm charts, OS packages and container images, plus AI models and agent skills (registry.safeguard.sh, accessed 28 Oct 2026). Configuration is a registry setting in the tool you already use: an .npmrc registry line and token for npm, a pip index URL, a Maven mirror of central in settings.xml, and GOPROXY for Go. Anything not in Gold, or outside your tier, comes from the public source (registry.npmjs.org, PyPI, Maven Central) through a verified cache, and every download is logged for audit. Chainguard's default is the reverse: serve only what it rebuilt unless you opt into fallback.

The mechanism, from Safeguard's launch post of 15 Oct 2026 (introducing Gold sourcing): find the upstream commit that fixed a vulnerability, backport it to the version you run, rebuild and run the tests. Its pre launch examples were minimist@1.2.5-sg.1 for CVE-2021-44906, with 163 of 163 tests passing, and pyyaml==5.3+sg.1 for two critical CVEs, with 1,286 tests passing. The post also describes a lodash@4.17.21 attempt that was refused, with nothing published, because the evidence was not there, and calls the refusal "the correct result". The sg suffix plays the same role as Chainguard's cgr suffix: a distinct version string so the build is identifiable.

The tiers, per the registry page: Gold keeps the latest version of each package line clean and older versions clean as of their build date. Gold Live keeps every version clean with continuous rescans, rebuilds and backports to older lines, faster fix targets, and requests for components not yet in Gold. The page publishes fix targets, which it does not frame as guarantees: for Gold, critical in 7 days, high in 14 and medium or low in 30; for Gold Live, critical in 72 hours, high in 7 days and medium or low in 14. Both tiers target notification of a new issue in 24 hours. Builds are signed with a Safeguard key in a hardware backed vault, verified with cosign against a published key. For packages, the SBOM, provenance and VEX are available at attestation endpoints under _gold/attest.

Package Firewall: the install time decision

Package Firewall is a different control. The docs describe it as a proxy in front of npm and pip that evaluates each dependency as it is fetched, including transitive ones, and can allow, warn or block (Package Firewall docs, accessed 28 Oct 2026). It checks for typosquatted names, dependency and namespace confusion, packages matching known malicious signatures or a blocklist, and runs static behavioral analysis of the archive without executing any code. Modes include audit (record without blocking), warn, block and quarantine, with held packages re evaluated and released automatically once their verdict clears, and aged out after a configurable window that defaults to 14 days. Every non allow decision becomes a finding in the unified findings model and is written to the audit trail. The docs recommend starting in audit mode, then moving to warn or block. Today, the docs list npm and pip, and say there is no CLI command for fronting an existing repository manager yet.

Compare the control points. Chainguard decides at the repository: what is served, what is blocked, and how long a new upstream version waits. Package Firewall decides at the install, with the verdict recorded as a finding. They are complementary rather than redundant, because a repository that rebuilds does not by itself explain to a developer why a specific install was refused, and an install control does not change the artifact.

Fix pull requests and lookup

Where a fixed version exists, Griffin, Safeguard's security model, opens tested, policy gated pull requests that move the dependency, singly or in bulk (AI Remediate docs). That is a different layer from Gold: Gold changes what a registry serves, and pull requests change your manifests and lockfiles. gold.safeguard.sh is the free lookup for packages and CVEs with a recommended safe version, no login required.

Side by side

How the approaches differ

Replace the supply, or fix and guard it

Chainguard's bet is that the supply itself should be replaced: rebuild from source, serve only what was rebuilt, and let a vendor decide what is admitted. The strength is that the default is safe, the rule against binaries without source is clean, and the evidence is uniform. The cost is coverage and fit: artifacts without source are absent, closed source Java libraries need another path, checksums change, and you are dependent on Chainguard to build the version you need, which its docs say is triggered by a request.

Safeguard's bet is narrower and additive. Keep the supply you have, replace the specific builds that are vulnerable with fixed ones, pass the rest through a verified cache with an audit log, and put a decision at install time for the packages that are not trustworthy. The cost is the other way around: the default for an unlisted package is the public source, so protection depends on the Package Firewall mode you choose and on Gold covering the versions that matter. Which is better depends on whether your threat model is dominated by the unknown package nobody asked for, or by the known vulnerable package you cannot upgrade.

Cooldown versus quarantine

Both vendors delay new versions, differently. Chainguard's cooldown holds a newly published upstream version out of your builds for a set time, default 7 days, so the community has time to report malware. Safeguard's quarantine holds a flagged package pending review and releases it when its verdict clears, aging it out after a window that defaults to 14 days. A cooldown is time based and global, a quarantine is verdict based and per package. A cooldown can delay a legitimate urgent fix, which Chainguard lets you tune per ecosystem. A verdict based hold depends on the quality of the verdict, which is why audit mode comes first. Test the one you pick against a real urgent upgrade.

Backports and version strings

Both vendors express a fixed build as a distinct version, +cgr.N or -0.cgr.N on one side and an sg suffix on the other. The version string decides how resolvers behave. Python treats a local version as higher precedence, which is how Chainguard's remediated index wins automatically. npm treats a prerelease style suffix differently, which is why Chainguard provides chainctl libraries remediate --apply to write exact versions. Ask each vendor, for each ecosystem you use, how a fixed build is selected, how a lockfile records it, and how your SCA tool and SBOM report it. A scanner that reads the version string may or may not recognize a suffixed build as fixed, so ask for the VEX or advisory feed and agree which source is the arbiter.

Evidence and trust anchors

Chainguard documents Sigstore signatures, SBOMs and SLSA provenance, with chainctl libraries verify to audit what you already have. Safeguard publishes a signing key and SBOM, provenance and VEX endpoints. The anchors differ, and the practical test is the same: a security engineer verifies a sample package without help and writes down how long it took.

Where each approach stops

A rebuilt dependency is not a reachable vulnerability analysis of your own code. Neither registry decides whether a vulnerable function is called, and neither fixes your first party code. Safeguard's platform adds reachability and pull requests that change your own manifests. Chainguard's Libraries product stays at the artifact supply. For the surrounding picture, see our earlier posts on Chainguard alternatives and Chainguard pricing.

An illustrative walk-through

This is a hypothetical scenario, not a customer result. A team runs a Python API and a Node.js front end, with a repository manager as the only route to the public registries.

Path A: Chainguard. Create a pull token with chainctl, add the Chainguard Python and JavaScript endpoints as the first upstream in the repository manager, and decide whether to enable upstream fallback (and with what cooldown) for packages Chainguard has not built. Add the python-remediated index if you want +cgr builds. Clear caches, regenerate lockfiles that pinned upstream hashes, and run chainctl libraries verify --detailed on the resulting virtual environment to see which dependencies came from the Chainguard Factory and which came from fallback. The result is a build in which most dependencies are rebuilt from source, plus a report of the exceptions.

# Path A, a sketch based on Chainguard's docs: standard and remediated Python indexes
pip install --index-url https://USER:PASSWORD@libraries.cgr.dev/python/simple/ \
  --extra-index-url https://USER:PASSWORD@libraries.cgr.dev/python-remediated/simple/ \
  -r requirements.txt
chainctl libraries verify --detailed ./venv/

Path B: Safeguard. Create a Gold pull token, point the repository manager or the build tools at the registry, and turn on Package Firewall in audit mode for npm and pip. Gold builds are used where they exist for the versions you pin, everything else passes through the verified cache, and the firewall records what it would have blocked. After a week of audit data, move to warn or block, and use fix pull requests to move the remaining vulnerable direct dependencies.

# Path B, a sketch based on Safeguard's pages: Gold index for pip, then the firewall (start in audit mode per the docs)
export PIP_INDEX_URL="https://token:$SAFEGUARD_TOKEN@registry.safeguard.sh/pypi/simple/"
pip install -r requirements.txt
safeguard pkgfw start

Neither path is complete alone. Path A gives a rebuilt supply with a vendor deciding what is admitted, and leaves reachability and your own code to other tools. Path B keeps your supply, fixes and guards it, and makes the policy yours to tune.

When to choose Chainguard

Choose Chainguard Libraries when:

• You want rebuilt by default. Serving only artifacts built from verified source is a strong, simple policy, and Chainguard is the vendor built around it.
• Your main fear is the compromised or tampered package. Build from source, malware and greyware scanning and a cooldown address that threat at the repository.
• Your stack is Python, Java and JavaScript and your dependencies are open source with public source repositories.
• You want pre disclosure access through the Athena coalition, and Chainguard's backports for older versions you cannot upgrade, in the ecosystems where that feature is available.
• You use a repository manager and want the endpoint to feed it, with chainctl libraries verify as an audit tool.
• You are already buying Chainguard Containers and want one vendor and one set of attestations across images and libraries.

When to choose Safeguard

Choose Safeguard Gold and Package Firewall when:

• You need to keep your current supply and fix the vulnerable parts of it, with the rest passing through unchanged and a log of every download.
• You use ecosystems beyond Java, JavaScript and Python, such as Go, NuGet, Composer, RubyGems, Cargo, Helm or OS packages, and want one registry and one token for them.
• You want a decision at install time on typosquatting, dependency confusion and known malicious packages for npm and pip, with audit mode first and findings for every decision.
• You want fixes that change your code too. Pull requests move your manifests, and Gold fixes the builds you cannot move off.
• You need deployment options. The pricing page describes an enterprise tier with a dedicated Gold mirror inside your VPC and air gapped snapshot delivery.
• You want the registry, the firewall and the fix workflow in one platform that also scans, attests and gates the rest of your pipeline.

Using both

They fit together. Chainguard's endpoint can be the preferred upstream for the ecosystems it covers, Safeguard's Package Firewall can sit in front for the install time record, and Safeguard's scanning, SBOMs, policies and fix pull requests apply to whatever the repository serves. Decide which system owns the SBOM and the VEX statement for a given package, and which tool opens the pull request for a given vulnerability, so developers receive one answer.

Evaluation checklist: a library bake-off

Run this on three to five real repositories across Java, Python and JavaScript, behind your actual repository manager. Record numbers before you read vendor answers.

1. Inventory. Export the full dependency list, direct and transitive, with versions, for each repository.
2. Coverage. Ask Chainguard what share of the list it builds, and how requests for missing versions are handled. Ask Safeguard which of the same versions exist as Gold builds. Record both match rates.
3. Absent artifacts. Note dependencies with no public source, closed source libraries, snapshots and non standard formats. Decide the fallback path for each.
4. Fallback and cooldown. If you enable Chainguard's upstream fallback, set a cooldown and test a legitimate urgent upgrade through it. For Package Firewall, run audit mode and review what it would have blocked.
5. Checksum impact. Switch a repository to each source and record every lockfile, cache and manager verification that breaks.
6. Version selection. For a remediated or Gold build, check how the package manager selects it and how the lockfile, SBOM and scanner report it.
7. Malware test. Replay a safe test set of known malicious package names against each control and record what is blocked, held or served. Do not install anything real; use the vendors' test methods.
8. Time to fix. Take the last ten critical CVEs in your dependency tree. Ask each vendor for the date a fixed build was available and compare with your detection dates.
9. Older versions. Pick three libraries you cannot upgrade. Ask each vendor whether a backport exists, what its version string is and how long it took to produce.
10. Verification. Have an engineer verify provenance and SBOMs with each vendor's commands, without vendor help, and record minutes.
11. Repository manager fit. Test with your real manager, including authentication, caching, rate limits and outage behavior.
12. Pre disclosure needs. If embargoed fixes matter, ask what membership requires and what you receive.
13. Evidence for auditors. Ask each vendor what documents and attestations you can hand to an auditor for a specific package version.
14. Layers above. Scan the same repositories for first party and unreachable findings, and decide which tool fixes those.
15. Commercials. Chainguard prices Libraries by quote, per ecosystem and developer count, per its pricing page. For Safeguard, see safeguard.sh/pricing for current plans and confirm in a quote. Compare the same scope.
16. Exit plan. Write how you would leave each: with Chainguard, pointing back to upstream and regenerating lockfiles. With Gold, removing the registry setting.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Griffin, Safeguard's security model, opens a policy gated pull request that moves the affected dependency to the safe version, and your own CI runs your tests on it before anyone merges. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Auto-merge is a separate switch and stays off by default, so your team decides what merges on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

FAQ

What is Chainguard Libraries?

A catalog of Java, JavaScript and Python dependencies that Chainguard rebuilds from verified upstream source in its own build infrastructure and serves from libraries.cgr.dev, with malware and greyware scanning, cooldowns for any upstream fallback, and CVE remediation for a subset of libraries. Go and .NET sections exist in the docs and are labeled beta. Source: Chainguard Libraries documentation, accessed 28 Oct 2026.

Does Chainguard Libraries serve every package on npm, PyPI and Maven Central?

No. By default it serves only packages Chainguard built, it requires verifiable source and a licence that allows redistribution, and its docs say the repository is not a full mirror. Closed source Java libraries such as proprietary JDBC drivers are not included. You can enable an upstream fallback with malware scanning and a cooldown for packages it does not carry.

How does Safeguard Gold differ from Chainguard Libraries?

Chainguard rebuilds and serves its own catalog by default. Gold serves fixed, rebuilt versions of packages that Safeguard has built and passes everything else through unchanged from the public source, with a verified cache and a download log. Gold covers a wider list of ecosystems on its registry page. Chainguard's catalog of rebuilt libraries is more developed for Java, JavaScript and Python. Source: both vendors' pages, accessed 28 Oct 2026.

Does Safeguard block malicious packages?

Package Firewall evaluates npm and pip installs and can block malicious, typosquatted and dependency confusion packages before they are installed, with audit, warn, block and quarantine modes. Chainguard blocks malware at its repository using OSV data, its own source and maintainer scanning and cooldowns. Test both against your own packages. Source: Safeguard Package Firewall docs and Chainguard Libraries docs.

Will switching to Chainguard Libraries break my lockfiles?

It can. Chainguard's FAQ says rebuilt artifacts can have different checksums from upstream, and lists cached artifacts, upstream pinned hashes in lockfiles and strict repository manager verification as common causes of errors during migration. Build pinning helps keep fallback versions stable afterward.

How do remediated versions work in each product?

Chainguard publishes a distinct version for a remediated build, such as +cgr.1 for Python, -0.cgr.1 for Java and -cgr.1 for JavaScript, from dedicated repositories for Python and Java and through chainctl libraries remediate for JavaScript. Safeguard's Gold Live tier describes backports to older lines, and Safeguard's launch examples use an sg suffix. Ask each how a resolver selects the fixed build in your ecosystem.

What does each vendor cost?

Chainguard's pricing page lists Libraries as "Get a free quote", licensed per language ecosystem by developer count. For Safeguard, see safeguard.sh/pricing for current plans and confirm in a quote. Compare the same scope.

Can I use both together?

Yes. Use Chainguard's endpoint as the preferred upstream for the ecosystems it covers, keep Safeguard Package Firewall and scanning in the path, and agree which system owns SBOM, VEX and fix pull requests.

Sources and access dates

All pages were accessed on 28 Oct 2026. Vendor facts change, so verify anything you plan to rely on.

• Chainguard: Libraries product page, pricing, CVE policy, Libraries overview, CVE remediation, verification, Java, Python, JavaScript, Go, .NET, FAQ.
• Press: Help Net Security, 17 June 2026.
• Safeguard: Gold Registry, introducing Gold sourcing, 15 Oct 2026, Package Firewall docs, AI Remediate docs, Gold Open Source, pricing.

Chainguard is named here in plain text for comparison. This post does not imply any partnership with or endorsement by Chainguard, and Chainguard has not reviewed it.