Use Gold Open Source in Your Workflow: Free API, Badges, RSS, CI Gate

Gold Open Source (GA) is Safeguard's free, no-login directory at gold.safeguard.sh where you can look up a package or a CVE and see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version before you install anything. You can use the same data from a free read-only JSON API, live README badges and RSS threat feeds, and a CI gate called Gold Scan can fail a build on actively exploited dependencies. One status note matters before you plan around it: on 24 October 2026 the GitHub Action is documented but not yet published on the Marketplace, while the command-line form is available from Safeguard's own registry.

This post walks through each of those surfaces, what the standards say about choosing components in the first place, the exact commands Safeguard's docs show, and the honest limits of a free lookup service.

Key takeaways

• Gold Open Source (GA) is free and needs no login. It builds on public sources such as NVD, OSV.dev, GitHub Security Advisories, CISA KEV, FIRST EPSS and OpenSSF Scorecard.
• CVE pages have an "Am I affected?" check; package pages with known vulnerabilities show a recommended safe version.
• The read API is GET only, JSON, keyless and provided as-is. It is rate limited; cache responses.
• README badges use /badge/ECOSYSTEM/NAME. RSS feeds cover new KEV entries and trending threats.
• Gold Scan gates CI with fail-on kev, vuln or none. The GitHub Action is documented but not yet on the Marketplace; the CLI is published on registry.safeguard.sh. It reads manifests, not lockfiles, and fails open. Treat it as a tripwire.
• Full transitive SCA (GA), reachability analysis (GA), policies and gates (GA) and autonomous remediation (GA, ships switched off) live in the Safeguard platform. Gold Registry (GA) is the separate hardened registry. Fork and patch is early access.
• NIST SSDF PW.4.4 suggests building automatic detection of known vulnerabilities into your toolchain. A free lookup and a CI tripwire are a first step toward that, not the whole of it.

Why look up a package before you install it

Most dependency risk enters a codebase when someone types an install command. After that, the package sits in a lockfile and gets harder to remove as code starts to depend on it. A thirty second lookup at the point of choice is about as cheap as a security control gets.

What NIST SSDF PW.4 asks of you

NIST SP 800-218, the Secure Software Development Framework version 1.1 (February 2022), has a practice called PW.4: "Reuse Existing, Well-Secured Software When Feasible Instead of Duplicating Functionality." The practice text says the aim is to lower cost and reduce the chance of new vulnerabilities by reusing modules "that have already had their security posture checked."

Two tasks under PW.4 bear directly on choosing open source components:

• PW.4.1 asks you to acquire and maintain well-secured components from commercial, open source and other third-party developers. Its notional examples include reviewing components in the context of their expected use, obtaining provenance information such as an SBOM or composition analysis, setting up repositories of sanctioned and vetted open source components, and keeping a list of approved components and versions.
• PW.4.4 asks you to verify that acquired components comply with your own requirements "throughout their life cycles." Its examples are concrete: regularly check for publicly known vulnerabilities that have not yet been fixed, build automatic detection of known vulnerabilities into the toolchain, make sure each component is still maintained and not end of life, plan for components that are no longer maintained, and confirm integrity through signatures or other mechanisms.

Notice the phrase "throughout their life cycles." SSDF does not treat component review as a gate you pass once. A package that was clean when you added it can pick up a CVE next month, and a CVE that looked theoretical can land on CISA's KEV list. That is why this post covers both the lookup before install and the CI check that keeps running afterwards.

SSDF PW.4.4 also maps to EO 14028 section 4e items and to NIST SP 800-53 controls SA-9, SR-3 and SR-4 in the framework's own reference column, which is one reason the practice shows up in federal software attestation work.

What the OpenSSF Concise Guide adds

The OpenSSF Best Practices Working Group publishes a "Concise Guide for Evaluating Open Source Software" (the version we read is dated 28 March 2025). It is a checklist a developer can run before adopting a dependency. A few of its rules map neatly onto data you can see in a lookup service:

• Consider necessity. Every new dependency increases attack surface, including through its own transitive dependencies.
• Activity level and release recency. The guide suggests confirming significant activity and a release within the previous 12 months.
• Security scores. It points to OpenSSF Scorecard results and known vulnerabilities as inputs.
• Vulnerability status. It asks you to confirm the current version is free of known important vulnerabilities, "especially long-known ones."
• License clarity. It asks you to confirm that every component has a license consistent with your intended use.

The guide covers far more than a lookup can answer, including maintainer diversity, secure defaults, vulnerability reporting and hands-on code review. A directory tells you what is publicly known, nothing more.

Requirement versus what Gold Open Source shows versus what you still own

The table makes the shape of the job clear. Gold Open Source is an information service. It narrows the question; it does not close it.

What Gold Open Source shows for a CVE or a package

Safeguard's docs describe Gold Open Source as a "free, no-login public directory of open-source software and what is publicly known about its security." It spans packages across 20+ ecosystems (npm, PyPI, Maven, Go, Cargo and more), container images, a CVE database, a CWE index mapped to the OWASP Top 10, MITRE ATT&CK matrices, AI models from the Hugging Face Hub, MCP servers from the official registry, agent skills and chip manufacturers. This post concentrates on packages and CVEs, because those are what developers check before installing.

On a CVE page

A CVE page brings together the fields you need to decide how urgent something is:

• Severity and CVSS. The base score and vector string, as published.
• Affected and fixed versions. The version ranges from the advisory, and whether a fix exists yet.
• EPSS score and percentile. FIRST describes EPSS as a model that "estimates the probability that a published CVE will be exploited in the wild in the next 30 days." It publishes a probability between 0 and 1, plus a percentile, every day for every CVE.
• CISA KEV status. Whether the CVE is in CISA's Known Exploited Vulnerabilities catalog.
• CWE. The weakness class, which links into the CWE index.
• Remediation guidance. Upgrade advice where a fix exists, and the "Am I affected?" checker described below.

When we called the API for a recent Moby advisory on 23 October 2026, the JSON included a CVSS 3.1 vector, the affected version string, an empty fixed version with a status of not fixed, a CWE identifier, an EPSS score and percentile, and a kev field. That is a useful check of how the data looks in practice: a CVE with no fix yet says so plainly, which is exactly the case where you need a different plan (see the Gold block further down).

On a package page

A package page answers "should I take this dependency, and at which version?" It shows:

• Vulnerability count and the advisories behind it. Each with severity and a link to the CVE page.
• License, version and release details. Including the published date and whether the package is deprecated.
• Download counts. The docs mention live download counts on package detail.
• Package health. An OpenSSF Scorecard card with individual checks such as Maintained, Code-Review, Pinned-Dependencies, Security-Policy and Dangerous-Workflow, plus an overall score.
• Recommended safe version. For packages with known vulnerabilities, the docs describe it as "the lowest version that clears the most advisories," with a copy-ready upgrade command for your ecosystem.

The safe version rule is worth reading twice. It is the lowest version that clears the most advisories, not the latest release. That choice keeps upgrade jumps small, which is usually what you want during an incident. It also means the recommended version may still carry an advisory that no release has fixed yet. Read the advisory list, not just the suggestion.

What "Gold Certified" means on Gold Open Source

Safeguard's docs give a precise definition, and it is narrower than you might guess from the word "certified." A component shows as Gold Certified when Gold knows of no vulnerabilities in the version it indexed and the component is not deprecated. The docs then say plainly that Gold "does not rebuild, sign or attest components" on Gold Open Source; the label describes what is publicly known about the upstream release.

That is different from Gold Registry (GA), the separate product at registry.safeguard.sh, where artifacts are rebuilt and held to a continuous bar with SLSA provenance, Sigstore signatures and evidence pages. If you need something you can hand to an auditor, that is the registry's job, and our companion post on reading a Gold Registry evidence page covers it. On Gold Open Source, "Gold Certified" means "no known vulnerabilities in the indexed version and not deprecated," and nothing more.

