Gold Registry Evidence Pages: What the Gold Bar Proves to an Auditor

A Gold Registry evidence page is the per-artifact record behind a hardened package or container image from registry.safeguard.sh. It shows an auditor that one specific artifact, identified by its digest, met the Gold bar when it was last checked: no exploitable critical or high CVEs, a completed license check, signed build provenance and a signature you can verify yourself. It does not prove anything about your own code, about artifacts you did not pull from the registry, or about the future.

That distinction matters more than the badge. An auditor working from EO 14028, the CISA secure software development attestation form or the EU Cyber Resilience Act is not asking whether a component looks safe. They are asking whether you can show, with artifacts, that you know where a third-party component came from, that you checked it for known vulnerabilities, and that the thing you checked is the thing you shipped. This post walks through what those frameworks ask for, what the Gold bar covers, how to read each part of the evidence, how to verify the signature and provenance with your own tools, and where the evidence stops.

Key takeaways

• Gold Registry (GA) serves hardened, drop-in packages and container images from registry.safeguard.sh. Each Gold artifact is held continuously to the Gold bar and has a public evidence page. The registry asks for a Safeguard Gold pull token before it serves anything.
• The Gold bar covers known exploitable critical and high CVEs, a license check, SLSA Build L3 or higher provenance and a signature. It is a continuous check, not a warranty. An artifact that regresses loses its badge.
• Attestation and signing (GA) is how you check the claims yourself. Safeguard's docs say Gold signatures are made with Safeguard's own key and verified with cosign against a published public key. There is no public transparency log entry to look up.
• Gold Open Source (GA) at gold.safeguard.sh uses the label "Gold Certified" for something narrower: no known vulnerabilities in the indexed upstream version and not deprecated. It does not rebuild or sign. Do not hand an auditor a Gold Open Source page as if it were registry evidence.
• Open Source Manager, OSM (GA) is where you see which of your open source packages are vulnerable and request a Gold version. Building a fork when upstream has no fix (fork and patch) is early access.
• SBOM generation and analysis (GA), SCA and vulnerability management (GA), policies, gates and guardrails (GA), the compliance and GRC suite (GA), and the CLI and local runner (GA) carry the rest of the audit trail: what is in your build, what is wrong with it, and what stopped it shipping.
• Autonomous remediation (GA, ships off) opens upgrade pull requests when a fixed version exists. It ships with every category set to Manual.

What auditors expect you to show about third-party components

Three texts drive most of the questions a supplier gets about open source and third-party components today. Each asks for something slightly different, and the differences decide what an evidence page can and cannot answer.

EO 14028 section 4(e)

Executive Order 14028, published in the Federal Register on 17 May 2021, told NIST to issue guidance on practices that enhance software supply chain security. Section 4(e) lists the criteria that guidance had to cover. Four of them are directly about components you did not write:

• 4(e)(iii): use automated tools, or comparable processes, to maintain trusted source code supply chains.
• 4(e)(iv): use automated tools, or comparable processes, that check for known and potential vulnerabilities and remediate them, regularly and at a minimum before release.
• 4(e)(vi): maintain accurate and up to date data, provenance (the order glosses this as origin) of software code or components, and controls on internal and third-party components, with recurring audits.
• 4(e)(x): ensure and attest, to the extent practicable, to the integrity and provenance of open source software used within any portion of a product.

Item (x) is the one auditors quote. Integrity means the bytes you ship are the bytes that were checked. Provenance means you can say where those bytes came from and how they were built. A vulnerability scan alone answers neither question.

The CISA Secure Software Development Attestation Form

OMB memorandum M-22-18 (14 September 2022) told agencies to collect self-attestations from software producers before using their software. The common form that came out of that process is published by CISA, with a revision date of 14 May 2024 on CISA's page. The form is built on NIST SP 800-218, the Secure Software Development Framework (SSDF) version 1.1, published in February 2022.

The form's Section III has four attestation statements. Two of them are about third-party components:

