Vet an Open Source Package Before You Adopt It, with Gold Open Source

To vet an open source package before you adopt it, open its page on Gold Open Source at gold.safeguard.sh/packages. It is free, needs no login, and shows the version Gold indexed, its known vulnerability count, an OpenSSF Scorecard health grade with per check scores, the install command, and links to the source repository and registry. You then confirm the license, the exact version you plan to pin and the code's behaviour yourself before the package enters your lockfile.

Gold Open Source answers the first, fast questions: is anything publicly known to be wrong with this release, and does the project look maintained and reviewed. It does not read your code, run the package or judge whether it suits your use. This post walks through what the live package pages show, as fetched on 25 October 2026, how to read each field, a step by step vetting routine built on the OpenSSF evaluation guide and NIST's Secure Software Development Framework, and what Safeguard does once the package is in your build.

Key takeaways

• Gold Open Source (GA) is free and needs no login. Its package directory spans npm, PyPI, Maven, Go, Cargo, RubyGems, NuGet, Packagist, Hex, CRAN, Swift, vcpkg and GitHub Actions, with tens of thousands of packages indexed.
• Each package page shows the indexed version, a vulnerability count, a Gold verification panel, a package health card built from OpenSSF Scorecard, package information, links to homepage, repository and registry, and a Scanned Release row with the date it was last indexed.
• "Gold Certified" has a narrow meaning. Safeguard's docs say a component shows as Gold Certified when 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 the package you will download.
• The indexed version may not be the version you plan to install. Always compare the Scanned Release with the version in your pull request.
• Some fields are blank today. On every package page we opened, the license field was empty, so license review still starts at the registry and the repository.
• A free read API returns the same package data as JSON, including the Scorecard reason text behind each check score.
• After adoption, Safeguard SCA (GA), policies and gates (GA), license compliance (GA) and autonomous remediation (GA, ships switched off with every category set to Manual) keep the package in check across your projects. The Safeguard CLI (GA), local runner (GA) and the Safeguard MCP server in Claude's connector directory (GA) are the surfaces shown in the demos.

Why vetting a package before adoption matters

Adding a dependency takes one line in a manifest. Removing one later can take months. The cheapest moment to say no, or "yes, but this version", is before the first merge.

The OpenSSF Best Practices Working Group puts the point plainly in its Concise Guide for Evaluating Open Source Software: every new dependency increases the attack surface, because a subversion of the new dependency, or of its own transitive dependencies, may subvert your system. The guide's first rule is to consider whether you need the dependency at all.

What NIST SP 800-218 asks of acquired components

NIST's Secure Software Development Framework, SP 800-218 version 1.1, gives this work two tasks under practice PW.4, "Reuse Existing, Well-Secured Software When Feasible Instead of Duplicating Functionality".

PW.4.1 asks organisations to acquire and maintain well secured software components, including open source ones, for use in their software. Its implementation examples include reviewing and evaluating third party components in the context of their expected use (and doing it again if that use changes), obtaining provenance information such as an SBOM or composition analysis for each component, keeping a repository of sanctioned and vetted open source components, and maintaining a list of approved components and versions with their provenance data.

PW.4.4 asks organisations to verify that acquired open source and other third party components comply with the organisation's requirements throughout their life cycles. Its examples include regularly checking for publicly known vulnerabilities that have not yet been fixed, building automatic detection of known vulnerabilities into the toolchain, using existing results from services that vet software, confirming each component is still actively maintained and has not reached end of life, planning what to do about components that are no longer maintained, and confirming integrity through digital signatures or other mechanisms.

Read together, the two tasks describe a gate at the door (PW.4.1) and a watch that never ends (PW.4.4). Gold Open Source helps with parts of both and completes neither.

OWASP, KEV and EPSS: the signals behind "known vulnerable"

OWASP's Top 10 for 2021 lists A06, Vulnerable and Outdated Components. Its description says you are likely vulnerable if you do not know the versions of all components you use, including nested dependencies, or if the software is vulnerable, unsupported or out of date. The category notably includes CWE-1104, Use of Unmaintained Third-Party Components, which is why maintenance signals matter as much as CVE counts.

