The Safeguard Gold Registry crossed 6,000 curated artifacts this month. Gold is the set of packages and images we build, validate, and ship ourselves, specifically because the upstream-with-a-pin model does not hold up over a long enough time horizon. Every artifact in Gold is zero-CVE at publish and monitored continuously; when a CVE appears in an upstream source, we rebuild and republish rather than just flag it.
This post covers what the 6,000-artifact milestone actually covers, how the registry is built, how you consume it, and the behaviors that are easy to miss if you are coming from a vanilla mirror setup.
What is in the 6,000?
Answer first: ten ecosystems, weighted toward what people actually deploy.
The split: roughly 1,600 npm packages, 1,400 PyPI packages, 650 Maven artifacts, 450 NuGet packages, 380 Go modules, 210 Rust crates, 220 Ruby gems, 190 PHP Composer packages, 650 container images, and 270 Helm charts. The image count includes common language base images (Node, Python, Java, .NET, Go, Rust, Ruby, PHP) with both distroless and minimal-shell variants, plus database and runtime images (Postgres, MySQL, Redis, Kafka, nginx, HAProxy, and others).
The selection rule is use-driven: we track the top 2,000 packages by install volume per ecosystem across the Safeguard fleet, intersect that with what customers are actually pulling, and build down from there. A package is eligible when it has a stable maintainer, a reproducible build, a license we can attest, and a test suite we can run. Of the theoretical top-2,000-per-ecosystem set, about 60% meet all four criteria on the first pass; most of the rest fail on reproducible-build or test-suite grounds.
About 400 of the 6,000 are Safeguard-maintained patches of packages whose upstream maintenance has lapsed. We backport CVE fixes, run the upstream test suite plus ours, and publish under the original name-plus-suffix (lodash-gold, request-gold, and similar). This is the lane that grew the most between the 4,000 and 6,000 milestones — abandoned-but-still-depended-on packages are a real problem, and publishing a pinned safe variant is the cleanest way we have found to handle it.
How does "zero-CVE at publish" actually work?
It is a pipeline, and it fails closed. Every Gold artifact goes through build, SBOM, scan, attest, sign, and publish, in that order, and the publish step is blocked on all five earlier steps succeeding.
Builds are reproducible. For source ecosystems (npm, PyPI, Maven, NuGet, Go, Rust, Ruby, PHP) this means a pinned builder image, a pinned toolchain version, and a fetch step that verifies upstream source against a known hash. For containers, this means a SLSA-level-3 build pipeline with hermetic inputs. The hash of the output is deterministic across two separate builder nodes; if it is not, publish is blocked.
SBOM generation is SPDX 2.3 for packages and CycloneDX 1.6 for container images, with both attached to every release. The SBOM covers the artifact and its transitive build and runtime inputs.
The scan step runs Eagle 3.0 plus a CVE feed against the full dependency closure. Any finding at high confidence or better — vulnerable.*, malware.*, typosquat.* — blocks publish. abandoned.* findings do not block publish but do raise the artifact's scheduled rebuild cadence. Findings on reachable code paths are weighted higher than unreachable ones, which matches how Safeguard treats findings everywhere else.
Attestation is Sigstore with a Safeguard-operated Fulcio and Rekor. Every Gold artifact has a signed attestation of its build provenance, its SBOM, its scan result, and its Gold classification.
How do I actually consume Gold from my build pipeline?
There are three modes: registry mirror, resolver rewrite, and policy enforcement. Most customers end up using two of the three.
Registry mirror mode replaces the upstream registry URL with the Gold URL in your package manager config. This works for npm, PyPI, Maven, NuGet, Ruby, and Composer. A package that exists in Gold is served from Gold; a package that does not exist in Gold falls through to the upstream registry unless you configure strict-mode, in which case the install fails. Strict mode is usually what regulated customers want; falling-through mode is usually what development teams want.
# npm
npm config set registry https://registry.gold.safeguard.sh/npm/
npm config set //registry.gold.safeguard.sh/npm/:_authToken $SG_TOKEN
# pip
pip config set global.index-url https://registry.gold.safeguard.sh/pypi/simple/
pip config set global.extra-index-url https://pypi.org/simple/
Resolver rewrite mode is more surgical. Rather than redirecting the whole install, the Local Runner or a CI step rewrites specific dependencies to their Gold equivalent when Griffin opens a remediation PR. This is the mode we recommend for teams with large existing lockfiles who do not want a big bang migration — Griffin pins to Gold when the Gold version is strictly safer than what is locked.
Policy enforcement mode does not change how you install; it enforces at merge time. A workflow reads the lockfile, compares each entry to the Gold Registry, and fails CI if a dependency has a Gold alternative that would resolve an open finding. Eagle 3.0's label output is the input to this check.
For container images, the equivalent of registry mirror mode is a pull-through cache. ghcr.io/safeguard/library/python:3.12-slim is a drop-in for python:3.12-slim with the same ABI and a published attestation trail.
What is the refresh and rebuild cadence?
Daily for the scan, event-driven for the rebuild.
Every Gold artifact is re-scanned against the current CVE feed and the current Eagle classifier at least once every 24 hours. When a new CVE is published that matches a Gold artifact's dependency closure, the artifact is flagged for rebuild and the rebuild is attempted within the hour. Most rebuilds complete the same day; a small number that require a maintainer response upstream can take longer, and those have public status pages.
When a rebuild produces a new version, the old version is kept available and marked superseded. Lockfiles that pinned the old version keep resolving; Safeguard surfaces the supersede in the web app and via the MCP Server so that Griffin can open a PR to move you to the new version on its next remediation pass.
For customers who need a slower cadence — air-gapped environments, change-control windows — there is a lts channel that lags the default channel by 30 days and gets security-only updates. Both channels are in all three regions (US, EU, Gov).
How Safeguard.sh Helps
The Gold Registry is the artifact layer under most of what the rest of the platform does: Griffin remediates by pinning to Gold when a safe version exists, Eagle uses Gold membership as a classifier feature, Lino maps Gold attestations into compliance evidence (NIST SSDF, FedRAMP SI-2, SOC 2 CC8.1), and self-healing containers rebuild against Gold base images automatically. You reach Gold from every Safeguard surface — the web app at app.safeguard.sh in US, EU, and Gov regions, the desktop application, the IDE extensions for VS Code, Cursor, and JetBrains, the MCP Server, and the Local Runner — and the same Sigstore attestations are served from each. For regulated workloads, the Gov region carries the same 6,000 artifacts under FedRAMP HIGH, IL7, and SOC 2 Type II boundaries, so you do not need to maintain a separate mirror to stay in scope.