• Statement 2: the producer makes a good-faith effort to maintain trusted source code supply chains by using automated tools or comparable processes to address the security of internal code and third-party components and manage related vulnerabilities. The form maps it to EO 14028 4(e)(iii) and SSDF tasks including PO.5.2, PS.1.1, PS.3.1, PW.4.1 and PW.4.4.
• Statement 3: the producer maintains provenance for internal code and third-party components incorporated into the software, to the greatest extent feasible. The form maps it to 4(e)(vi) and SSDF tasks including PO.1.3, PS.3.1, PS.3.2, PW.4.1 and PW.4.4.

Statement 4 covers automated vulnerability checks run on an ongoing basis and before releases, a policy to address discovered vulnerabilities before release, and a vulnerability disclosure program.

Two details trip people up. First, the form says third-party open source components incorporated into a product are not themselves in scope for a separate attestation. The producer attests for its own product, and that attestation includes the steps it took to reduce the risk of the components inside. The form states that producers using third-party components "are required to attest" to those steps. Second, CISA's page now notes OMB memorandum M-26-05, which describes a risk-based approach under which agencies may choose to use the form and may contract for a current SBOM on request. Whether your federal customer still asks for the form is a question for that customer. What they ask for underneath it, provenance and vulnerability evidence for components, has not gone away.

The EU Cyber Resilience Act

Regulation (EU) 2024/2847, the Cyber Resilience Act, applies in full from 11 December 2027. Article 71 sets two earlier dates: Article 14 reporting obligations apply from 11 September 2026, and Chapter IV on notified bodies from 11 June 2026. The European Commission's CRA page confirms the reporting date and notes that the Commission published practical guidance for manufacturers on 27 July 2026.

The CRA texts that matter here:

• Article 13(5): manufacturers must exercise due diligence when integrating components sourced from third parties, so that those components do not compromise the product's cybersecurity. This explicitly includes free and open source components that were not placed on the market commercially.
• Annex I, Part II, point 1: manufacturers must identify and document vulnerabilities and components, including by drawing up an SBOM in a commonly used, machine-readable format covering at least the top-level dependencies.
• Annex I, Part II, point 2: address and remediate vulnerabilities without delay, including by providing security updates.

The recitals also frame the goal of placing products on the market "without known exploitable vulnerabilities", which is close in spirit to how the Gold bar is phrased. The CRA does not name SLSA, Sigstore or any specific evidence format. It asks for due diligence and documentation. Signed provenance and a dated vulnerability record per component are one strong way to show both.

What these three have in common

Strip away the formatting and every one of these texts asks you to produce the same four things for a third-party component:

1. Identity: which component, which version, which exact artifact.
2. Origin: where it came from and how it was built.
3. Known vulnerability state: what was checked, when, and what was found.
4. Integrity: proof that the artifact in your product is the one that was checked.

An evidence page is useful to an auditor to the extent it answers those four for a specific digest. Hold every field you read against that list.

The Gold bar, and how it is held continuously

Safeguard's offering defines a set of criteria every artifact in Gold Registry (GA) must meet. In plain terms:

The full published bar is quoted word for word in the Gold Registry section near the end of this post.

What "continuously" means

The Gold bar is not a one-time certificate. New CVEs are published against old code every day, so an artifact that was clean at build time can stop being clean without a single byte changing. Safeguard's offering states that Gold is held to the bar continuously and that an artifact loses its Gold badge if it regresses.

For an auditor, that has two consequences.

First, every claim on an evidence page has an implicit "as of" date. The useful question is not "is this artifact Gold?" but "was it Gold on the date we shipped, and is it still Gold today?" Your records need to capture the first; the evidence page and a fresh check answer the second.

Second, losing the badge is a signal, not a failure of the registry. It is the system working. What matters is whether your process noticed and acted. That is your evidence to produce, not Safeguard's.

SLSA levels: read the level from the provenance

SLSA version 1.0 defines a Build track with levels L0 to L3. Build L2 requires a hosted build platform that generates and signs the provenance. Build L3 adds strong controls that prevent build runs from influencing one another and keep the signing secrets out of reach of user-defined build steps. In SLSA's words, L3 means forging provenance or evading verification requires exploiting a vulnerability "beyond the capabilities of most adversaries".

