Gold Open Source Explained: Packages, Images, Models, MCP, Skills, Chips

Gold Open Source (gold.safeguard.sh) is Safeguard's free public directory, and it is generally available (GA). One site, no login, covers open source packages, container images, AI models, MCP servers, agent skills, chip manufacturers, a CVE database and a browser-side dependency scan. This post is the map: what each page shows today, what it does not, and which page answers which question.

Key takeaways

• Gold Open Source (GA) is free and needs no account. Every page in this post was fetched on 25 October 2026 and is described only as it rendered that day.
• Packages and Gold Certified list open source packages across many ecosystems with version, a Gold badge, a risk level, a vulnerability count and the time each entry was last indexed. Package pages add an OpenSSF Scorecard health card, a pinned install command and a README badge snippet.
• Container Images listed no images when we checked, so it is not yet a place to choose a base image. The CVE database loads its list in the browser; use the read API for scripts.
• AI Models, MCP Servers, Agent Skills and Chip Manufacturers are reference directories. They tell you what a thing is, who publishes it and under which license or category. They do not attach a vulnerability verdict to each entry, and you should not read one into them.
• Scan checks a pasted or uploaded manifest or SBOM against the Gold corpus in your browser. Developers documents the free read-only JSON API and README badges.
• The Safeguard connector for Claude (GA) is featured at the top of the MCP Servers page, with an "Add in Claude" link to Claude's connector directory.
• When you need this across every repository you own, the Safeguard platform's SCA (GA), CLI (GA) and autonomous remediation (GA, ships switched off with every category set to Manual) take over. Gold Open Source is the lookup; the platform is the inventory and the fix.

Why one free directory for everything you pull in

A typical service ships open source packages on a base container image, may call an open-weight model, and is increasingly built by an AI agent that loads skills and talks to MCP servers. Each is a third-party component with its own license and maintainers. The facts you need to judge them usually live on three or four different sites, and most people stop after the first.

What the standards ask of you

The case for checking components before you adopt them is written into public guidance, not just vendor marketing.

• NIST SP 800-218, the Secure Software Development Framework (SSDF) version 1.1, published February 2022, has a practice group PW.4 about reusing existing, well-secured software rather than duplicating functionality. In practice that means you are expected to know what you pulled in and to have checked it.
• CISA's Known Exploited Vulnerabilities (KEV) catalog describes itself as "the authoritative source of vulnerabilities that have been exploited in the wild" and tells organisations to use it as an input to vulnerability prioritisation.
• FIRST's Exploit Prediction Scoring System (EPSS) estimates the probability that a published CVE will be exploited in the next 30 days. It complements severity scores such as CVSS, which describe how bad a flaw is rather than how likely it is to be used.
• The Model Context Protocol specification has a Security and Trust and Safety section. It says tools "represent arbitrary code execution" and that hosts must get explicit user consent before invoking any tool.
• Anthropic's Agent Skills documentation tells users to use skills only from trusted sources, meaning ones you created yourself or obtained from Anthropic, because a malicious skill can direct Claude to call tools or run code in ways that do not match its stated purpose.
• Hugging Face's model card documentation describes license metadata as a field the Hub uses to display a model's license and to let people filter by it.
• OpenSSF Scorecard runs automated checks on open source projects for risky practices such as unpinned dependencies or missing code review.

None of these documents tells you which site to use. They all assume you will look something up before you depend on it. Gold Open Source puts most of those lookups in one place.

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

The map: every Gold Open Source page in one table

The sections after it go page by page; the decision table further down maps questions to pages.

The CVE database did not show its list to a plain HTTP fetch, which is normal for a page that loads data in the browser. Use the read API on the Developers page for automation instead.

Packages: the core directory

The Packages page at gold.safeguard.sh/packages is where most people start. It is titled "Explore Packages" and describes itself as a catalog of verified packages with real-time security intelligence. The index runs to tens of thousands of packages.

What you can filter and sort by

The left side of the page offers three groups of filters.

• Type. All types, or container images, or a specific ecosystem.
• Ecosystem. On 25 October the list included npm, Cargo, Go, Maven, GitHub Actions, PyPI, RubyGems, Hex, CRAN, NuGet, Swift, vcpkg, Packagist and an "Other" bucket. Each shows how many entries it holds. The large ecosystems are npm, Cargo and Go; Packagist and vcpkg had only a handful of entries that day, so do not assume full coverage of every ecosystem in the list.
• Security status. "No known vulnerabilities" or "Has vulnerabilities". Most of the index sat in the first bucket.

