We're building Gold sourcing: pull the fixed package instead of fixing it yourself

The Safeguard team · 15 October 2026

Updated 15 October 2026: the first Gold builds are now published on registry.safeguard.sh: minimist@1.2.5-sg.1, minimist@1.2.8-sg.2 and pyyaml==5.3+sg.1. The version wording for npm below has been corrected.

Most of the vulnerabilities in your software live in code you didn't write. We're building Safeguard Gold sourcing so you can pull a fixed and signed build of that open-source code from a private registry instead of remediating it yourself. It isn't generally available yet. Early access is open today.

This post is for the people who own dependency risk, usually AppSec and platform engineers. It covers what Gold sourcing will do, the launch targets for each tier, how it will fit your package managers, and how you'll be able to check our work.

What Gold sourcing is

Gold sourcing is a private registry at registry.safeguard.sh that serves Safeguard-fixed builds of open-source components. When a component you depend on has a known vulnerability, Safeguard will fix the code that carries it and rebuild the component. Each build is scanned and signed before it goes into the registry, and your package manager will pull the fixed build.

Anything that isn't in Gold will fall back to the public source, unchanged. You won't maintain two lists of where packages come from.

We're starting with packages and container images. Models, agent skills and connectors (including MCP servers) come later.

Why "just upgrade" often doesn't work

Upgrading is the right answer when you can do it. Often you can't, at least not this sprint.

The fix for a critical CVE might only exist in a new major version that breaks your API. A release branch might be frozen. A transitive dependency might pin the vulnerable version three levels down, behind a maintainer who hasn't merged anything in a year. So the finding sits in the backlog. It gets a risk acceptance and comes back next quarter.

The work that actually closes it is narrow. Find the upstream commit that fixed the hole, backport it to the version you run, rebuild, and prove the tests still pass. It takes skill. And it's identical for every team running that version, which is the whole point: do it once, centrally, and let everyone pull the result.

What every Gold artifact will ship with

Every Gold build has to clear the same bar before it can be published, whatever the tier:

• No known vulnerabilities at last scan (0 known CVEs at last scan), with the scan date recorded.
• No known malware, with the scan date recorded.
• An SBOM listing what's inside.
• Signed SLSA provenance describing how it was built.
• A VEX document stating which vulnerabilities the build fixes.

"No known vulnerabilities at last scan" is deliberate wording. New CVEs are published against old code every day, so nobody can honestly promise that a component will stay free of them. What we can give you is the date of the last clean scan and a clear rule for what happens when a build stops being clean. That rule is what the tiers are about.

Three tiers, one security bar

All three tiers ship builds that meet the same bar on the day they're built. They differ in how long we keep them clean.

Gold keeps the latest version clean. When a new issue turns up in the latest version of a package line, we rebuild it. Older versions are clean as of their build date.

Gold Live keeps every version clean. Every version is rescanned continuously and rebuilt when something new is found, including backports to older lines. Its fix targets are faster.

Gold Zero-Day is coming soon. It will add early fixes for Zero Days that Safeguard's own models find, on top of everything in Gold Live.

Launch targets

These are the targets we're building to for launch. They are targets, not guarantees, and we plan to publish measured fix times next to them once we have them. Gold's fix targets apply to the latest version of a package line. Gold Zero-Day's numbers will be confirmed at launch.

The uptime target will cover registry.safeguard.sh itself. Components that aren't in Gold will be passed through from the public source, so their availability also depends on that source.

How a fix gets made

Here is the method, shown with three pre-launch test runs of the fix pipeline. The minimist and pyyaml builds from those runs are now published on registry.safeguard.sh as minimist@1.2.5-sg.1 and pyyaml==5.3+sg.1, alongside minimist@1.2.8-sg.2.

minimist@1.2.5 carries a critical prototype-pollution bug, CVE-2021-44906. Upstream fixed it in the 1.2.6 line. The pipeline found the two commits that closed it and cherry-picked them onto 1.2.5 with their original references. It left out two other listed commits that belong to different release lines. The package's own suite passed, 163 of 163, including the upstream proof-of-concept test. Before the fix, parsing --_.constructor.constructor.prototype.foo bar set Function.prototype.foo. After it, nothing was polluted.