Safeguard's own documents do not agree on the minimum level. The offering states SLSA L3 or higher for Gold Registry. One OSM docs page says Gold packages require a minimum of SLSA Level 2, and another OSM page describes Gold Directory packages in terms of an LCAL score. Some Safeguard docs also list an L4, which comes from the pre-1.0 SLSA draft; SLSA v1.0 stops at Build L3. Do not resolve this by quoting a number from marketing. Resolve it by reading the provenance itself and checking the builder identity against what you trust, as described below. Whatever level you put in an audit file should come from that check.

What is on a per-artifact evidence page, and how to read each field

Safeguard's offering describes a public evidence page per Gold Registry artifact, intended for audits under frameworks such as EO 14028 and the CRA. Safeguard's product docs do not yet publish a field-by-field reference for that page. Rather than invent a layout, this section reads it the way an auditor should: by the claims it must support, using the attestation fields Safeguard's docs do describe and the open standards those attestations follow.

Identity fields

Package or image name, ecosystem and version. Useful for humans, worthless as proof on their own. A version tag can be moved. Two builds of "1.2.3" can differ.

Digest (SHA-256). This is the field that matters. Safeguard's attestation docs state that every attestation carries the artifact digest and that any change to the artifact invalidates every attestation. In the in-toto Statement format that Safeguard's attestations use, the subject of a statement is identified by its digest, and the in-toto spec says subjects are matched purely by digest. Read every other claim on the page as a claim about this digest and nothing else.

How to read it: copy the digest, then confirm it matches the digest of the artifact in your lockfile, image manifest or deployment. If it does not match, nothing else on the page is about your artifact.

Provenance fields

Safeguard's docs list SLSA Provenance v1 as one of five attestation types it produces, alongside CycloneDX SBOM, SPDX SBOM, a vulnerability scan snapshot and a Safeguard Review. The ESSCM attestation view documents these provenance details for a component: build platform, source repository, build trigger, build timestamp and builder identity. These map closely to the SLSA provenance v1 fields:

How to read it: an auditor cares less about the exact values than about whether you checked them against expectations you set in advance. "The builder was one we trust at Build L3, and the source matched the upstream project we expected" is a sentence you should be able to write from these fields.

Known vulnerability state

Safeguard's attestation types include a vulnerability scan predicate, described in the docs as a snapshot of known vulnerabilities at build time. The ESSCM attestation view also records when an attestation was last verified and a verification status of pass, fail or partial.

How to read it: there are two dates here and they mean different things. The build-time snapshot tells you what was known when the artifact was made. The last-checked date tells you how fresh the "still Gold" claim is. For an audit, record both, and record the date you shipped.

License check

The bar requires a completed license check, and Safeguard produces CycloneDX and SPDX SBOM attestations for the artifact, which carry license data for its components. How to read it: the license on the evidence page is the declared license of the artifact and what it contains. Whether that license is acceptable for your use is your policy decision, not a fact the page can supply.

Signature fields

The OSM docs describe an Attestations view for a Gold package that shows the attestation type, signer identity, build information and verification status. The ESSCM view adds signature type and signer identity per component.

How to read it: a "verified" status on a page is Safeguard telling you it checked. Your auditor will be more convinced if you checked too, with a tool you control, against a key you fetched yourself. That is the next section.

A reading checklist

When you open an evidence page, or prepare one for an auditor, run through these in order:

1. Does the digest on the page match the digest in my build?
2. Does the builder identity match one I have decided to trust, at the level I am claiming?
3. Does the source in the provenance point at the upstream project I expect?
4. When was the vulnerability state last checked, and is that recent enough for my policy?
5. Is the artifact still Gold today? If not, when did it lose the badge, and what did we do?
6. Did I verify the signature and provenance myself, and did I keep the output?

Gold Registry is not the same as "Gold Certified" on Gold Open Source

This is the most common source of confusion, and it has audit consequences.

Gold Open Source (GA) at gold.safeguard.sh is a free, no-login directory of public open source security data. Safeguard's docs define its "Gold Certified" label precisely: a package or image shows as Gold Certified when Gold knows of no vulnerabilities in the version it indexed and the package is not deprecated. The docs say that is the whole rule. They also say Gold Open Source does not rebuild, sign or attest packages, and does not host a registry.