You can sort by most downloaded, name, recently updated, most starred or most vulnerable. "Most vulnerable" is the useful one for a security team: it brings the packages with the largest known exposure to the top.

What each row tells you

Each row in the list shows the ecosystem, the package name, the version that was indexed, a Gold badge where the package meets the Gold bar, a risk level, a vulnerabilities field, a dependency count where one is known, and a timestamp for when the entry was last indexed. Twenty rows show per page, with paging below.

The version is the one Gold indexed, not necessarily yours, and the timestamp tells you how fresh the record is.

What a package page adds

Click into a package and you get a detail page. Using the npm lodash page as it rendered on 25 October as the example, a package page showed:

1. A plain question as its heading, "Is lodash safe?", with the ecosystem, the indexed version and a status.
2. An install command pinned to that version, with a copy button.
3. A Markdown snippet to add a Gold badge to your README.
4. Weekly downloads and the number of known vulnerabilities.
5. A Gold Verification card with a checklist that includes no high or critical vulnerabilities, license identification and verified provenance (the source repository is linked and traceable), plus the time the entry was last indexed and a link to how Gold is determined.
6. A Package health card from OpenSSF Scorecard, with a letter grade, a score out of 10, the date it was scored and individual checks such as Maintained, Vulnerabilities, Dangerous Workflow, Code Review, Security Policy, Dependency Update Tool, Fuzzing and Pinned Dependencies.
7. Package information: license, last updated, first published, links to homepage, repository and registry.
8. A "Watch this package" control and share links.

Read the detail line under each check, not only the tick. On the lodash page that day, the license check carried the heading "License identified" while its detail text said the license was not identified in the package metadata. The headline and the detail can say different things, and the detail is the part you should copy into a review.

The full walk through of a package page and a CVE page, with the "Am I affected?" checker, is in Use Gold Open Source in your workflow. This hub does not repeat it.

Gold Certified: the packages that meet the bar

The page at gold.safeguard.sh/directory/gold-certified is titled "Gold Open Source Packages: 0 Known CVEs at Last Scan". Its description says these are packages that meet the Gold bar: zero known CVEs at last scan, license identified, and re-checked by Safeguard.

On 25 October the page rendered the same Explore Packages view as /packages, with a "secure" filter already applied and a "Clear Filters" link. The rows looked the same as on the main Packages page, each carrying the Gold badge.

The Gold home page explains what the bar means in its "Four Pillars of Trust" section. The pillar that matters most here says every Gold component has no known exploitable, critical or high-severity vulnerabilities at its last scan, and is re-checked as new advisories are published. Two other pillars cover license identification with obligation mapping, and provenance through source origin tracking and generated SBOMs.

How to read "Gold" correctly

The phrase that carries the weight is "at last scan". Gold is a statement about a specific version at a specific time against the advisories known then. It is not a promise that the version will never have a CVE. When a new advisory lands, the re-check is what moves a package out of the bar. That is why the indexed timestamp on each row is worth a glance before you rely on the badge.

Gold Certified is also a list of what is in the index. A package missing from it is not necessarily unsafe; it may simply not have been indexed, or it may carry a low or medium finding that keeps it out.

Container Images: not a source of image picks today

The Container Images page lives at gold.safeguard.sh/directory/images (/images on its own returned a 404 on 25 October). Its description says it covers Docker and OCI container images with vulnerability reports and verification status. When we checked, the page listed no images; a fetch returned only the header, menu and footer.

So do not use this page to pick or compare a base image today, and do not expect a search for a named image to return a record. Choose base images with your own scanning, and check back on the page later. Once you build an image, you need to know what is inside every layer, which is where container scanning in the platform comes in. See Track container images per environment in Safeguard.

AI Models: who publishes it and under what license

The AI Models page at gold.safeguard.sh/models is a directory of AI and LLM models. Its header says it holds a few hundred models: mostly open-weight models sourced from Hugging Face, plus a set of notable frontier models from the large AI labs, each with developer, license and modality.

What each entry shows

• Name, for example a model family and size.
• Open or closed. Frontier models offered only through an API are marked closed and carry a "Proprietary" license label. Open-weight models carry their actual license.
• Developer, which for open-weight models is the Hugging Face organisation or user that published it.
• License, such as Apache 2.0, MIT, OpenRAIL variants, community licenses with custom terms, or "other".
• Category or modality, from a filter list that on 25 October included embeddings, image to text, masked language model, multimodal (vision-language), reasoning LLM, speech recognition, structured decisions, text generation, text to audio, text to image, text to speech and text to video.
• Downloads and likes for open-weight models, as counts pulled from the Hub.