Two public signals help you rank what you find. CISA maintains the Known Exploited Vulnerabilities catalog, which it describes as the authoritative source of vulnerabilities exploited in the wild, and asks organisations to use it as an input to their vulnerability management prioritisation. FIRST's Exploit Prediction Scoring System is, in FIRST's words, a model that estimates the probability that a published CVE will be exploited in the wild in the next 30 days. A package with a known exploited vulnerability in the version you plan to adopt is a stop sign. A package with a low EPSS score on an old advisory is a judgement call.

The EU Cyber Resilience Act raises the stakes for manufacturers

The European Commission's summary of the Cyber Resilience Act says the regulation introduces mandatory cybersecurity requirements for manufacturers across planning, design, development and maintenance of products with digital elements, and that these obligations apply at every stage of the value chain. It also requires manufacturers to handle vulnerabilities during the lifecycle of their products. The Commission's page gives the dates: the CRA entered into force on 10 December 2024, reporting obligations apply from 11 September 2026, and the main obligations apply from 11 December 2027.

If you ship software into the EU, a recorded vetting step for each new component is the kind of evidence that holds up when someone asks how a dependency got there.

What a good evaluation covers

The OpenSSF Concise Guide groups its checks into six areas. It is worth knowing them before you open any lookup tool, because it shows how much of the job a directory can cover.

Keep that last row in mind. No directory, including Gold Open Source, replaces running the package in a sandbox and reading what it does.

What Gold Open Source shows for packages today

Gold Open Source is Safeguard's free, public directory of open source software and what is publicly known about its security. The offering files describe its package coverage as vulnerability counts, license, versions, download counts and OpenSSF Scorecard health. Everything below was read from the live pages on 25 October 2026. Pages change, so treat the field names as a guide and the values as a snapshot.

The package directory

The directory at gold.safeguard.sh/packages opens with three summary tiles (total packages, secure, recently updated) and a filter panel.

Filters. You can filter by ecosystem and by security status. The ecosystems listed were npm, Cargo, Go, Maven, GitHub Actions, PyPI, RubyGems, Hex, CRAN, NuGet, Swift, vcpkg, Packagist and an "Other" bucket. The security status filter has two values: "No known vulnerabilities" and "Has vulnerabilities".

Sort. The sort menu offers Most Downloaded, Name (A to Z), Recently Updated, Most Starred and Most Vulnerable.

Cards. Each result card shows the ecosystem, the package name, the indexed version, a GOLD badge where the package meets the Gold rule, a short risk label, the vulnerability count ("None" when zero), a dependency count where Gold has one, and the timestamp the entry was indexed. Results are paginated, twenty to a page.

For vetting a specific package you will usually go straight to its page.

A package page, section by section

Package pages follow the pattern gold.safeguard.sh/package/ECOSYSTEM/NAME, for example gold.safeguard.sh/package/npm/express or gold.safeguard.sh/package/pypi/requests. Go modules use the full module path, such as gold.safeguard.sh/package/go/github.com/pkg/errors. Here is what each section showed.

Header. The ecosystem, the package name, the indexed version, a status label (RESOLVED on the pages we opened) and the registry description. The docs do not define the status label, so do not base a decision on it.

Installation. A copy ready install command pinned to the indexed version, such as npm install express@4.22.3 or pip install requests==2.34.2. This is the version Gold scanned, not necessarily the latest release and not necessarily the one you want.

README badge. Markdown for a live Gold badge that links back to the package page. This is for maintainers who want to show status; it does not change what you need to check.

Weekly downloads. The registry's weekly download figure, where Gold has one. Popularity is a signal of adoption, which the OpenSSF guide counts as a plus, not a signal of safety.

Vulnerabilities. A headline count of known vulnerabilities for the indexed version.