pyyaml==5.3 carries two critical arbitrary-code-execution bugs in full_load: CVE-2020-1747 and CVE-2020-14343. Both fixes were backported from the 5.3.1 and 5.4 releases, and 1,286 tests passed. The public exploit payload runs code against upstream 5.3. Against the rebuilt package it raises a ConstructorError and runs nothing.

The third run matters most. lodash@4.17.21 as published to npm is built from a generated tag rather than the source tag, so the upstream fix doesn't apply cleanly. Its published test script is just an echo, which the pipeline treats as "no tests", never as a pass. The pipeline refused to call it clean and published nothing. That package needs a human backport and a closer look at one advisory. When the evidence isn't there, a refusal is the correct result.

Version numbers stay compatible with what you already pin:

• npm and Maven builds use the upstream version with a -sg.N suffix, such as 1.2.5-sg.1. In npm's semver that's a prerelease, so a range like ^1.2.5 never picks it by itself: you pin it, override it or follow the gold-latest dist-tag. With the registry's same-coordinate option, a request for upstream 1.2.5 is also answered with the newest Gold build of 1.2.5, in a file whose version reads 1.2.5 and whose metadata names the Gold build.
• PyPI builds use a local version such as 5.3+sg.1, which still matches pyyaml==5.3.
• Container images get a -sg.N tag and their own digest.

How it will fit your package managers

The registry is live, with endpoints for npm, PyPI, Maven, container images and other ecosystems. Gold builds exist for npm and PyPI so far. You point your existing configuration at it with a pull token from your workspace admin: the registry line in .npmrc, the index URL for pip, a mirror in Maven's settings.xml, or a docker login. The exact configuration is in Why patching your dependencies yourself doesn't scale.

Two behaviours are worth knowing now, because they shape how you'll roll it out.

Existing lockfiles will keep installing exactly what they pinned. npm ci against an old lockfile still pulls the upstream tarball, and hash-pinned Python requirements keep the upstream file. To adopt Gold, you re-lock. A fresh resolve records the Gold build and its integrity hash, and that becomes your pin.

Maven caches releases in ~/.m2, so picking up a Gold build means clearing the group's directory or starting from a fresh CI cache. If you pin checksums with Gradle dependency verification, a pinned upstream checksum fails closed. The registry will never swap it silently.

How you'll check our work

You'll be trusting us with build inputs, so you shouldn't have to take our word for anything. Every Gold build is signed with a key held in a cloud key management service. The public key is published at https://registry.safeguard.sh/_gold/keys/cosign.pub, and you verify the signature and the SLSA provenance yourself with standard cosign commands. Signing is key-based, and signatures are not written to a public transparency log. Entitled customers can download the SBOM, provenance and VEX for each build from the registry.

Where Gold will show up in Safeguard

Gold sourcing lives in Safeguard Open Source Manager (OSM). For early-access customers, the inventory at app.safeguard.sh/osm/inventory shows which of the components Safeguard already tracks across their projects have a Gold build, which tier covers it and when it was last clean. Where there's no Gold build yet, they can request one from the same screen.

We're also building Gold into compliance evidence. The SBOM, provenance, signature and VEX for each build will be able to support software supply chain controls in SOC2, NIST SSDF and the EU Cyber Resilience Act. That evidence supports those controls. It doesn't satisfy them on its own, and your auditor still makes the call.

Where this is going

Our launch targets are measured in days and hours. The direction is shorter: from days to hours, then minutes, and eventually seconds and milliseconds.

That is a goal, not something Gold sourcing does today. Each step down depends on the pipeline handling more of the backport and verification on its own, and on measured fix times that justify a tighter target. We'll publish those measurements as we go, so you can judge the progress yourself.

Early access is open now. Pricing is available on request. To join, book a call and tell us which packages and images you'd like fixed first, or email sales@safeguard.sh.