How the "Am I affected?" checker works

The "Am I affected?" check sits on every CVE page. You enter the version you are running, and Gold compares it with the advisory's affected and fixed versions to give an immediate verdict. There is no account, no upload and no scan of your project; it is a version comparison against published ranges.

That simplicity is the point. During an incident, the first question from every team is "do we run an affected version?" and the first answer usually comes from someone typing a version number they found in a lockfile. The checker turns that into a consistent answer.

It is worth knowing how version ranges are expressed upstream, because that is what the checker reads. The OSV schema, maintained by the OpenSSF, records affected versions as a list of ranges with introduced, fixed and last_affected events, plus explicit version lists. A range with an introduced event and no fixed event means no release has fixed it yet. When the advisory data is incomplete or wrong, any checker built on it inherits the problem, so treat a "not affected" verdict as strong evidence, not proof.

Practical tips:

1. Use the exact resolved version from your lockfile (package-lock.json, poetry.lock, Cargo.lock and so on), not the range in your manifest.
2. Check each copy. Monorepos and container images often carry several versions of the same library.
3. Read the fixed version list. An older release line is fine if that line has a patched release.
4. Record what you checked. The version and advisory you compared against are the start of a VEX statement later.

The free dependency scan page

For more than one version at a time, Gold Open Source has a "Scan your dependencies" page at gold.safeguard.sh/scan. You paste or upload a dependency manifest, or a CycloneDX or SPDX SBOM, and the page shows which packages carry known vulnerabilities in the Gold corpus. The page says the file is "parsed in your browser and never sent to a server," and that it checks up to 100 dependencies per run.

This is the right tool when you want a quick look at a small project or an SBOM a supplier sent you, and you do not want to install anything. For larger dependency trees, or anything you need to repeat every day, use the CLI gate or the platform.

How to call the free read-only JSON API

The Developers page at gold.safeguard.sh/developers documents the API. In its own words, every endpoint is GET, returns JSON, is rooted at https://gold.safeguard.sh, and is "read-only and free." There is no API key and no account.

Endpoints

The docs give one example call:

curl https://gold.safeguard.sh/api/packages/lodash

The same shape works for a CVE:

curl https://gold.safeguard.sh/api/vulnerabilities/CVE-2026-34040

What a response looks like

Responses wrap the payload in a success flag and a data object. When we called the package endpoint for lodash on 23 October 2026, the data object included the package name, ecosystem, indexed version, vulnerability count and identifiers, a status, weekly downloads, deprecation flag, homepage and repository, and a health block holding OpenSSF Scorecard checks with a score, a grade and the date of the Scorecard run. The CVE endpoint returned fields such as cvss, cvssVector, affectedVersions, fixedVersions, status, epssScore, epssPercentile, cwe and kev.

A not-found CVE returns HTTP 404 with a short JSON error. Code that calls the API should check both the HTTP status and the success flag.

Limits you should design around

The Developers page is short on formal limits, so here is what it says and what we observed, kept separate:

• Stated by Safeguard. The API is "provided as-is for read-only use." Data is aggregated from public sources listed on the Credits page. You should "cache badge/API responses rather than requesting them on every page load."
• Observed on 23 October 2026. Responses included an x-ratelimit-remaining header, so the API is rate limited. Safeguard does not publish the limit, so do not hard code one. The Gold Scan source code describes the public API as throttling aggressively and retries on HTTP 429 and 5xx with a linear backoff, which is a sensible pattern to copy.
• Observed on 23 October 2026. One vulnerability search call returned an error payload rather than results, and a keyword search returned no rows. Detail endpoints worked. Build for occasional failures: retry with backoff, then degrade gracefully.
• Indexed version, not your version. The package detail endpoint describes the version Gold indexed, which may be the latest release, not the one you run. A zero vulnerability count for the indexed version says nothing about an older version pinned in your lockfile. For your own version, use the CVE's affected and fixed ranges.
• Name in the path. The package detail path takes a name; the search endpoint is where you filter by ecosystem. Names that exist in more than one ecosystem are a reason to use search with the ecosystem filter when it matters.
• Coverage. The corpus is large but not everything. A package or CVE that is not in Gold returns not found, which means "unknown," not "safe."