Gold verification. A panel that reads either "Meets the Gold bar from automated verification" or "NOT GOLD: Does not currently meet the Gold bar", followed by rows such as "No high or critical vulnerabilities", "License identified" and "Verified provenance", each with a one line note, and a "Last indexed" timestamp. Safeguard's docs say these rows follow from the Gold rule and from whether the component links a source repository; they are not separate scans. Read the notes rather than the ticks. On the pages we opened, the "License identified" row carried the note "License not identified in metadata."

Package health. A letter grade and a score out of ten, labelled as coming from OpenSSF Scorecard, with "Updated this month" where the score is fresh. Below it, individual Scorecard checks with their scores, and a line giving the Scorecard source and the date it was scored. Which checks appear varies by project. Pages we opened showed Maintained, Vulnerabilities, Dangerous Workflow, Code Review, Security Policy, Dependency Update Tool, Branch Protection, Signed Releases, Fuzzing and Pinned Dependencies in different combinations.

Package information. License, last updated, first published, size and maintainer. On the pages we opened, license, size and maintainer were empty, and "first published" matched the date Gold indexed the entry rather than the project's first release. Use the registry for these facts.

Links. Homepage, Repository and Registry, where known. These are the links you use for the authenticity check in step 2 below.

Scanned Release. The current version Gold holds, its vulnerability count, the date it was indexed and its download figure.

Two examples, as fetched

The express page on npm showed version 4.22.3, zero known vulnerabilities, the Gold verification panel passing, and a package health grade of A at 8.9 out of 10. Its Scorecard checks read Maintained 10, Vulnerabilities 10, Dangerous Workflow 10, Code Review 10, Security Policy 10, Dependency Update Tool 10, Fuzzing 0 and Pinned Dependencies 6, scored on 23 October 2026. That is a healthy picture with two clear gaps you might ask about (no fuzzing found, and build dependencies not all pinned by hash), and a license field you have to fill in yourself from the registry.

One Go module page we opened showed a 2020 pseudo version as its current version, although the project has published later tagged releases. The page described the version Gold indexed. If you adopted the module today you would pin a recent tag, and the zero count on the page would tell you nothing about it. This is the most important habit when reading any package page: check that the version on the page is the version in your pull request.

The "Is it safe to use?" verdict page

Each package also has a short verdict page at gold.safeguard.sh/safe/ECOSYSTEM/NAME, linked from the package page as "Is express safe?" and similar. For express it read "Looks safe to use", with a safety score of 100, and a "Why" list: an OpenSSF and maintenance health grade of A, and no known vulnerabilities in the Gold index. Four tiles followed: known CVEs (0), critical or high (0), actively exploited (No) and health grade (A).

The page states its own limits at the bottom: the verdict is generated from public data (known vulnerabilities, CISA KEV, OpenSSF Scorecard and maintenance signals), is guidance and not a guarantee, and you should confirm which version you use with the full report and scan your actual manifest. That is the right way to read it. The verdict page is a summary for a quick conversation, not a sign off.

What "Gold" means, precisely

Safeguard's docs page for Gold Open Source defines it in one rule: 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 add that this describes what is publicly known about the upstream release, and that Gold does not rebuild, sign or attest components.

So a GOLD badge on a package page means "no publicly known vulnerabilities in the indexed version, and not deprecated, at the time it was last indexed". It does not mean someone reviewed the code, that the license suits you, or that the next release will be clean. Hardened, rebuilt artifacts are a separate Safeguard offering, covered in the remediation section near the end of this post.

Where the data comes from

Gold Open Source's Credits page lists its sources. For package pages the relevant ones are the National Vulnerability Database (NIST) for CVE metadata and CVSS scores, the CVE Program, OSV.dev for open source advisories and affected version ranges, GitHub Security Advisories, the CISA KEV catalog behind "actively exploited" flags, EPSS from FIRST on CVE pages, OpenSSF Scorecard for the package health card, and the package registries (npm, PyPI, Maven Central, the Go module index, RubyGems, crates.io, Packagist and the NuGet Gallery) for package metadata.