So a Gold Certified label on gold.safeguard.sh describes what is publicly known about an upstream release. It carries no Safeguard signature or build provenance. It is a good research tool, not evidence of integrity or origin.

Gold Registry (GA) is different. Its artifacts are built by Safeguard, signed, carry provenance, and are served from registry.safeguard.sh behind a pull token. Only these have the per-artifact evidence described above.

If your audit file cites gold.safeguard.sh, label it as vulnerability research, not component provenance.

How to verify a Gold artifact's signature and SLSA provenance yourself

Safeguard's attestation and signing docs (GA) describe exactly how Gold artifacts are signed, and the method affects how you verify them.

How Safeguard signs

According to the docs:

• Every attestation Safeguard produces is in in-toto v1 format and signed with Safeguard's own ECDSA P-256 key, held in a cloud key management service. The private key does not leave it.
• Signatures are not written to a public transparency log. There is no Rekor entry to look up.
• You verify with cosign, the Sigstore project's signing tool, against Safeguard's published public key at https://registry.safeguard.sh/_gold/keys/cosign.pub.
• There is no Safeguard CLI command for verifying attestations yet, and no public attestation API yet. You use cosign directly, or the Attestation tab in the Safeguard app.

This deserves a sentence in your audit narrative because it differs from the keyless Sigstore model many readers assume when they see "Sigstore-signed". In keyless signing, a short-lived certificate tied to an identity signs the artifact and the event is recorded in a public transparency log, so anyone can audit that the signature happened. In key-based signing, trust rests on the publisher protecting a long-lived key. Safeguard's docs name this trade-off directly: without a public log, you rely on Safeguard to protect the key. The Sigstore docs support both modes; cosign accepts a key path, a key URL or a KMS URI for key-based verification.

The verification commands

These are the commands as Safeguard's docs show them. Replace the digest placeholder with the digest of the artifact you actually pulled.

KEY=https://registry.safeguard.sh/_gold/keys/cosign.pub

# Container images: signature and SLSA provenance
cosign verify --key "$KEY" --insecure-ignore-tlog registry.safeguard.sh/library/python@sha256:<digest>
cosign verify-attestation --key "$KEY" --insecure-ignore-tlog --type slsaprovenance registry.safeguard.sh/library/python@sha256:<digest>

# Files: a detached signature next to the file
cosign verify-blob --key "$KEY" --insecure-ignore-tlog --signature <file>.sig <file>

The flag that tells cosign to skip the transparency log check is needed precisely because there is no log entry. Without it, verification fails by design.

Two practical points. First, fetch the public key once, review it, and pin it in your own repository or secrets store rather than fetching it live on every build. When we requested the key URL on 23 October 2026 it returned a server error, which is exactly the kind of transient failure a pinned copy protects you from. Second, always verify by digest, never by tag. The @sha256: form in the commands above is deliberate.

What to check in the provenance once the signature passes

A valid signature only proves Safeguard's key signed this statement. SLSA's verification guidance lists what else a verifier should do, and it is worth following literally:

1. Check the builder. Confirm runDetails.builder.id is in your list of trusted builders, and that you trust that builder at the SLSA level you are claiming. SLSA describes this as a map from builder identity to the maximum level each builder is trusted to.
2. Check the subject. Confirm the digest in the statement's subject matches the artifact you are about to use.
3. Check the build type and parameters. Confirm buildType and externalParameters match what you expect for this package, for example the expected upstream source repository. Treat unknown parameters as a failure.
4. Record the result. Keep the cosign output, the date, the digest and the key fingerprint with your release records. That record, not a screenshot of a badge, is what answers 4(e)(x) and the form's Statement 3.

cosign verify-attestation returns the attestation payloads on success. Save that output; it is the provenance document an auditor may ask to see.

Check the vulnerability claim independently

The Gold bar's CVE claim is Safeguard's assessment. You can cross-check it with your own scan. The Safeguard CLI (GA) scans container images, including from a private registry, and writes results as JSON. The docs show the private registry form:

safeguard scan --image myregistry.azurecr.io/myapp:v1 \
  --registry-username "$REGISTRY_USER" \
  --registry-password "$REGISTRY_PASSWORD"

