Short answer: work down a ladder. Check whether a fixed version already exists and upgrade to it. If none does, push the fix upstream. If the issue is severe or upstream will not move, build and run a patched fork from source that you can verify. Safeguard Gold covers each rung, starting with a free lookup at gold.safeguard.sh.
Why you get stuck
A vulnerability is public and your application depends on the package. The maintainer has not shipped a fix, or has said they will not. Until something changes you carry a vulnerable package, or you maintain a private patch that nobody else reviews and that drifts from upstream every release. A package index also says little about how an artifact was built, so you cannot check what you are installing.
The steps
- Confirm you are affected. Identify the package, the version you run and the vulnerability. Check whether the vulnerable code is reachable from your application. If it is not, the urgency changes.
- Look for a fixed version. If one exists, upgrade. A fix pull request that moves you to it, with a lock file update, is the lowest-effort path, and your tests run on the pull request.
- Check the safe version. A newer release is not always the safe one. Look for a recommended safe version, not only the latest.
- If there is no fix, contribute one. Open an issue with a clear reproduction, and offer a patch to the maintainer. Many fixes get accepted when the work is done for them.
- If upstream will not move and the issue is severe, fork. Fork the project, apply the fix, and rebuild from source rather than patching a binary.
- Make the build verifiable. Sign the build. Attach an SBOM, SLSA provenance and VEX, so anyone downstream can see what was built, from what and how.
- Serve it from one controlled place. Point your builds at the patched artifact, and keep a note to switch back when upstream ships its own fix.
- Record the decision. Write down why you forked, who approved it and when you will review it.
How to judge a patched fork
A fork is only as good as the evidence behind it. Before you run one in production, check that it was rebuilt from source and not repackaged from a binary, that the build is signed, and that you can read the SBOM and the provenance. Check that the patch is small and reviewable, and that the vulnerability is marked fixed in the attached VEX document. If any of that is missing, you are trusting the publisher, not verifying the build.
Common mistakes
- Pinning to an old version for months because the upgrade looks risky, instead of testing it in a branch.
- Applying a private patch and forgetting it, so the next upstream release silently drops it.
- Treating a package as safe because it is popular. Popularity says nothing about whether a vulnerability is fixed.
- Skipping the reachability check, then spending a week on a flaw your code never calls.
What Safeguard Gold does
Gold has two parts.
Gold Open Source is free and needs no login at gold.safeguard.sh. Look up a package or a CVE, run the "Am I affected?" checker to get a recommended safe version, or use the free read API. It also offers a Chrome extension for lookups in the browser and a CI gate action that can fail a build on a known exploited or known vulnerable component.
Gold Registry is the hardened-build side. 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 fix route follows the ladder above. When a fixed version exists, Safeguard opens a fix pull request that moves you to it. When upstream has no fix yet or will not ship one, Safeguard works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes it and publishes a hardened Gold build.
Download
Download the datasheet, US Letter (PDF)
Download the datasheet, A4 (PDF)