What it is good for, and what it is not

The models page does a narrow job well: one line on who published a model and what license it claims, the first question a legal reviewer asks.

Several popular models carry community licenses or "other" rather than a standard open source license; "other" means you must read the terms on the model card. Some community-uploaded derivatives of well known models also appear, often with names that suggest a modified or quantised build. The publisher column is how you tell the original from a re-upload.

The page does not show a vulnerability verdict, a scan result or a safety score per model. It is a directory, and this post treats it as one. Safeguard's AI-BOM discovery (GA) is the platform feature that finds which models and SDKs your own code actually uses; the capability overview in What Safeguard does today shows where it fits.

MCP Servers: the official registry, searchable, with a remote flag

The MCP Servers page at gold.safeguard.sh/mcp describes itself as a directory of MCP servers from the official registry, "the connectors and plugins that give AI agents tools and data". On 25 October it listed tens of thousands of servers, and noted that a large share of them have hosted remote endpoints.

Safeguard's own connector, at the top

Before the list, the page features one entry: Safeguard's MCP server at mcp.safeguard.sh. Its card says it offers supply chain security tools for your agent covering vulnerabilities, SBOMs, licenses and remediation, and that it is available in Claude's connector directory or can be connected to any MCP client. Two buttons follow, "Add in Claude" and "Setup guide". The page notes that the directory link opens claude.ai and needs you signed in to Claude, and that the setup guide covers every other client.

That is the route we recommend for Claude users: install Safeguard from the connector directory rather than wiring up a custom server by hand. Safeguard is listed there as a community connector. The capability is GA. For the full install flow in Claude and in IDEs, see Safeguard in your IDE and in the Claude and ChatGPT connector directories.

What each listing shows

Each server in the list shows a display name, a namespaced identifier in reverse domain form (for example a domain flipped around followed by a server name), and a "remote" tag where the server has a hosted endpoint. The page shows the first 300 results and asks you to refine your search for the rest.

How to use it, and what it does not tell you

The registry identifier is the useful part. Many MCP servers share similar display names. The namespace tells you which domain or publisher registered it. If the server someone sent you does not appear here under the namespace you expect, that is a reason to stop and ask before you connect it.

The "remote" tag tells you whether your agent will talk to someone else's hosted service or run code locally. Those are different risk conversations. A remote server sees whatever your agent sends it; a local one runs on your machine with your permissions.

What the page does not show is a security verdict on each server. Being in the official registry means the server was published there. It does not mean anyone has reviewed its tools. The MCP specification itself is blunt about this: tool descriptions "should be considered untrusted, unless obtained from a trusted server," and hosts must get explicit consent before invoking any tool. Use the Gold listing to identify a server, then apply your own consent and access rules in the host.

If you run many MCP servers across a company and want a policy layer in front of them, Safeguard's MCP Guardrail (GA) is the platform feature for that. It is covered in Put a policy proxy in front of MCP servers.

Agent Skills: where a skill comes from

The Agent Skills page at gold.safeguard.sh/skills is the smallest directory on the site, a few dozen entries. Its header describes them as capabilities that extend AI coding agents, "from official Anthropic Agent Skills to notable community skills".

What each entry shows

A source filter sits at the top, with Anthropic's official skills repository and community collections as options. Each skill shows its name, its description as written by its author (often the same text the agent uses to decide when to load it), and its source. On 25 October the list included Anthropic's document skills for Word, PowerPoint and PDF files, design and art skills, a skill creator and a template, alongside community skills for brainstorming, systematic debugging, test-driven development, code review and running parallel subagents.

How to use it

Anthropic's own documentation gives the rule: use skills only from trusted sources, meaning ones you wrote or ones from Anthropic, and audit anything else before you use it. The Gold skills page helps with the first half of that. It tells you whether a skill you have heard of is the official one or a community one, and it shows you the description the skill will present to the agent.

It does not audit the skill. The page shows no scan result, no file listing and no rating for any skill. A skill is a folder of instructions and sometimes scripts. Before you install one, read every file in it, especially any script it runs, and check that what it does matches what its description says.

Chip Manufacturers: hardware context, not vulnerability data