Point it at the Gold image reference you pulled, by digest. Results land under ./output by default, in files including vuln.json and license.json. The docs note that the scan exits 0 whenever it ran, whatever it found, and that gating on findings is done by policy gates in the platform. A raw scan may list medium or low findings, or findings that Safeguard assessed as not exploitable in the hardened build. That is consistent with the bar; record it rather than treating it as a contradiction.

Step by step: pull Gold artifacts without changing how developers install

Safeguard's offering describes a flow where you point your own package directory at Safeguard so hardened equivalents resolve without changing how developers install anything. Here is that flow, using only what Safeguard's docs and the registry itself show. Where the docs do not yet show a screen or setting, the step says so.

1. Find what you would replace. Open Open Source Manager › Inventory in the Safeguard app. OSM (GA) holds your open source package inventory. Sort or filter to the vulnerable packages you care about most.

2. Request Gold versions. On a single row, select Request Gold. Safeguard confirms with "Gold Request Submitted" and the row shows "Gold Requested". To request every vulnerable package at once, select Source Gold above the table, review the packages and risks, then Submit Request. Request Premium Gold works the same way. The docs say each request reaches the Safeguard team as a task, and that these buttons appear only if your plan includes them. If a hardened build has to be made from a fork because upstream has no fix, that path is fork and patch, which is early access.

3. Get a pull token. Gold Registry requires authentication. When we queried registry.safeguard.sh on 23 October 2026, it answered as a standard container registry (registry API version 2.0, with basic authentication) and replied that "a Safeguard Gold pull token is required". The docs do not yet publish how tokens are issued, so get yours from your Safeguard contact or administrator, and store it as a CI secret, never in a repository.

4. Point resolution at the registry, in your package manager or artifact proxy. The docs show the pattern for one public Safeguard npm package: a scoped registry line in .npmrc.

   # .npmrc
   @safeguard-sh:registry=https://registry.safeguard.sh/npm/
   

   That example is for Safeguard's own public gold-scan tool, which needs no token. For Gold artifacts, the exact registry paths and authentication for each ecosystem come with your token. Many teams put the registry behind the artifact proxy or package mirror they already run, so developer commands do not change at all. The docs do not describe a specific proxy configuration, so follow your proxy's own documentation for adding an upstream with credentials.

5. Pin by digest. For images, reference the image on registry.safeguard.sh by its @sha256: digest, as the docs' verification commands do. For packages, commit lockfiles that record integrity hashes. A tag or version range lets the artifact change under you, which breaks the link between your build and the evidence.

6. Verify in CI before use. Run the cosign commands from the previous section against the pinned key. Fail the job if verification fails. Save the output as a build artifact.

7. Enforce at deploy time. Safeguard's attestation docs describe a Kubernetes admission controller, part of policies, gates and guardrails (GA), that checks every pod admission for an SBOM, a valid signature, a SLSA level that meets policy (default Level 3) and a signer identity on an allow-list. Failed verification means admission is denied. This turns "we verified in CI" into "unverified artifacts cannot run".

8. Track what you shipped. Scan your projects so the SBOM records the Gold artifacts and their versions. In ESSCM, open a project, go to Explore SBOM, then the Attestation tab. It lists every component with its SCAL level (0 to 5, lower is better), attestation type, signature status and provenance. Filter to "Unattested Only" to see what is not covered.

9. Collect the evidence. For each release, keep the SBOM, the cosign outputs, the evidence page links for each Gold artifact, and the dates. The compliance and GRC suite (GA) is where Safeguard maps evidence to controls if you want it alongside the rest of your audit file.

Where your own code fits

Gold Registry covers components you consume. Your auditor will also ask about artifacts you build. Safeguard's docs show a CI step that produces signed attestations for your own builds:

- name: Attest build
  uses: safeguard/attest@v2
  with:
    artifact: ./dist/app.tar.gz
    predicates:
      - slsa-provenance
      - sbom-cyclonedx
      - vuln-scan