Gold aggregates, normalises and enriches these sources. That is useful because you check one page instead of five. It also means Gold inherits their gaps: if an advisory has not been published, or has not been mapped to a package and version range, no aggregator can show it.

The free read API

The same data is available as JSON from a free, read only API with no key, documented on Gold's Developers page. The package detail endpoint is GET /api/packages/NAME, the search endpoint is GET /api/packages?search=NAME&ecosystem=ECOSYSTEM, and GET /api/packages/NAME/vulnerabilities lists the advisories affecting a package. A trimmed response for express, fetched on 25 October 2026, looked like this:

{
  "success": true,
  "data": {
    "name": "express",
    "ecosystem": "npm",
    "version": "4.22.3",
    "vulnerabilities": 0,
    "status": "resolved",
    "weeklyDownloads": 93967835,
    "license": null,
    "deprecated": false,
    "repository": "git+https://github.com/expressjs/express.git",
    "health": {
      "score": 8.9,
      "grade": "A",
      "checks": [
        { "name": "Security-Policy", "score": 10, "reason": "security policy file detected" },
        { "name": "Fuzzing", "score": 0, "reason": "project is not fuzzed" }
      ],
      "date": "2026-10-23T21:21:21Z",
      "source": "OpenSSF Scorecard"
    }
  }
}

Two things stand out. The reason strings are Scorecard's own explanations, which the web page does not show, so the API is the quicker way to see why a check scored low. And license is null, which matches the empty license field on the page. The detail endpoint takes a name without an ecosystem, so for names that exist in more than one ecosystem use the search endpoint with the ecosystem filter. For badges, RSS feeds and the rest of Gold's free tooling, see Use Gold Open Source in your workflow.

What the package pages do not show

Know the edges before you rely on a page:

• Your code's use of the package. Gold has no idea whether you call the vulnerable function, which features you enable or how you configure the package.
• Your transitive tree. A package page describes one package. The indirect dependencies it pulls into your build, and their versions, depend on your lockfile and resolver.
• A license decision. The license field was empty on every page we opened. Even when it is filled, compatibility with your distribution model is a legal question for your team.
• Behaviour at install or run time. The page does not show install scripts, network calls or file access. The OpenSSF guide's practical testing and code evaluation steps are still yours.

Step by step: vet a package with Gold Open Source

This routine follows the order of the OpenSSF Concise Guide and records what you find, so the result doubles as evidence for SSDF PW.4.1. It takes ten to twenty minutes for a typical library. Commands are shown as the Gold Developers page documents them; we did not run them inside a CI system.

1. Write down the exact candidate. Record the ecosystem, the package name exactly as it appears in the registry, and the version you intend to pin. Write down why you need it. If an existing dependency or a few lines of your own code would do, stop here; the OpenSSF guide's first rule is to consider necessity.

2. Open the package page and confirm identity. Go to gold.safeguard.sh/package/ECOSYSTEM/NAME. Compare the name character by character with the one in your pull request. Use the Repository and Registry links to confirm the package points at the project you expect, and that the repository is the original rather than a personal fork. If Gold has no page for the name, that is not a verdict either way; go to the registry and repository directly.

3. Compare the version on the page with your version. Read the Scanned Release row and the version in the header. If they match yours, the vulnerability count applies to your candidate. If they do not, treat the count as background only, and check your version through its advisories (step 5).

4. Read the vulnerability count and the Gold verification panel. A GOLD panel means no publicly known vulnerabilities in the indexed version and not deprecated. A "NOT GOLD" panel means at least one of those conditions failed; read the row notes to see which. Where the headline counter and the Scanned Release row show different numbers, do not settle on either; go to the advisories.

5. Follow the advisories. Safeguard's docs say every package page with known vulnerabilities shows a recommended safe version, the lowest version that clears the most advisories, with a copy ready upgrade command. For each advisory, open its CVE page on Gold, which per the docs shows CVSS, affected and fixed versions and an "Am I affected?" check where you enter your version for a verdict. Note whether any advisory is on the CISA KEV list and what its EPSS score is. A known exploited vulnerability that affects your version means you do not adopt that version.