The Chip Manufacturers page at gold.safeguard.sh/chips is the odd one out, and it is worth being clear about what it is. Its header describes a few dozen semiconductor companies: fabless designers, foundries, integrated device manufacturers (IDMs), memory makers, electronic design automation (EDA) vendors, IP licensors and equipment makers.

What each entry shows

A filter row lets you pick a category: EDA, IDM, IP, equipment, fabless, foundry or memory. Each company entry shows its category, headquarters country, founding year and a line on its notable products, such as CPU or GPU families, AI accelerators, memory types or fab equipment.

Why it is in a security directory

Hardware is part of the supply chain too. For an AI deployment, an embedded product or a sovereign hosting requirement, you often need to know whether a chip maker designs or fabricates, and where it is headquartered. The chips page gives that context in one place.

It does not hold vulnerability data, firmware advisories or export control status. For hardware and firmware vulnerabilities, go to the manufacturer's own security advisories and to the CVE record.

Vulnerability database: open it in a browser, or call the API

The CVE database lives at gold.safeguard.sh/vulnerability. Its description calls it a free, real-time open source vulnerability database you can search by package, severity or ecosystem, with CVSS scores, affected versions, fixed versions and remediation guidance.

On 25 October a plain fetch returned only the frame and a "Loading vulnerabilities..." placeholder; the list loads in the browser. Coverage is not complete, and some well known CVEs return "not found", so a missing record is not evidence that a CVE does not exist or does not affect you. Check the CVE Program or OSV record as well.

The home page's "Latest Security Vulnerabilities" panel gives a feel for the record format: the advisory ID, a severity, a short description naming the package, a published timestamp, a CVSS score and a fixed version, or "No fix yet" where none had shipped. That last field is the one to watch. A record that says "No fix yet" is telling you to plan a mitigation, not an upgrade.

For automation, the Developers page lists two read endpoints for vulnerabilities: a search that filters by keyword, severity or ecosystem, and a detail call by CVE ID that returns CVSS, EPSS, CISA KEV status and affected and fixed versions.

Scan: check a manifest or SBOM in your browser

The Scan page at gold.safeguard.sh/scan is titled "Free Dependency Scan". It asks you to paste or upload a dependency manifest, or a CycloneDX or SPDX SBOM, and shows which packages carry known vulnerabilities against the Gold corpus.

What the page states, in its own words and in the Developers page:

• It is free and needs no login.
• The file is parsed in your browser and is not sent to a server. The Developers page adds that only package names are looked up.
• It checks up to 100 dependencies against the Gold corpus.

That 100 dependency limit is the thing to plan around. A small service's direct dependencies fit. A full lockfile for a large application, with transitive dependencies, will not. Use the scan page for a quick check of a manifest or a small SBOM, and use the platform for a full inventory.

Developers: the read API and README badges

The Developers page at gold.safeguard.sh/developers documents two things that are free and read-only with no API key.

README badge. A live status badge for any package, using the pattern /badge/ followed by the ecosystem and package name. The page gives a Markdown snippet that links the badge to the package's Gold page, and says the badge updates as the package's status changes.

Read API. All endpoints are GET, return JSON and are rooted at gold.safeguard.sh. The page lists package search, package detail, a package's vulnerabilities, corpus-wide package statistics, vulnerability search and vulnerability detail by CVE ID. It asks callers to cache responses rather than request them on every page load, and says the data is aggregated from public sources listed on the Credits page.

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

That is the example the page itself gives. The Developers page also has a section on CI integrations and states plainly which parts are released and which are not; read it before you plan a pipeline around one. The step by step for the API, badges, RSS feeds and CI is in Use Gold Open Source in your workflow.

Where the data comes from

The Credits and Data Sources page says Gold aggregates, normalises and enriches public data from named publishers such as NIST's National Vulnerability Database, the CVE Program, OSV.dev, GitHub Security Advisories, CISA's KEV catalog, FIRST's EPSS and OpenSSF Scorecard, and that "the original records belong to them". Where a Gold record and the upstream record disagree, the upstream record is the source of truth.

Step by step: a component intake review using the whole directory

Here is a routine for a developer or reviewer who is about to add something new to a project. It uses only free Gold pages. Allow about fifteen to twenty minutes for a component you have never seen.