The docs say this step runs in GitHub Actions, GitLab CI, Azure DevOps, Buildkite, CircleCI, Jenkins and Safeguard's runner, and that the SLSA level you reach depends on your build environment. For example, the docs list GitHub reusable workflows or a Safeguard runner on a dedicated VM for L3. The docs also say there is no CLI command for signing container images and packages yet.

What happens when an artifact regresses and loses its badge

A regression usually means a new CVE was published that affects the artifact, and Safeguard assessed it as exploitable at critical or high severity. The artifact's bytes did not change. Its status did.

Per Safeguard's offering, the artifact loses its Gold badge. What follows is partly Safeguard's job and partly yours.

What the registry does. The badge comes off. A newer hardened build that meets the bar is the expected route back, either from an upstream fix or, where upstream has no fix and the issue is severe, through the fork and patch flow, which is early access. The offering does not promise a turnaround time, and you should not assume one.

What you do.

1. Find where it is. Use your SBOMs. In Safeguard, the platform shows which projects contain a given component and version, so you can list every service that pulled the regressed digest.
2. Decide on exposure. Reachability analysis (GA) helps rank whether your code calls the vulnerable path, so you work on the services that are actually exposed first.
3. Move to the next good build. When a newer Gold build exists, update the pin. Autonomous remediation (GA, ships off) can open the upgrade pull request if you have enabled it; out of the box every category is set to Manual.
4. Record it. Your audit file should show that you detected the regression, assessed it and acted within your policy timelines. CISA form Statement 4(b) asks for a policy or process to address discovered vulnerabilities before release. CRA Annex I Part II point 2 asks you to remediate without delay.
5. Consider VEX. If you conclude the regressed artifact is not exploitable in your product, a VEX statement is the standard way to say so. Safeguard supports CSAF and VEX upload (GA). See the companion post on ingesting and sharing VEX and CSAF in Safeguard.

Badge loss is the continuous check working. Badge loss with no change in your records is the finding an auditor will write up.

How Gold Registry relates to Gold Open Source and OSM

The three names overlap, so here is the division of labour in one place.

One detail on the free side: Safeguard's docs say the safeguard-sh/gold-scan-action GitHub Action is not yet on the GitHub Marketplace, and that the command-line form of the same check is available now from registry.safeguard.sh. The Gold block later in this post describes the Action as it will work once published.

The flow between them runs in one direction. You learn about a package on Gold Open Source or in OSM. You request a Gold version from OSM. You pull the hardened build from Gold Registry. You verify it with cosign and record the evidence. If there is no Gold build and no upstream fix, the early access fork and patch flow is the route Safeguard offers.

The companion post on Gold Open Source in your workflow covers the free side in depth. The post on fork and patch when upstream has no fix covers the early access side and its limits. For background on how hardened builds are produced, see how the Gold Registry works, the Gold build pipeline, starting clean with Gold Registry and the Gold Registry expansion. For how attestations and SCAL scores work across your own projects, see attestation and provenance in Safeguard.

A worked audit narrative

Here is how the pieces combine into language an auditor can test. Adapt the specifics to your own records.

For this release of our payments service, the base container image and its npm dependencies were pulled from Gold Registry by digest. For each, we verified the signature and SLSA provenance in CI with cosign against Safeguard's published public key, which we pinned in our repository after review. The builder identity matched our trusted builder list at SLSA Build L3. We retained the verification output, the CycloneDX SBOM for the release, and the evidence page link and digest for each Gold artifact. When two packages later lost Gold status, we identified affected services from our SBOMs, assessed one as not reachable and issued a VEX statement, and upgraded the other to a newer Gold build within our policy window.

That paragraph is a template, not a real customer record. The structure is the point. Each sentence maps to a requirement: digest and pinning to integrity, cosign output to provenance, SBOM to Annex I Part II(1) and Statement 3, the regression handling to Statement 4 and Annex I Part II(2).

Requirement, what Safeguard does, what you still own

What Safeguard does not do

Be precise with an auditor about these limits. Overclaiming here is what turns a clean audit into a finding.

1. Not every package or image has a Gold build. Gold Registry covers a curated set of hardened components, not every version of every open source project. Do not quote an artifact count in audit material; check the specific artifacts you use. For anything not in the registry, your evidence comes from your own SBOMs, scans and provenance checks. Requests for new Gold versions go through OSM, and the fork and patch route is early access with limited package coverage.