6. Read the package health card as questions, not a grade. Look past the letter. A low Maintained score raises the OpenSSF guide's activity question: has there been a commit and a release in the last year. A low Code Review score means changes may merge without a second person looking. A missing Security Policy means you may not know how to report a problem. A low Pinned Dependencies or Dangerous Workflow score is about the project's build pipeline, which is where supply chain compromises often start. Note the "scored" date; a stale score describes the project as it was.

7. Get the Scorecard reasons from the API. If a check scored low, fetch the JSON to see Scorecard's reason text:

   curl -s https://gold.safeguard.sh/api/packages/express
   

   For a name that exists in several ecosystems, search with the ecosystem filter instead:

   curl -s "https://gold.safeguard.sh/api/packages?search=requests&ecosystem=pypi"
   

   Save the dated response with your decision record.

8. Settle the license outside Gold. Read the LICENSE file in the repository and the license metadata in the registry. Check it is an OSI approved license with an SPDX identifier, as the OpenSSF guide recommends, and that its obligations fit how you distribute your software. Safeguard's license compliance (GA) can then enforce the decision across projects; see open source license obligations and attribution.

9. Check what it pulls in, then try it in isolation. Install the candidate in a throwaway environment and look at what lands in the lockfile. The OpenSSF guide asks whether it adds unexpected or unnecessary indirect dependencies, such as development only packages in production. Look up any new indirect dependencies on Gold the same way. While it is isolated, read the install scripts and recent commits, and run the project's tests.

10. Record the decision and pin the version. Write a short note: candidate, version, date, Gold page and API snapshot, advisories reviewed, health checks of concern, license, transitive additions and the decision. Pin the exact version in your lockfile. This note is the "list of organisation approved components and versions with their provenance data" that SSDF PW.4.1 Example 5 describes, built one package at a time.

11. Hand it to continuous checks. Vetting describes one day. From the next commit, the package should be inside your normal composition analysis, policies and fix pull requests, covered in the section after the tables.

If you want to check a whole manifest rather than one package, Gold also has a free browser page at gold.safeguard.sh/scan that accepts a pasted or uploaded manifest or a CycloneDX or SPDX SBOM, parses it in the browser and checks up to 100 dependencies against Gold's data. See check dependencies for CVEs in your browser.

Reading Scorecard checks: what each one asks

The package health card shows checks from OpenSSF Scorecard. Scorecard's own documentation defines each one. This table maps the checks that appeared on Gold pages to Scorecard's definition and to the question you should ask.

Scorecard's docs note that several checks only work for repositories hosted on GitHub, and that low maintenance is not always a problem for mature software. Use the checks to pick follow up questions, not as a pass mark.

Decision table: what you find on the page, and what to do

Requirement vs what Gold shows vs what you still own

After adoption: keep the package in check with Safeguard

Vetting is a gate. The package then lives in your build for years, and new advisories land against versions that were clean on the day you adopted them. This is where the paid Safeguard platform takes over from the free directory.

Software composition analysis (GA). Safeguard's SCA docs describe resolving the complete dependency graph from your manifests and lockfiles, including transitive dependencies, and matching every resolved package and version against CVE and GHSA advisories enriched with EPSS and CISA KEV. Each finding carries the component and version, the advisory identifiers, severity with EPSS and KEV context, the transitive path from your project root to the vulnerable package, a reachability verdict where available and the safe upgrade target. The docs show a project scan from the CLI as:

safeguard scan --project my-api

We did not run this command for this post. Reachability analysis (GA) ranks findings by whether your code calls the vulnerable path; see prioritise vulnerabilities with reachability, EPSS and KEV. For how deep transitive resolution goes and how unused dependencies are handled, see deep transitive dependencies in Safeguard.