1. Name the component exactly. Write down the ecosystem, the package name and the version you plan to use. For a model, write the publisher and model name. For an MCP server, write the registry identifier. For a skill, write its source repository.
2. Look it up in the right directory. Packages go to /packages. Models go to /models. MCP servers go to /mcp. Skills go to /skills.
3. For a package, open its page. Record the indexed version, the vulnerability count, the Gold Verification checklist including the detail text under each check, the Scorecard grade and the date it was scored, and the license.
4. Compare versions. If yours is older than the indexed version, check the package's vulnerabilities through the API for your version.
5. For each CVE, read the fixed version. If it says "No fix yet", plan a mitigation. If a fixed version exists, pin it.
6. Check KEV and EPSS for anything that remains. A CVE that is in KEV goes to the top of the list regardless of its CVSS score.
7. For a model, read the license. If the license column says "other" or names a community license, open the model card and read the terms. Confirm the publisher is the original, not a re-upload.
8. For an MCP server, check the namespace and the remote flag. Decide whether your host's consent and access settings are appropriate for a remote service that will see your agent's traffic.
9. For a skill, check the source, then read the files. Gold tells you where it comes from. Only reading it tells you what it does.
10. Run the manifest through /scan. Once the new component is in your manifest, paste the manifest into the free scan page to confirm nothing else in the file carries a known vulnerability. Stay within the 100 dependency limit.
11. Record what you found. Paste the results into the pull request description or your intake ticket, with the date. Gold's records are point-in-time, so the date is part of the evidence.

Example: an intake record

This is what step 11 looks like for the lodash example above, filled in from the package page as it rendered on 25 October 2026.

The record shows what a green badge alone would not: no known vulnerabilities, but a low maintenance score and no license in the metadata.

Decision table: which page answers which question

When to move from the directory to the Safeguard platform

Gold Open Source answers questions about one component at a time. Once the question becomes "where is this in everything we ship", you need an inventory, and that is what the platform does.

• SCA and SBOM generation (GA). The Safeguard CLI (GA) scans a repository, a container image or an existing SBOM and writes results as JSON. The commands are safeguard scan --dir . for a repository, safeguard scan --image <name> for an image and safeguard scan --sbom <file> for an SBOM. Results land under ./output.
• Which projects contain a component. The platform shows every project that contains a given component and version, which is the question you ask the morning a new KEV entry appears.
• Prioritisation (GA). Reachability analysis, EPSS and KEV together rank which findings to fix first. See Prioritise vulnerabilities with reachability, EPSS and KEV in Safeguard.
• Autonomous remediation (GA). Fix pull requests that move a dependency to a safe version. It ships switched off, with every category set to Manual, so your team chooses what runs on its own.
• SBOMs you can hand to customers (GA). See SBOM generation and analysis in Safeguard.

Gold Registry (GA) is the paid side of Gold: hardened artifacts you pull into builds, each with a public evidence page. If you need to explain that page to an auditor, see Read a Gold Registry evidence page. For the full list of what Safeguard offers and how each piece is labelled, see What Safeguard does today.

What Safeguard does not do

Gold Open Source is useful because it is honest about being a directory. Here is where its edges are.

1. It does not see your code. Gold Open Source knows nothing about your repositories, lockfiles or images. A package that is Gold at its indexed version tells you nothing about the older version pinned three levels down in your dependency tree. The scan page helps, but only up to 100 dependencies.
2. It does not give a verdict on models, MCP servers, skills or chips. Those four directories list what a thing is, who publishes it and under what license or category. They show no vulnerability score or safety rating per entry. Being listed is not an endorsement.
3. It is point-in-time. "At last scan" is part of the Gold definition. A record checked last week does not account for an advisory published this morning. Always look at the indexed or scored date.
4. It does not replace the upstream source. CVE, OSV, GHSA, KEV, EPSS and Scorecard data originate with their publishers. Where Gold and an upstream record disagree, the upstream record wins.
5. It does not fix anything. Gold tells you the fixed version where one exists. Applying it, testing it and shipping it is your work, or the platform's autonomous remediation once you turn it on.
6. It does not cover every ecosystem equally. The ecosystem filter shows large indexes for a few ecosystems and small ones for others. A short list for your ecosystem means thinner coverage, not fewer problems.
7. It is not legal advice. License fields come from package metadata, model cards and registries. Read the actual license text before you rely on it.

Common mistakes

