Gold, Gold Live, Gold Zero-Day: coverage over time explained

A fixed build is clean on the day it's built. The question that matters is what happens the next time a CVE is published against it. Safeguard's three Gold tiers, Gold, Gold Live and Gold Zero-Day, all meet the same security bar at build time. They differ only in coverage over time: which versions we keep clean after that day, and how fast.

This post explains the three models of coverage behind the tiers (point-in-time, continuous and ahead-of-disclosure), how a rebuild actually reaches your builds without breaking reproducibility, and the fix-time targets for each tier. If you haven't read it, the previous post covers what a Gold build is and how to verify one.

Every scan result has a date on it

"No known vulnerabilities" is always true as of a moment. The CVE database grows every day, and a lot of new entries describe bugs in code that shipped years ago. A package that scanned clean in March can carry a critical CVE by April without a single byte changing.

So any promise about a clean component is really a promise about time. There are three honest shapes it can take.

Point-in-time. The build was clean when it was made, and the evidence says when. After that, keeping current is up to you.

Continuous. Someone keeps rescanning the build after release and rebuilds it when something new turns up. The guarantee isn't "this will never have a CVE". It's "when one appears, a fixed rebuild follows within a stated time".

Ahead of disclosure. Some vulnerabilities are found by researchers before any public advisory exists. Under coordinated disclosure, the maintainer gets time to fix before details go public. A continuous model reacts to public advisories. An ahead-of-disclosure model can ship a fix before the advisory is published, while holding back the details until disclosure.

The three Gold tiers

Gold keeps the latest version of each package line clean. When a new issue turns up in the latest version, we rebuild it. Older versions stay clean as of their build date, and their evidence says so. Gold suits teams that track the latest release of their dependencies.

Gold Live keeps every version clean. Every Gold version is rescanned and rebuilt when a new issue is found, including older lines you can't move off yet. Gold Live also tells you when it happens, in the ways your tooling can act on: notices, signed webhooks, automatic upgrade pull requests and CI triggers. It suits teams on long-lived release branches, regulated products with frozen versions, and anyone who can't upgrade on someone else's schedule.

Gold Zero-Day is coming soon. It will add early fixes for Zero Days found by Safeguard's own models on top of everything in Gold Live. We'll confirm its targets when it launches.

All three tiers share the build-time bar: no known vulnerabilities at last scan, no known malware, a reproducible build, a CycloneDX SBOM, SLSA provenance, a VEX document and a Safeguard signature.

How a rebuild reaches your build

This is the part that decides whether continuous coverage actually helps. A rebuild that silently changes what your lockfile installs breaks reproducibility. A rebuild that nobody installs protects nobody. You want to choose which one you're getting.

Rebuilds get new versions

A Gold build's version is the upstream version plus a build number: 1.2.3-sg.1 for npm and most ecosystems, 1.2.3+sg.1 on PyPI. A rebuild of the same upstream version becomes 1.2.3-sg.2. Existing versions are never overwritten.

Pinned stays pinned

If you pin an exact Gold version, a digest or a lockfile hash, a rebuild changes nothing until you move the pin. That's the right default for production: what you tested is what you ship.

# Pin one Gold build (exact version; -sg.N is a semver prerelease, so ^1.2.3 never picks it on its own)
npm install <package>@1.2.3-sg.1 --save-exact

# Follow the newest Gold build of the package (moving dist-tag)
npm install <package>@gold-latest

# Force a Gold build for a transitive dependency (package.json)
{
  "overrides": { "<package>": "1.2.3-sg.1" }
}
# pnpm: "pnpm": { "overrides": { "<package>": "1.2.3-sg.1" } }
# yarn: "resolutions": { "<package>": "1.2.3-sg.1" }

Or follow a moving tag

If you'd rather pick up rebuilds on the next resolve, each ecosystem has a pointer that moves. npm has the gold-latest dist-tag above, and with the registry's same-coordinate option a fresh resolve of 1.2.3 also returns the newest Gold build of 1.2.3. On PyPI, a plain ==1.2.3 pin resolves to the highest 1.2.3+sg.N on a fresh resolve. Container images have a moving -sg tag next to the immutable ones:

# One Gold build
docker pull registry.safeguard.sh/library/python:3.12.7-sg.1

# Moving tag: the newest Gold rebuild of 3.12.7
docker pull registry.safeguard.sh/library/python:3.12.7-sg

# Strongest pin: the digest
docker pull registry.safeguard.sh/library/python@sha256:<digest>

A sensible pattern for images is to follow the moving tag in a scheduled job, then pin the digest it resolves to in your Dockerfile. You get rebuilds quickly, and every release still names exactly one image.

Know when to move the pin

Pinning is only safe if something tells you when a pin is out of date. Gold Live has four ways to do that, and you can use any combination.

Notices. Affected workspaces get a notice in Safeguard naming the package, the rebuilt version and what it fixes.

Signed webhooks. Safeguard sends a gold.update_published event to your endpoint when a rebuild of a version you use is published:

POST <your webhook URL>
Content-Type: application/json
User-Agent: Safeguard-Gold-Webhook/1
X-Safeguard-Event: gold.update_published
X-Safeguard-Delivery: <update id>
X-Safeguard-Timestamp: 1760500000
X-Safeguard-Signature: sha256=<hex HMAC-SHA256(secret, "<timestamp>.<body>")>