2. The badge is not a warranty. The Gold bar is a continuous check against known vulnerability data at a point in time. It cannot cover vulnerabilities nobody has disclosed yet. It does not transfer your legal obligations under the CRA, M-22-18 or any contract to Safeguard.

3. Gold Registry does not cover your own code. First-party code, your build pipeline and how you configure and deploy components are outside it. Safeguard's other GA capabilities (SCA, SBOM, attestation of your own builds, policy gates) help there, but they are separate evidence you have to produce.

4. It does not cover operating system kernels or vendor runtimes you do not build. A hardened container image does not change the host kernel it runs on, a managed database service, or a vendor appliance. Those fixes come from their vendors or distributions, as the Gold block below also notes.

5. There is no public transparency log for Gold signatures. Per Safeguard's docs, signing uses Safeguard's own key rather than keyless signing with a public log. You rely on Safeguard protecting that key. If your policy requires transparency log inclusion for every signature you trust, Gold signatures will not meet it today.

6. There is no Safeguard CLI command or public API for verifying attestations yet. The docs say so directly. Use cosign, or the Attestation tab in the app. Do not plan an audit workflow around an attestation API.

7. Safeguard's docs disagree on the minimum SLSA level for Gold. The offering says L3 or higher; one OSM docs page says Level 2. Read the level from each artifact's provenance and your own builder trust list, not from a summary.

8. It does not fill in the attestation form for you. The CISA form is signed by your CEO or a designee and covers your practices. Safeguard can supply evidence that supports Statements 2 to 4 for components; the attestation itself is yours.

Common mistakes

Citing a Gold Open Source page as provenance evidence. "Gold Certified" on gold.safeguard.sh means no known vulnerabilities in the indexed upstream version and not deprecated. It is not a Safeguard build or signature. Use it as research only.

Verifying by tag instead of digest. If your deployment references python:3.12 and you verified python@sha256:... last month, you cannot prove they are the same bytes. Pin and verify by digest.

Trusting the page's "verified" status without checking yourself. A status shown by the publisher is a claim. Your auditor wants your verification output, made with a key you pinned.

Fetching the public key live in every build. It creates a dependency on a network call at build time and lets a key swap pass silently. Pin it, record its fingerprint, and review any change.

Writing "zero CVEs" in audit material. The bar is zero exploitable critical or high CVEs. A critical CVE can be listed against a package and still be assessed as not exploitable in the hardened build, and medium and low findings can still appear in an independent scan. Use the precise wording, and say it plainly in your audit narrative.

Assuming keyless Sigstore semantics. Safeguard's docs describe Gold signing as key-based, verified with the Sigstore project's cosign tool, with no transparency log. A keyless, identity-based verification command will fail.

FAQ

What is a Gold Registry evidence page?

It is a public page for one hardened artifact in Safeguard's Gold Registry (GA) that records the artifact's state against the Gold bar: known exploitable critical and high CVEs, license check, SLSA provenance and signature. It is designed to be shared with an auditor. Treat every claim on it as applying to one specific digest.

Is Gold Registry the same as Gold Open Source?

No. Gold Open Source (GA) at gold.safeguard.sh is a free directory of public security data about upstream releases, and its "Gold Certified" label means no known vulnerabilities and not deprecated. Gold Registry (GA) at registry.safeguard.sh serves artifacts that Safeguard built, signed and attested, behind a pull token.

How do I verify a Gold artifact's signature with cosign?

Use the commands in Safeguard's attestation and signing docs: cosign verify with Safeguard's published public key and the option that skips the transparency log, against the image reference by digest. Use cosign verify-attestation with the SLSA provenance type to check provenance, and cosign verify-blob for files with detached signatures. Pin the public key rather than fetching it live.

Why do the cosign commands skip the transparency log?

Safeguard's docs state that Gold signatures are made with Safeguard's own key held in a cloud key management service and are not written to a public transparency log. There is no log entry to check, so verification must skip that step. The trade-off is that you rely on Safeguard to protect the signing key.

What SLSA level do Gold artifacts meet?