This public read API is separate from the Safeguard platform API. Several platform docs pages carry a banner saying the /v1 REST endpoints under api.safeguard.sh are not yet available, and nothing in this post uses them.

README badges and RSS threat feeds

README badges

The Developers page offers a live status badge you can embed in any README or docs page. The Markdown it documents is:

[![Safeguard Gold](https://gold.safeguard.sh/badge/npm/lodash)](https://gold.safeguard.sh/package/npm/lodash)

The pattern is /badge/ECOSYSTEM/NAME, for example /badge/pypi/requests or /badge/npm/@types/node. The badge is an SVG and "updates automatically as a package's security status changes."

For a maintainer, a badge on your own package tells downstream users you watch its public security status and gives them one click to the advisories. For a team, badges in an internal service catalog can show the status of the few libraries everyone depends on. Many README renderers cache images through a proxy, so a badge can lag the live page; the page behind the link is the source of truth.

A badge reflects the package as Gold indexed it, not the version a particular consumer pins. Treat it as a public signal, not a compliance artifact.

RSS threat feeds

Gold publishes RSS 2.0 feeds you can subscribe to in any reader, chat integration or automation tool:

• Actively exploited (CISA KEV): https://gold.safeguard.sh/feed/kev.xml. Its channel description reads "CVEs confirmed exploited in the wild, from the CISA Known Exploited Vulnerabilities catalog." Each item links to the CVE page on Gold.
• Trending threats: https://gold.safeguard.sh/feed/trending.xml, the feed behind the Trending Threats page, which leads with the newest KEV additions.

Both feeds set a ttl of 60. In the RSS 2.0 specification, ttl is "a number of minutes that indicates how long a channel can be cached before refreshing from the source." A reader that respects it will poll at most hourly, which is the right cadence for this kind of feed.

Why KEV is the feed to watch first

CISA describes the KEV catalog as "the authoritative source of vulnerabilities that have been exploited in the wild." Its criteria for adding an entry are an assigned CVE ID, reliable evidence of active exploitation, and clear remediation guidance. CISA's page notes that exploitability alone is not a criterion; exploitation is.

The KEV page also records a recent change: CISA issued Binding Operational Directive 26-04, "Prioritizing Security Updates Based on Risk," on 10 June 2026, and it carries forward the KEV criteria from BOD 22-01. Federal civilian agencies must remediate KEV entries within prescribed timeframes under BOD 26-04. Everyone else is not bound by it, but CISA "strongly recommends" making immediate action on KEV entries part of every vulnerability management plan.

A KEV feed in a team channel is a low-noise way to follow that advice: every entry is a confirmed exploitation.

A routine that works

For a deeper look at how EPSS and KEV feed prioritisation inside the platform, see our companion post on prioritising vulnerabilities with reachability, EPSS and KEV.

Step by step: add the Gold scan to your CI

Gold Scan is a small dependency gate that runs in CI and fails the build when a dependency is actively exploited (KEV) or known vulnerable. It needs no account and no API key. In the docs' words, "your source never leaves the runner (only dependency names are sent to the public read API)."

Status first: the Action and the CLI

The two forms are at different stages, and Safeguard's own pages say so:

• GitHub Action. The Gold Open Source docs say safeguard-sh/gold-scan-action "is not on the GitHub Marketplace yet," and that the workflow they show "shows how it will work once it ships." We checked on 23 October 2026: the repository URL returned 404.
• CLI. The same docs say the command-line form "is available now from registry.safeguard.sh" as @safeguard-sh/gold-scan. The registry's package metadata shows version 1.0.0 published on 17 October 2026.
• Developers page. The Gold Developers page still describes the Action and CLI as "coming soon." The docs page is the newer of the two and gives the install command, which is what the Developers page says to wait for.

Two safety notes from the docs are worth repeating. @safeguard-sh is Safeguard's own scope on its own registry. Never install @safeguard/gold-scan from a public registry, because that scope belongs to someone else on npmjs.com. And do not install any action or package that claims to be Gold Scan from anywhere other than the source the docs name.

The workflow the docs show, for when the Action ships

This is the workflow from the Gold Open Source docs, saved as .github/workflows/gold-scan.yml:

name: Gold Scan
on: [push, pull_request]
jobs:
  gold-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: safeguard-sh/gold-scan-action@v1
        with:
          fail-on: kev # kev = actively exploited only | vuln = any known CVE | none = report only

In GitHub's workflow syntax, uses "selects an action to run as part of a step in your job," from the same repository, a public repository or a container image. Until safeguard-sh/gold-scan-action exists as a public repository, this step will fail to resolve. Keep it out of your required checks until the docs say it has shipped.

The CLI form, which works today

These are the commands exactly as the docs show them. First, point the scope at Safeguard's registry in .npmrc:

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

npx @safeguard-sh/gold-scan            # scan the current directory (fail-on=kev)
npx @safeguard-sh/gold-scan . --fail-on vuln

Or, without an .npmrc, name the registry on the command line:

npx --registry https://registry.safeguard.sh/npm/ @safeguard-sh/gold-scan .

The docs say this form runs in pre-commit hooks, GitLab CI, Jenkins or a local run. It needs Node 18 or later.

Step by step

1. Pick your threshold. Start with fail-on kev. It fails only when a dependency carries a CVE in the CISA KEV catalog, which keeps noise low on day one. The package README calls kev "low-noise" and vuln "strict."

2. Add the registry scope. Commit the .npmrc line above, or use the form that names the registry on the command line so nothing else in your npm configuration changes.

3. Run it locally once. Run npx @safeguard-sh/gold-scan from the repository root. It walks the directory for supported manifests, prints which manifests it found, checks each unique dependency against Gold and prints a pass or fail line. Fix or note anything it reports before you wire it into CI.

4. Add it to your pipeline. In GitHub Actions today, that means a normal run: step after checkout that calls the documented npx command. Here is our sketch, built from the documented CLI command and GitHub's workflow syntax; it is not a Safeguard docs example:

   name: Gold Scan (CLI)
   on: [push, pull_request]
   jobs:
     gold-scan:
       runs-on: ubuntu-latest
       steps:
         - uses: actions/checkout@v4
         - uses: actions/setup-node@v4
           with:
             node-version: 20
         - run: npx --registry https://registry.safeguard.sh/npm/ @safeguard-sh/gold-scan . --fail-on kev
   

   In GitLab CI or Jenkins, run the same npx command in a job with Node 18 or later.

5. Make it a required check. On a pull request the job shows up as a status check. Making it required in your branch protection settings turns it into a gate, not a suggestion.

6. Watch a few runs, then tighten. After a week or two of clean kev runs, consider fail-on vuln on your main branch or on one service. The first argument is the directory to scan, so you can point a run at a subdirectory.

7. Decide what happens on a fail. A KEV failure should page someone or open a ticket the same day. A vuln failure on a library with no fix needs an exception process and an owner, not a silent override.

8. Pin what you run. GitHub's security hardening guide recommends pinning actions to a full-length commit SHA. When the Gold Action ships, pin it that way. For the CLI, consider pinning the package version (@safeguard-sh/gold-scan@1.0.0) so an update does not change your gate without review.

The three fail-on modes

What the gate actually does

We read the source of version 1.0.0 as published on registry.safeguard.sh, because the details matter for how far you can trust a pass:

• Manifests it reads. package.json, requirements.txt, Cargo.toml, go.mod, Gemfile and composer.json, discovered recursively. It skips node_modules, vendor, dist and other build or vendor directories.
• What it does not read. Lockfiles. It sees the dependencies you declare, not the full resolved tree. Transitive dependencies are out of scope.
• How it looks things up. For each unique dependency, it calls /api/packages/NAME. If the package has vulnerabilities, it fetches the advisory list and cross-references it against the KEV catalog.
• Versions. In 1.0.0 the lookup is by package name, and the count comes from the record Gold indexed. Your declared version is parsed but not compared against affected ranges. So a gate failure means "this package has known vulnerabilities in Gold's record," and you should then check your exact version with "Am I affected?" A pass means Gold's record for that name had no qualifying vulnerabilities at that moment.
• Not in Gold. A dependency that Gold does not know is reported as "Not in Gold," which the README describes as "unknown, not necessarily unsafe."
• Size cap. The Action input max-deps defaults to 750 unique dependencies; the scan warns and truncates above that.
• Fail open. If the API is unreachable or keeps rate limiting after retries, the scan exits 0. The docs put it as "a Gold outage never blocks your build." That is the right default for a free service, but it means a pass on a bad network day is not evidence.
• Output. It writes a job summary to the run and sets exit code 0 for pass and 1 for a failed gate.

That makes Gold Scan a tripwire: cheap, fast, low noise, and good at catching a declared dependency with an actively exploited CVE. It is not a version-aware scan of your full dependency tree.

Where the data comes from, and what Safeguard adds

Gold's Credits page lists its sources and says the original records belong to their publishers. For the package and CVE views in this post, the important ones are:

From their own documentation: EPSS is maintained by a FIRST special interest group and published daily and freely; it is a probability, not a severity. OSV records describe affected packages by ecosystem, name and version ranges, which is what makes automated "am I affected" logic possible. OpenSSF Scorecard runs automated checks on a repository and is a hygiene signal about the project, not a verdict on a specific version. CISA curates KEV against its three criteria.

What Safeguard adds, per its Credits page, is "verification, scoring, and Gold status" as "our own analysis layered on top." In practice, for the surfaces in this post, that means:

• Normalisation. Different sources describe the same vulnerability in different shapes. Gold presents them as one record per CVE and one record per package.
• Joins. KEV status, EPSS and CWE appear on the same page as affected and fixed versions, so you do not open four tabs.
• The recommended safe version. A calculation over the advisories for a package.
• The Gold Certified label. Using the narrow rule above.
• Delivery. API, badges, feeds, the browser scan page, the Gold Chrome extension and the CI gate.

Freshness

The homepage calls the index "live" and "continuously updated," and in the KEV feed we fetched on 23 October the newest items were KEV additions dated 20 October. But Gold cannot be fresher than its sources. NVD enrichment can lag publication, OSV and GHSA records are updated as maintainers and reviewers work through them, and EPSS updates daily. If you are tracking a vulnerability disclosed this morning, read the vendor or project advisory directly and use Gold as the second check.

What Gold Open Source is not

A free tool that looks authoritative can lull a team into thinking a job is done, so plainly:

• Not a scan of your repository. Lookups and badges describe public packages, and Gold Scan reads declared dependencies. Neither resolves your lockfile or transitive tree; software composition analysis (GA) in the platform does.
• Not version aware everywhere. "Am I affected?" is. The package endpoint, badges and the 1.0.0 gate describe the record Gold indexed.
• Not a guarantee that a package is safe. Unknown vulnerabilities exist, and upstream data can be late or wrong.
• Not reachability analysis. Gold does not know whether your code calls the vulnerable function. The platform's reachability analysis (GA) does; Safeguard's docs mark some language support as Preview.
• Not your approval process. SSDF PW.4.1 expects your organisation to keep its own approved component list. Gold can inform it, not own it.

When to move from Gold Open Source to the platform

Gold Open Source is the free front door. The Safeguard platform adds:

• Software composition analysis and deep transitive dependency scanning (GA), plus vulnerability management with EPSS and KEV enrichment (GA), so you can see which projects contain a given component and version.
• Reachability analysis and prioritisation (GA). Safeguard's product materials put the reduction in findings at roughly 60 to 80%; that is Safeguard's stated figure, not a guaranteed result.
• Policies, gates and guardrails (GA), including plain English policy creation, so "no KEV in production" is enforced at build, CI and release.
• Autonomous remediation (GA, ships switched off), where Griffin opens tested fix pull requests. Every category is set to Manual until you turn it on.
• The Safeguard CLI, local runner, IDE extensions and MCP server (all GA).

The free entry tier of the Portal (GA) means free signup, one existing repository plus one open source repository from GitHub, GitLab or Bitbucket, one project per month, SCA only. Our companion post on plain English security policies and release gates shows how a gate like fail-on kev becomes an organisation-wide policy.

What Safeguard does not do

Specific limits, so you can plan around them:

1. The Gold Scan GitHub Action is not published yet. As of 24 October 2026, safeguard-sh/gold-scan-action is documented but not on the GitHub Marketplace. Use the CLI from registry.safeguard.sh until the docs say the Action has shipped.
2. Gold Scan does not read lockfiles or transitive dependencies, and in version 1.0.0 it does not compare your declared version against affected ranges. A pass does not mean your resolved tree is clean.
3. Gold Scan fails open. If the public API is unreachable or rate limiting persists after retries, the build passes. If you need a gate that cannot be skipped by a network fault, use platform policies and gates (GA) instead.
4. The free API has no published rate limit or service level. It is provided as-is. Responses carry a rate limit header, and Safeguard asks you to cache. Do not put it in a hot path of a production service.
5. Gold Open Source does not rebuild, sign or attest components. Its "Gold Certified" label is a statement about public knowledge of the upstream release. For signed, provenance-backed artifacts, look at Gold Registry (GA).
6. Gold cannot be fresher than NVD, OSV, GHSA, CISA KEV and FIRST EPSS. A same-day disclosure may not be in the index yet. Read the upstream advisory.
7. Coverage is broad, not total. A package or CVE that is not in Gold returns not found, which means unknown. It does not mean safe.
8. Nothing here replaces your judgment about context. Whether a vulnerable code path is reachable, whether a mitigation applies, and when you patch are decisions your team owns, informed by data but not made by it.

Common mistakes

• Checking the manifest range instead of the resolved version. ^1.2.0 is a range. The answer to "am I affected?" depends on what is in your lockfile.
• Reading "not in Gold" as "safe." It means Gold has no record. Look the package up elsewhere, or treat it as unvetted.
• Starting with fail-on vuln everywhere. Teams that turn on the strict mode on day one usually end up disabling the check. Start with kev, then tighten where you can keep up.
• Treating a green CI check as evidence for an audit. A fail-open tripwire on declared dependencies is useful engineering hygiene. It is not the "automatic detection of known vulnerabilities" across all components that an assessor would expect from SSDF PW.4.4 on its own.
• Installing look-alike packages. The docs warn that @safeguard/gold-scan on npmjs.com is not Safeguard's. Use the @safeguard-sh scope from registry.safeguard.sh.
• Following only CVSS. A 9.8 with a tiny EPSS and no KEV entry may matter less this week than a 7.5 on the KEV list. Use all three signals together.
• Taking the recommended safe version as final. It is the lowest version that clears the most advisories. Check whether any advisory remains open on that version and whether the upgrade crosses a major version.

FAQ

Is Gold Open Source really free, and do I need an account?

Yes, it is free, and no account is needed. The website, read API, badges, RSS feeds and browser scan page need no login or API key, and the CLI gate on registry.safeguard.sh needs no token.

How do I check if my version of a package is affected by a CVE?

Open the CVE page on gold.safeguard.sh and use "Am I affected?" with the exact version from your lockfile. For many versions at once, paste a manifest or SBOM into gold.safeguard.sh/scan.

What are the Gold Open Source API endpoints?

All are GET under https://gold.safeguard.sh: package search and detail, a package's vulnerabilities, package statistics, CVE search, and CVE detail with CVSS, EPSS, KEV status and affected and fixed versions.

Does the Gold Open Source API have a rate limit?

Yes. Responses carry an x-ratelimit-remaining header, but the limit is not published. Cache responses and retry on HTTP 429 with backoff.

Is safeguard-sh/gold-scan-action on the GitHub Marketplace?

Not as of 24 October 2026. The docs show how it will work once it ships. The CLI, @safeguard-sh/gold-scan, is available now from registry.safeguard.sh.

What is the difference between fail-on kev and fail-on vuln?

kev fails only when a dependency carries a CVE in the CISA KEV catalog. vuln fails on any known CVE in Gold. none only reports. kev is the default.

Does Gold Scan check transitive dependencies?

No. It reads declared dependencies from manifests, not lockfiles. Use the platform's SCA (GA) for the full tree.

How do I add a Safeguard Gold badge to my README?

Copy the Markdown from the Developers page and change the ecosystem and name in the /badge/ECOSYSTEM/NAME path and the link to the package page.

What does "Gold Certified" mean on Gold Open Source?

Gold knows of no vulnerabilities in the version it indexed and the component is not deprecated. Gold Open Source does not rebuild, sign or attest components; that is Gold Registry (GA).

If you want to go further than the free tools, you can download Safeguard and read the Safeguard docs to scan a full repository with the CLI or local runner. Related reading: our posts on the Gold Open Source directory, the Gold Open Source Chrome extension, Safeguard's Chrome extensions and Gold lookups and Safeguard Gold for open source maintainers.

A lookup or a CI tripwire tells you a dependency has a problem; it does not fix it, and some of the most stressful cases are the ones where Gold's CVE page says plainly that no fixed version exists. The section below covers what Safeguard offers for both cases, the fixed version that has not reached your builds yet and the fix that does not exist upstream at all, and our post on what to do when upstream has no fix goes deeper on the early access fork and patch flow.

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 free Gold tools stop at telling you something is wrong. These demos show the next step, finding and fixing the dependency inside a real repository, with a human approving each action.

This first demo is a real Safeguard CLI session. After install, safeguard opens the interactive terminal, the user asks it to fix the lodash CVE in the repository, and the assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. It then shows /permissions, /model and /scan .. That is the same move a Gold Scan failure asks of you: confirm the safe version, change the dependency, and prove the tests still pass.

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

The second demo connects Claude to the Safeguard MCP server (GA) with OAuth and chooses which tools Claude can use. Safeguard is listed in the Claude connector directory as a community connector. If your team already works in an assistant, this is how the platform's vulnerability and dependency data becomes available there, with you deciding which tools the assistant may call. Our companion post on Safeguard in the IDE and in assistant connector directories covers the setup in more depth.

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

Quick check

Sources

• Gold Open Source home, gold.safeguard.sh
• Safeguard docs: Gold Open Source
• Gold Open Source: Developers (API and badge)
• Gold Open Source: Credits and data sources
• Gold Open Source: Free dependency scan
• Gold Open Source: Actively exploited (KEV) RSS feed
• Gold Open Source: Trending threats RSS feed
• Gold Open Source: Trending threats page
• Gold Open Source: Package API example (lodash)
• registry.safeguard.sh package metadata for @safeguard-sh/gold-scan
• Safeguard docs: OSM Security Database (shows the /v1 not yet available banner)
• NIST SP 800-218, Secure Software Development Framework v1.1
• OpenSSF: Concise Guide for Evaluating Open Source Software
• CISA: Known Exploited Vulnerabilities Catalog
• CISA: Known Exploited Vulnerabilities, catalog criteria and BOD 26-04 note
• FIRST: Exploit Prediction Scoring System (EPSS)
• OpenSSF: OSV schema
• OpenSSF Scorecard
• GitHub Docs: Workflow syntax for GitHub Actions
• GitHub Docs: Security hardening for GitHub Actions
• RSS Advisory Board: RSS 2.0 specification

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