Policies and gates (GA). The decisions you made by hand during vetting can become rules. Safeguard's Policies and Gates docs list conditions including vulnerability severity, CVSS score, EPSS score, license, component age and maintenance (for example, no abandoned packages). Each policy has an action that decides what a failure does to the gate: Block fails the gate, Warn passes it with a warning naming the policy, and Notify passes it and sends a notification. When a team needs a package that breaks a rule, an exception request records the policy, the finding, a business justification and an expiry date, and goes to approvers with an audit trail. With policy outcomes switched on, the docs show a CI job failing on a gate with:

safeguard ci scan --wait --fail-on-gate <gate>

Again, shown as documented, not run here. For writing those rules in plain English, see plain English security policies to release gates.

License compliance (GA). Once you have recorded a license decision during vetting, license policies can flag the same license appearing anywhere else in your estate.

Autonomous remediation (GA). When a new advisory lands against an adopted package and a fixed version exists, Safeguard's Griffin models can open a tested, policy gated pull request to move to the safe version, for one repository or in bulk. It ships switched off, with every category set to Manual, so your team decides what runs on its own. See autonomous remediation in Safeguard.

An SBOM for the record. SBOM generation (GA) gives you the full inventory that OWASP A06 asks for and that a package by package vetting log cannot. See SBOM generation and analysis in Safeguard.

Gold Open Source stays useful alongside all of this: when a pull request adds a dependency, the reviewer can open its Gold page in seconds without an account.

What Safeguard does not do

• Gold Open Source does not vet your use of a package. It describes public facts about an indexed release. It does not know which functions you call, how you configure the package or whether it fits your architecture.
• Gold Open Source does not rebuild, sign or attest packages. Safeguard's docs say so directly. A GOLD badge reflects public vulnerability data and deprecation status for the indexed version, not a review of the code.
• Gold Open Source does not always index the version you plan to adopt. It shows one scanned release per package page, which may be older or newer than yours.
• Gold Open Source does not supply license, maintainer or size data today. Those fields were empty on every package page we opened on 25 October 2026. License and maintainer checks still happen at the registry and the repository.
• Safeguard does not replace your own isolation testing and code review for a new dependency. Install script review, sandbox runs and reading recent commits stay with your team, as the OpenSSF guide recommends.
• Safeguard cannot show advisories that have not been published. Like every tool built on public advisory data, a zero count means nothing is publicly known, not that the code is free of flaws.
• Safeguard does not make the adoption decision. It gives evidence and enforces the rules you set. Whether a package with a low maintenance score is acceptable for your product is your call.

Common mistakes

Reading the badge without reading the version. The most common error. A GOLD badge on an old indexed release says nothing about the release in your pull request. Compare versions first, every time.

Treating the health letter as a pass mark. An A can hide a zero on Code Review; a C can belong to a stable, small library that rarely needs changes. Read the individual checks and the scored date.

Assuming an empty license field means "no license". On Gold today it means "no license metadata". Go to the repository, and record the SPDX identifier yourself.

Stopping at the direct dependency. The package you vet may bring a dozen others into your lockfile. Look at what lands after a test install and vet the new indirect dependencies too.

Vetting once and never again. SSDF PW.4.4 is explicit that verification lasts for the component's life cycle. A package that was clean in October can carry a critical advisory in December. Continuous composition analysis and policies handle this; a one time lookup does not.

Using popularity as a safety signal. Weekly downloads tell you many people depend on a package, which helps with support and scrutiny. They do not tell you the current release is free of problems.

Skipping the record. A decision without a note cannot be audited, repeated or revisited. Ten lines in a pull request description or an approved components list is enough.

FAQ

How do I check if an open source package is safe before using it?

Open its page on gold.safeguard.sh/packages to see known vulnerabilities for the indexed version and its OpenSSF Scorecard health checks. Confirm the version matches the one you plan to use, read the license in the repository, test the package in isolation and check what indirect dependencies it adds. Record the decision and pin the version.

Is Gold Open Source free?

Yes. Gold Open Source is free, needs no login and has a free read only API with no key. It is a GA Safeguard offering.

What does the Gold badge on a package mean?