Safeguard's offering states SLSA L3 or higher. One OSM docs page states a Level 2 minimum. Read the builder identity in each artifact's provenance and compare it with your own list of builders you trust at L3. Put the level you verified in your audit file, not a summary figure.

Does using Gold Registry satisfy EO 14028 or the CISA attestation form?

Not on its own. It gives you strong evidence for third-party components you pull from it: provenance, integrity and vulnerability state. EO 14028 and the CISA form also cover your own development environment, your own code, your vulnerability disclosure program and a signed attestation from your company. Those remain yours.

Does Gold Registry help with the EU Cyber Resilience Act?

It supports the due diligence Article 13(5) requires for third-party components and gives you per-component records to keep with your SBOM under Annex I Part II(1). The CRA does not require SLSA or any specific signing scheme, and the obligations, including the main ones that apply from 11 December 2027, stay with the manufacturer.

What happens if a Gold artifact gets a new critical CVE?

If the new CVE is assessed as exploitable at critical or high severity, the artifact loses its Gold badge. Find where you use that digest from your SBOMs, assess reachability, move to a newer Gold build when one exists, and record what you did. Fork and patch for packages with no upstream fix is early access.

Can I request a Gold version of a package that is not in the registry?

Yes, if your plan includes it. In Open Source Manager › Inventory, select Request Gold on a package, or Source Gold to request every vulnerable package at once. Each request reaches the Safeguard team as a task. Building a hardened fork where upstream has no fix is early access, so ask which packages it covers.

From evidence to fixes

The evidence page is the last step of a longer chain: knowing a component is vulnerable, getting to a fixed or hardened version, and proving you did. The block below is Safeguard's standard description of that chain, including the full published Gold bar and the early access status of fork and patch.

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, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. 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. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs 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. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

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

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature 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, compatibility tested build of a specific package. This fork and patch flow is in early access today, so 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.

See how Safeguard would help

The Gold flow ends in two places you work in every day: the terminal and your CI. These demos show the Safeguard CLI and local runner that you would use to scan, check and fix what you pull.

This demo is a real CLI session. You install the CLI, run safeguard to open the interactive terminal and ask it to fix the lodash CVE in a repository. It reads the finding and the advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. It finishes with /permissions, /model and /scan ., the same scan you would run after moving dependencies to Gold builds to confirm what is now in your project.

Click through it at your own pace, or open it full screen.

This demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. It is the route for teams that want scans of images and dependencies, including hardened ones pulled from the registry, to run where the code lives, with only results sent to the platform.

Click through it at your own pace, or open it full screen.

To try it on your own projects, download Safeguard at https://safeguard.sh/download and read the docs at https://docs.safeguard.sh/docs .

Quick check

Sources

• Executive Order 14028, Improving the Nation's Cybersecurity, Federal Register text (govinfo)
• CISA, Secure Software Development Attestation Form
• CISA, Secure Software Development Attestation Common Form (PDF)
• OMB Memorandum M-22-18, Enhancing the Security of the Software Supply Chain through Secure Software Development Practices (PDF)
• NIST SP 800-218, Secure Software Development Framework version 1.1
• NTIA, The Minimum Elements for a Software Bill of Materials
• Regulation (EU) 2024/2847, Cyber Resilience Act, official text (Publications Office of the EU)
• European Commission, Cyber Resilience Act policy page
• SLSA v1.0, Security levels
• SLSA v1.0, Verifying artifacts
• SLSA v1.0, Provenance
• Sigstore docs, Verifying signatures with cosign
• Sigstore docs, Verifying in-toto attestations
• in-toto Attestation Framework
• in-toto Attestation Framework, Statement layer specification v1
• Safeguard Docs, Gold
• Safeguard Docs, Gold Open Source
• Safeguard Docs, Attestation and Signing
• Safeguard Docs, Open Source Manager
• Safeguard Docs, OSM Attestation
• Safeguard Docs, OSM User Guide
• Safeguard Docs, ESSCM Attestation
• Safeguard Docs, EO 14028 Compliance Checks
• Safeguard Docs, CLI usage
• Safeguard Gold Open Source
• Safeguard Gold Registry

Last reviewed: 24 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.