{
  "artifact": "<package>",
  "artifact_kind": "package",
  "coordinates": {
    "package": "<package>",
    "registry_url": "https://registry.safeguard.sh/npm/",
    "version": "1.2.3-sg.2"
  },
  "digest": null,
  "ecosystem": "npm",
  "embargo": null,
  "event": "gold.update_published",
  "fixed": ["CVE-YYYY-NNNNN"],
  "id": "<update id>",
  "kind": "rebuild",
  "line_id": "package:npm:<package>@1.2.3",
  "new_version": "1.2.3-sg.2",
  "old_version": "1.2.3-sg.1",
  "published_at": "2026-10-15T09:00:00Z",
  "rebuild_included": true,
  "severity": "high"
}

The signature is an HMAC-SHA256 over the timestamp and the raw body, so you can reject forged deliveries and stale replays. Verify against the raw bytes, before any JSON parsing:

# Python 3, standard library only. Verify against the RAW request body, before any JSON parsing.
import hashlib, hmac, os, time

SECRET = os.environ["SAFEGUARD_WEBHOOK_SECRET"]  # the whole value, including "whsec_"
TOLERANCE_SECONDS = 300

def verify(raw_body: bytes, headers) -> bool:
    try:
        ts = int(headers.get("X-Safeguard-Timestamp", ""))
    except ValueError:
        return False
    if abs(time.time() - ts) > TOLERANCE_SECONDS:
        return False
    expected = "sha256=" + hmac.new(
        SECRET.encode(), f"{ts}.".encode() + raw_body, hashlib.sha256
    ).hexdigest()
    return hmac.compare_digest(expected, headers.get("X-Safeguard-Signature", ""))

# Flask: verify(request.get_data(), request.headers)
# FastAPI: verify(await request.body(), request.headers)
# Answer 2xx quickly; X-Safeguard-Delivery is the update id, so ignore one you have already handled.

CI triggers. If you turn them on, Safeguard can start a workflow in your repository when a rebuild lands. The workflow re-resolves against Gold, runs your tests and shows you the diff:

# .github/workflows/safeguard-gold-update.yml
# Re-resolves against Safeguard Gold when a rebuilt Gold version you use is published (Safeguard sends
# repository_dispatch "safeguard-gold-update" when CI triggers are on), or when you run it by hand.
# Repository secret: SAFEGUARD_TOKEN
name: Safeguard Gold update
on:
  repository_dispatch:
    types: [safeguard-gold-update]
  workflow_dispatch:
permissions:
  contents: read
jobs:
  re-resolve:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Which update
        env:
          UPDATE_ID: ${{ github.event.client_payload.update_id }}
          ARTIFACT: ${{ github.event.client_payload.artifact }}
          NEW_VERSION: ${{ github.event.client_payload.new_version }}
        run: echo "Safeguard Gold update ${UPDATE_ID:-manual}: $ARTIFACT $NEW_VERSION"
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          registry-url: https://registry.safeguard.sh/npm/
      - name: Fresh resolve and test
        env:
          NODE_AUTH_TOKEN: ${{ secrets.SAFEGUARD_TOKEN }}
        run: |
          rm -f package-lock.json
          npm install --prefer-online
          npm test
          git diff --stat
      - name: Python
        env:
          PIP_INDEX_URL: https://token:${{ secrets.SAFEGUARD_TOKEN }}@registry.safeguard.sh/pypi/simple/
        run: pip install --upgrade --no-cache-dir -r requirements.txt

Upgrade pull requests. Safeguard can open a pull request that moves your pins, overrides or lockfile entries to the rebuilt version, with the fixed CVEs in the description. Your CI runs on it like any other change before anyone merges it.

Fix-time targets by tier

These are the targets Gold is built to. They are targets, not guarantees, and not measured averages. Gold's fix targets apply to the latest version of a package line. Gold Live's apply to every version.

A few notes on reading the table.

• Every tier is notified within 24 hours, and malware is pulled within 24 hours, whatever the tier. A known-malicious package isn't something to leave on a slower clock.
• The uptime target covers registry.safeguard.sh itself. Anything not in Gold passes through to the public source via our cache, so its availability also depends on that source.

Choosing a tier

Ask one question: when a new critical CVE lands on a version you run, which version is it?

If it's almost always the latest release, because your teams upgrade continuously, Gold covers you. For a critical CVE, the target for a fixed latest version is 7 days, and you keep upgrading as you already do.

If it's often an older line, because of a frozen release, a long-term-support branch or a dependency that pins an old version, you want Gold Live. It's the tier that rebuilds the version you actually run, and the one that tells your pipeline when it has.

Gold Zero-Day will be for teams that also want early fixes for Zero Days, before they become public advisories. It isn't available yet.

Where this is going

Today's targets are measured in days and hours. The direction is shorter: from days to hours, then minutes, and eventually seconds and milliseconds. That's a goal, not something Gold does today. Each step down depends on the pipeline handling more of the backport and verification on its own, with evidence good enough to stand behind a tighter target.

Next in this series, the runtime side: what library-level protection catches that a WAF can't.

Gold and Gold Live are in early access, and the registry is live at registry.safeguard.sh. Pricing is available on request. To try it, book a call or email sales@safeguard.sh.