Safeguard's docs say a component shows as Gold Certified when Gold knows of no vulnerabilities in the version it indexed and the component is not deprecated. It describes public knowledge about the upstream release at the last index. Gold Open Source does not rebuild, sign or attest components.

What is the OpenSSF Scorecard score on a package page?

It is a security health rating for the project's source repository, produced by OpenSSF Scorecard, which checks practices such as code review, branch protection, a security policy, pinned build dependencies, signed releases and recent maintenance. Gold shows a letter grade, the score out of ten and the individual checks with the date they were scored.

Why does the license field on a Gold package page show a dash?

On the pages we checked on 25 October 2026, Gold had no license metadata, and the verification panel noted "License not identified in metadata." Read the LICENSE file in the repository and the registry entry, and record the SPDX identifier yourself.

Can I query Gold Open Source from a script?

Yes. The Developers page documents read only GET endpoints at gold.safeguard.sh, including /api/packages/NAME, /api/packages?search=NAME&ecosystem=ECOSYSTEM and /api/packages/NAME/vulnerabilities. No API key is needed; cache responses rather than calling on every page load.

What does NIST SSDF say about using open source components?

SP 800-218 practice PW.4 covers reusing well secured software. Task PW.4.1 asks you to acquire and maintain well secured components, with examples such as reviewing components in the context of their use and keeping a list of approved components and versions. Task PW.4.4 asks you to verify that components keep meeting your requirements throughout their life cycles, including checking for known vulnerabilities and confirming active maintenance.

Does Gold Open Source tell me whether my code is affected by a vulnerability?

Not for your code. CVE pages on Gold have an "Am I affected?" check that compares a version you enter against an advisory's affected and fixed versions. Whether your application calls the vulnerable code is a reachability question, which Safeguard's reachability analysis (GA) answers inside the platform for your scanned projects.

What should I do if a package I want is not on Gold Open Source?

Vet it directly. Check the registry and repository for identity, license, release history and security policy, run OpenSSF Scorecard against the repository if you can, and test it in isolation. Absence from Gold is not a verdict either way.

Keep adopted packages patched after the review

The vetting routine above decides what enters your build. The next question is what happens when a package you approved months ago picks up a new advisory, or when the fix you need has not shipped upstream yet. The section below is Safeguard's standard answer to that question, and it applies to every package you adopt through this process.

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 categories include dependencies, licenses, security posture and findings, and each one is set separately. 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.

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

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) 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. 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 first demo is a real Safeguard CLI session. You ask it to fix the lodash CVE in a repository; it reads the finding and the advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. It is the step after vetting: a package you adopted picks up an advisory, and the upgrade happens with a human approving the changes.

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

The second demo sets up the Safeguard local runner on your own machine, approves it with its device code, then scans from the terminal. For package vetting, this is how a team scans a candidate branch that adds a dependency without giving Safeguard access to the repository host.

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

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. Once connected, a reviewer can ask Claude about the findings and vulnerabilities Safeguard already holds for a project while reading a pull request that adds a dependency.

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

To try Safeguard yourself, start at safeguard.sh/download, and read the setup guides at docs.safeguard.sh.

Quick check

Sources

• Gold Open Source: package directory
• Gold Open Source: example package page, npm
• Gold Open Source: example package page, PyPI
• Gold Open Source: example package page, Go
• Gold Open Source: "Is express safe to use?" verdict page
• Gold Open Source: Developers, API and badges
• Gold Open Source: Credits and data sources
• Gold Open Source: free dependency scan
• Safeguard docs: Gold Open Source
• Safeguard docs: Software Composition Analysis
• Safeguard docs: Policies and Gates
• OpenSSF: Concise Guide for Evaluating Open Source Software
• OpenSSF Scorecard: check documentation
• NIST SP 800-218, Secure Software Development Framework v1.1
• OWASP Top 10:2021, A06 Vulnerable and Outdated Components
• CISA: Known Exploited Vulnerabilities Catalog
• FIRST: Exploit Prediction Scoring System
• European Commission: Cyber Resilience Act
• SPDX License List
• OSV: open source vulnerability database

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