• Treating the Gold badge as permanent. It reflects the indexed version at its last scan. Check the date.
• Reading only the headline of a check. On package pages, the detail text under a check can qualify the headline. Copy the detail into your review.
• Assuming the indexed version is your version. The directory row shows one version. Yours may be older and carry CVEs that the newer one does not.
• Scraping pages that render in the browser. The CVE list returns a frame to a plain fetch. Use the read API.
• Looking for a base image on Gold. The Container Images page listed no images when we checked.
• Taking an MCP registry listing as a security review. The registry records who published a server. It does not vet its tools. The MCP specification says tool descriptions should be treated as untrusted unless the server is trusted.
• Installing a skill because it appears on the list. The skills page tells you the source. Anthropic's guidance is to audit anything that is not yours or Anthropic's before using it.
• Skipping the license column on models. "Other" and community licenses are common. They often carry use restrictions.
• Pasting a whole monorepo lockfile into /scan. The page checks up to 100 dependencies. Split it, or use the CLI.

FAQ

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

It is free and needs no account. The scan page, the read API and the README badges are also free. The site has a Login link for Safeguard platform users, but you do not need it to use any page in this post.

What does "Gold Certified" mean?

On the Gold Certified page, it means a package had zero known CVEs at its last scan, has an identified license and is re-checked as new advisories are published. The key words are "at last scan". It is a point-in-time statement about a specific version.

Does Gold Open Source scan AI models for vulnerabilities?

The AI Models page does not show a vulnerability or safety verdict per model. It lists each model's developer, license, modality and, for open-weight models, downloads and likes from Hugging Face. Use it to confirm the publisher and license, then read the model card.

Is every MCP server on gold.safeguard.sh safe to use?

No listing on the MCP Servers page is a safety rating. The page lists servers from the official MCP registry with their namespace and whether they are remote. Treat every server's tools as code execution, as the MCP specification advises, and set consent and access rules in your host.

How do I add the Safeguard MCP server to Claude?

The MCP Servers page features Safeguard's connector at the top with an "Add in Claude" button that opens Claude's connector directory. You need to be signed in to Claude. The page's setup guide covers other MCP clients.

Are the agent skills on Gold Open Source verified?

The skills page shows each skill's source, official Anthropic or community, and its description. It does not show a scan or audit result. Read every file in a skill before you install it.

Why is there a chip manufacturers directory on a security site?

Hardware is part of the supply chain. The chips page gives category, headquarters, founding year and notable products for a few dozen semiconductor companies. It is context for procurement and sovereignty questions, not a source of hardware vulnerability data.

Can I use Gold Open Source from a script?

Yes. The Developers page lists free, read-only GET endpoints for package search, package detail, package vulnerabilities, corpus statistics, vulnerability search and CVE detail. No API key is needed. Cache responses rather than calling on every page load.

Gold Open Source tells you whether a component version is known to be vulnerable and what the fixed version is. The block below covers what happens next, when you need that fix in your own builds, or when no fix exists yet.

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

These demos show the parts of Safeguard that pick up where the free directory stops. Each one is a recorded walkthrough you can click through.

The first demo shows Claude connected to Safeguard. It walks through adding the Safeguard connector, signing in with OAuth and choosing which tools Claude can use. This is the same connector featured at the top of the Gold MCP Servers page, and it lets you ask Claude the questions in this post about your own projects rather than one package at a time.

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

The second demo is a real Safeguard 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 any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, and prints a summary without pushing anything. That is the step after a Gold lookup tells you which version is safe.

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

The third demo sets up the Safeguard local runner on your own machine, approves it with its device code and then scans from the terminal. Use it when you want to run the full scan across a repository that is too large for the browser scan page.

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

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

Quick check

Sources

• Gold Open Source home
• Gold Open Source: Packages
• Gold Open Source: Gold Certified
• Gold Open Source: Container Images
• Gold Open Source: AI Models
• Gold Open Source: MCP Servers
• Gold Open Source: Agent Skills
• Gold Open Source: Chip Manufacturers
• Gold Open Source: Vulnerability database
• Gold Open Source: Free dependency scan
• Gold Open Source: Developers, API and badges
• Gold Open Source: lodash package page
• Gold Open Source: Credits and data sources
• Safeguard documentation
• Safeguard download page
• NIST SP 800-218, Secure Software Development Framework 1.1
• CISA Known Exploited Vulnerabilities Catalog
• FIRST Exploit Prediction Scoring System
• FIRST Common Vulnerability Scoring System
• OpenSSF Scorecard
• Model Context Protocol specification, 2025-06-18
• Official MCP Registry
• Anthropic: Agent Skills overview
• Hugging Face: Model Cards
• OSV: Open Source Vulnerabilities
• CVE Program
• MITRE CWE
• CycloneDX specification overview
• SPDX

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