Source AI Models from Hugging Face Safely with Gold Open Source

To source an AI model from Hugging Face safely, start with a free lookup in the Gold Open Source models directory at gold.safeguard.sh/models, which shows each model's license in plain language, whether commercial use is allowed, whether the weights are open or API only, and how widely it is used. Then confirm the license on the model card, prefer safetensors weights over pickle files, and pin the exact revision you tested. Gold Open Source is generally available (GA), free and needs no login; the file level checks after the lookup are steps you run yourself.

This post walks through that flow end to end: what the models directory shows today, what it does not show, how to read each field, and the Hugging Face side of the job from Hugging Face's own documentation. It is about choosing and vetting a model before you adopt it. If you need to find the models and AI SDKs already inside your code, read find every AI model and SDK you ship with Safeguard AI-BOM discovery instead.

Key takeaways

• Gold Open Source (GA, free, no login) has an AI models directory that lists open weight models sourced from the Hugging Face Hub plus notable frontier models, each with developer, license, category and modality.
• Every model page shows Category, Downloads / 30d, Likes / Stars, License and Weights, plus a "Licensing & commercial use" panel that labels commercial use as OK, allowed with conditions, or unclear.
• The license panel is plain language guidance. The page itself says it is not legal advice and tells you to confirm against the model's own license.
• The models directory is a sourcing aid, not a verdict on the weight files. The model pages show no result about what is inside the files, no file format and no pinned revision. Those checks stay with you.
• On the Hugging Face side, the documented controls are model cards with YAML metadata, a license field with an "other" option, gated access requests, the safetensors format, pickle warnings, and the revision parameter for pinning a tag or commit hash.
• After adoption, Safeguard AI-BOM discovery (GA) finds which models and AI SDKs your code actually uses, and the Safeguard CLI (GA) scans the software dependencies that load those models.
• In Claude, Safeguard (GA) is added from the connector directory as a community connector, so the same checks can run inside a chat.

Why model sourcing is a supply chain problem

A model you download from a public hub is a third party component, just like a package from npm or PyPI. It arrives as files you did not build, from an author you probably have not met, under a license your legal team has not read. It then runs inside your product with access to your data. Teams that would never pip install a random package without a look will often pull a multi gigabyte model because a notebook or a tutorial named it.

The difference is that model files are much harder to inspect than source code. You cannot read a weight matrix the way you can read a function. That pushes more of the risk to the sourcing decision itself: who published the model, under what terms, in what file format, and which exact version you took.

What OWASP says about LLM supply chain risk

The OWASP Top 10 for LLM Applications 2025 lists supply chain as LLM03. Its entry walks through several risks that apply directly to choosing a model from a public hub:

• Licensing risks. OWASP notes that AI work mixes software and dataset licenses with different legal requirements, and that dataset licenses can restrict use, distribution or commercial use.
• Outdated or deprecated models. Models that are no longer maintained carry security issues of their own.
• Vulnerable pre-trained models. OWASP describes models as binary black boxes where static inspection offers little assurance, and warns that a model can carry hidden biases or backdoors that the hosting repository's checks did not catch.
• Weak model provenance. OWASP points out that model cards and documentation describe a model but offer no guarantee about where it came from, and that an attacker can compromise a supplier account on a model hub or create a look alike.

The mitigations OWASP lists start with vetting data sources and suppliers, including their terms and privacy policies, and keeping that review going over time. That is the part of the job a directory lookup speeds up.

What NIST says

NIST AI 600-1, the Generative AI Profile of the AI Risk Management Framework, names twelve risks that generative AI introduces or makes worse. The twelfth is Value Chain and Component Integration, which NIST describes as non transparent or untraceable integration of upstream third party components, along with improper supplier vetting across the AI lifecycle. Choosing a model without recording who published it and under what terms is exactly that gap.

NIST SP 800-218A, published in July 2024, takes the Secure Software Development Framework (SSDF) version 1.1 and adds practices, tasks and considerations specific to AI model development. If your organisation already maps its development process to the SSDF, 800-218A is where model specific expectations sit. The broader NIST AI Risk Management Framework (AI RMF 1.0) frames all of this as risk management across the AI lifecycle, and NIST notes on its AI RMF page that the framework is being revised.

None of these documents tells you which model to pick. All of them expect you to know what you picked, where it came from, and why you trusted it.

What Hugging Face says about loading model files

Hugging Face's own documentation is direct about the main file level risk. Its pickle scanning page explains that pickle is a widely used serialization format in machine learning and the default format for PyTorch model weights, and that loading a pickle file can run arbitrary code. Hugging Face suggests loading models from users and organizations you trust, relying on signed commits, and using safer formats.

The safer format Hugging Face documents is safetensors, which its docs describe as a simple format for storing tensors safely, as opposed to pickle, while staying fast. The Transformers library exposes this choice in its loading options: use_safetensors controls whether safetensors checkpoints are used, and weights_only, which defaults to True, restricts the unpickler to tensors, primitive types and dictionaries plus any types you add explicitly.

So the safest model is not only one from a trusted publisher. It is one from a trusted publisher, in a safe format, at a version you pinned.

What Hugging Face gives you to work with

Before looking at Gold, it helps to know which controls Hugging Face itself documents. Everything in this section comes from Hugging Face's docs.

Model cards

Hugging Face describes model cards as files that accompany models and provide handy information. Under the hood, a model card is the README.md in the model repository: a Markdown file with a YAML metadata section at the top. Hugging Face says a model card should describe the model, its intended uses and potential limitations (including biases and ethical considerations), the training parameters and experimental information, the datasets used, and the evaluation results.

For sourcing, three parts of the card matter most: the stated intended uses, the limitations, and the license metadata.

License metadata, including "other"

The model card metadata includes a license field. Hugging Face publishes a list of license identifiers it recognises, ranging from common open source licenses to model specific community licenses. Two values deserve attention. unknown means exactly that. other means the author is using a license not on the list; in that case Hugging Face asks the author to add the license text to a LICENSE file in the repository and set a name for it in license_name.

When you see other, the license is not missing. It is somewhere in the repository, and someone on your side has to read it.

Gated models

Some model authors turn on access requests. Hugging Face calls these gated models. When gating is on, you must submit an access request to reach the model files, and that request shares your Hugging Face username and email address with the model authors unless they opted out of collecting it. Authors can also add custom fields to the request form.

For an enterprise, gating raises a practical question: whose account requests access, and what terms did that person accept on the company's behalf?

Downloading and pinning a revision

Hugging Face documents several ways to download a model. From the command line:

hf download HuggingFaceH4/zephyr-7b-beta

Since model repositories on the Hub are Git repositories backed by Xet storage, you can also clone them with Git once git-xet is installed.

The control that matters most for supply chain hygiene is the revision parameter. By default, the Hugging Face client downloads the latest version from the main branch. The docs show how to download a file from a specific branch, a pull request, a tag or a commit hash instead:

# Download from the `v1.0` tag
hf_hub_download(repo_id="lysandre/arxiv-nlp", filename="config.json", revision="v1.0")

A tag or branch can move. A commit hash cannot. If you want the model you tested to be the model you ship, pin the commit hash.

What the Gold Open Source models directory shows today

Gold Open Source is Safeguard's free, no login public directory of open source software and what is publicly known about its security. Safeguard's docs list what it covers: packages, container images, CVEs, CWEs, MITRE ATT&CK, AI models, MCP servers, agent skills and chip manufacturers. For AI models, the docs describe the section as open weight models sourced from the Hugging Face Hub, with live download and star counts, plus notable frontier models.

Everything below describes the live pages at gold.safeguard.sh/models as fetched on 25 October 2026.

The directory page

The models directory lists several hundred AI and LLM models. The header explains that most are open weight models sourced from Hugging Face, with notable frontier models added, and that each entry shows developer, license and modality.

At the top is a search box with the hint "Search models", suggesting names such as Llama, DeepSeek, GPT or Whisper. Below it is a category filter with these options:

• Embeddings
• Image to text
• Masked language model
• Multimodal (vision-language)
• Reasoning LLM
• Speech recognition
• Structured decisions
• Text generation / LLM
• Text to audio
• Text to image
• Text to speech
• Text to video

Each card in the list shows the model name, a tag that says open or closed, the developer, the license and the category. Open weight models also show two numbers carried over from Hugging Face: downloads and likes. On the day we fetched it, the list opened with the frontier models tagged closed and proprietary, followed by open weight models ordered by likes.

A model page, field by field

Click a model and you get a detail page. For an open weight model sourced from Hugging Face, the page has the same structure every time.

The header. The page labels the model as an "Open-Weight Model" or a "Proprietary Model", then gives the model name and the publisher, which for Hugging Face models is the organisation or user name from the repository path.

The facts row. Five fields:

Proprietary models do not show download or like counts, because they have no Hub repository to count.

About. A short plain sentence that restates the weights status and category. For an open weight model it says the weights are published and can be downloaded, self hosted and fine tuned. For a proprietary model it says the weights are not published and the model is accessed through the provider's API. It then says what the license allows for commercial use.

Licensing & commercial use. This is the most useful panel for sourcing. It shows:

1. The license name in full, for example "Llama 3 Community License" rather than the short llama3 identifier.
2. A commercial use verdict. The values we saw were "Commercial use OK", "Commercial use with conditions" and "Commercial use unclear".
3. A license family tag. The values we saw were "permissive", "open weight", "proprietary" and "unknown".
4. A one or two sentence plain language summary of what the license asks of you.
5. A fixed disclaimer: "Plain-language guidance, not legal advice," followed by an instruction to confirm against the model's own license.

View on HuggingFace. A direct link to the model's repository on the Hub, where the model card, files and commit history live. For proprietary models, the link goes to the provider's page instead.

Related models. A list of other models in the same category, mixing open weight and proprietary entries. This is a quick way to find alternatives when the first choice fails your license check.

Five live examples

These examples show how the license panel reads across different kinds of models. Counts were live values on 25 October 2026 and will change.

An embeddings model under MIT. The page for bge-small-en-v1.5 from BAAI shows the Embeddings category, open weights, license mit, and tens of millions of downloads in 30 days. The license panel reads "MIT", "Commercial use OK" and "permissive", and summarises MIT as a short permissive license that lets you use, modify and distribute the model, including in closed source products, as long as you keep the copyright and license notice.

A speech model under Apache 2.0. The page for whisper-large-v3 shows Speech recognition, open weights and Apache 2.0. The panel marks it permissive with commercial use OK, and its summary points out the explicit patent grant and the need to preserve the NOTICE file and respect trademark terms.

A text generation model under a community license. The page for Meta-Llama-3-8B shows the license identifier llama3, expands it to "Llama 3 Community License", and marks it "Commercial use with conditions" and "open weight". The summary names the conditions the page considers most important: an acceptable use policy, a separate license needed above a monthly active user threshold, and an attribution requirement. This is the case where the verdict alone is not enough; the conditions are the decision.

A text to image model with license "other". The page for FLUX.1-dev shows license other, "Commercial use unclear" and "unknown". The summary says the license is not clearly specified and tells you to check the source's license text or model card before relying on it, especially for commercial use. This lines up with Hugging Face's own convention: other means the license text lives in the repository and someone has to read it.

A proprietary frontier model. The page for Claude Opus 4 shows "Proprietary Model", license proprietary and Weights "Proprietary", with a note that the model is API only and no weights are published. The license panel marks commercial use as allowed with conditions and explains that use is governed by the provider's terms of service. For an API only model, sourcing is a vendor and contract decision rather than a file download.

What Gold's own docs say about its labels

Safeguard's Gold Open Source docs are explicit about the limits of the directory. A component shows as Gold Certified when Gold knows of no vulnerabilities in the version it indexed and the component is not deprecated, and the docs call that "the whole rule." They also state that Gold does not rebuild, sign or attest components. In other words, Gold reports what is publicly known about the upstream release. It does not vouch for the bytes.

For AI models specifically, the live model pages do not show a vulnerability panel, a file listing, a file format or a revision. They show what this post describes: category, popularity, license, weights status, related models and a link out. Read them as a sourcing and license triage tool.

Step by step: vet a Hugging Face model before you adopt it

This walkthrough combines the Gold Open Source lookup with the Hugging Face controls described above. Steps 2 to 5 happen in Gold; steps 6 to 10 happen on Hugging Face and in your own tooling. Nothing here needs a Safeguard account.

1. Write down the job before you search

Note the task (embeddings, speech recognition, text generation), where the model will run (your own hardware or a provider's API), and whether the product is commercial. The commercial question decides which license verdicts you can accept. The hosting question decides whether you need open weights at all.

2. Search or filter the models directory

Open gold.safeguard.sh/models. If you have a model name, type it in the search box. If you only have a task, pick the category filter instead. The category list gives you the candidate set without having to know model names in advance.

3. Read the Weights field first

Open weights mean you will download, store and load files, so the rest of this walkthrough applies. Proprietary means the model is API only; your sourcing decision moves to the provider's terms, data handling and your contract. Do not spend time on file formats for a model you cannot download.

4. Read the license panel, then sort candidates into three groups

Use the commercial use verdict to sort:

• Commercial use OK, permissive. Usually the lightest review. You still need to keep notices, and the summary tells you which ones.
• Commercial use with conditions. Read the conditions in the summary, then the full license. These licenses often carry acceptable use policies, user thresholds or attribution rules that affect product design, not just legal sign off.
• Commercial use unclear, unknown. Stop and read the license text in the repository. Gold's own page tells you to do this, and Hugging Face's convention for other puts the text in a LICENSE file.

Remember the disclaimer on every page: this is plain language guidance, not legal advice.

5. Check related models for a cleaner alternative

If your first choice has conditions you cannot meet, the Related models list on the same page shows other models in the same category with their licenses. A permissive alternative with a similar task may save a legal review. Compare popularity too: Downloads / 30d and Likes / Stars do not prove safety, but a model almost nobody uses gets less community scrutiny.

6. Follow "View on HuggingFace" and read the model card

Click through to the repository. Read the model card's intended uses and limitations, which Hugging Face says the card should describe. Check that the license in the card's metadata matches what Gold showed. If it says other, find the LICENSE file and the license_name value.

Check the publisher. The model path on Hugging Face is organisation/model. Confirm the organisation is the one you expect, since OWASP's LLM03 entry warns about look alike accounts and compromised supplier accounts on model hubs.

7. Check whether the model is gated

If the repository asks for an access request, decide who submits it. Hugging Face's docs say the request shares the requester's username and email with the model authors unless they opted out, and authors can add custom fields. Use a company controlled account, record what was accepted, and keep a copy of the terms.

8. Look at the file formats in the repository

In the repository's files, look for .safetensors weights. Hugging Face recommends safer formats over pickle because loading a pickle file can run arbitrary code. If a model ships only pickle based weights, treat it as higher risk: load it only from a publisher you trust, and in Transformers keep weights_only at its default of True. Where safetensors weights exist, ask your loader for them explicitly with use_safetensors.

9. Pin the exact revision you tested

Find the commit hash of the revision you evaluated, and pass it as revision when you download. Hugging Face's docs show the parameter accepting a branch, a tag, a pull request reference or a commit hash; a commit hash is the only one that cannot move under you. Store the hash wherever you store the rest of your dependency pins, so an upgrade is a reviewed change rather than a silent one.

10. Mirror and record

Copy the pinned files into storage you control, so production does not depend on a public hub being reachable or unchanged. Record the decision in a short intake record (an example follows below), including the Gold page you checked, the license verdict, and the commit hash.

11. Scan the code that loads the model

The model runs inside a Python stack: a model library, a tensor framework, tokenizers and their dependencies. Those are ordinary open source packages with ordinary CVEs. Look each one up in Gold Open Source for known vulnerabilities, affected and fixed versions, or run the Safeguard CLI (GA) over the repository:

safeguard scan --dir .

The CLI writes results as JSON under ./output. Fix what it finds before the model goes to production. For the full free workflow around package lookups, see use Gold Open Source in your workflow.

12. After adoption, keep an inventory

Once the model is in, the risk shifts from "should we take it" to "where is it now". Safeguard AI-BOM discovery (GA) finds the AI models and AI SDKs your code uses, so you can tell when a second team quietly adopts a different model or a newer revision. That flow is covered in find every AI model and SDK you ship with Safeguard AI-BOM discovery.

A model intake record you can copy

An intake record turns the walkthrough into something an auditor or a future teammate can read. This is a suggested format for your own repository, not a Safeguard file format.

model_intake:
  name: bge-small-en-v1.5
  publisher: BAAI
  source: https://huggingface.co/BAAI/bge-small-en-v1.5
  gold_page: https://gold.safeguard.sh/models/BAAI/bge-small-en-v1.5
  checked_on: 2026-10-25
  task: embeddings for internal search
  hosting: self-hosted
  weights: open
  license:
    identifier: mit
    gold_verdict: "Commercial use OK"
    gold_family: permissive
    confirmed_against_model_card: true
    obligations: "keep copyright and license notice"
  gating: none
  files:
    format: safetensors
    revision: "<full commit hash you tested>"
  mirror: "<your internal artifact store path>"
  loader_settings:
    use_safetensors: true
    weights_only: true
  dependency_scan: "safeguard scan --dir . (no open critical or high findings)"
  approved_by: "<name, role>"
  review_by: 2027-04-25

Keep it next to the code that loads the model. When someone wants to change the model or the revision, the pull request changes this file too, and the reviewer can see what moved.

Reading the license verdicts: a decision table

What changes between a package and a model

Teams that already vet open source packages can reuse most of their process, with four adjustments.

Versions are commits, not releases. Packages have semantic versions and registries that keep old versions available. Hugging Face model repositories are Git repositories; the "version" you care about is a commit. A model's main branch can change without any version number changing.

Licenses are less standard. Package ecosystems have converged on a small set of SPDX identifiers. Models add community licenses with conditions on use, attribution and scale, and custom licenses recorded as other. The Gold license panel helps most here, because it turns an identifier into a verdict and a summary.

Inspection is harder. You can read a package's source. You cannot meaningfully read weights. That makes the publisher, the file format and the pinned revision carry more weight in the decision.

The surrounding code is still code. The libraries that load and serve a model are ordinary packages. The model may be the headline, but CVEs in the loading stack are the part your existing SCA process already handles. For how Safeguard approaches license obligations on the package side, see open source license obligations, OpenChain and attribution with Safeguard.

Using Gold model lookups inside Claude

If your team works in Claude, Safeguard (GA) is available from Claude's connector directory as a community connector. You add it from the directory, sign in, and choose which Safeguard tools Claude may use. A developer can then ask about a project's vulnerabilities or a CVE's fixed version in the same chat where they are comparing models. The setup is covered in Safeguard in your IDE and in the Claude and ChatGPT connector directories.

For the models directory itself, the simplest path is still the web page: it needs no login and every field described here is visible without an account.

What Safeguard does not do

Honest limits for this flow:

1. The models directory gives no verdict on weight files. Model pages show license, weights status, category and popularity. They do not list the files in a repository, show their format, or report anything about what the files contain. File format checks and safe loading settings are steps you run, as described above.
2. Gold does not rebuild, sign or attest models. Safeguard's Gold Open Source docs say this about Gold components in general. The model pages reflect public metadata about the upstream model; they do not produce a hardened copy of it.
3. The license panel is not legal advice. Every model page says so. It is a fast first read that tells you which models need a lawyer and which probably do not. The model's own license text is the authority.
4. It does not pin or mirror anything for you. Gold does not record the commit you tested or keep a copy of the files. Pinning a revision and mirroring the weights into your own storage are your controls.
5. It does not judge model quality, bias or fitness for your task. The directory does not benchmark models or assess their outputs. Evaluation on your own data is still required, and the model card's limitations section is where the publisher describes known weaknesses.
6. It does not cover private or gated content you hold. Gold lists public models. A private repository, a gated model your team was granted, or a fine tune you made in house is outside what the directory shows.
7. Counts are a snapshot. Downloads and likes are carried from the Hugging Face Hub and change daily. They describe popularity, not safety.

Common mistakes

Trusting the short license identifier. llama3 and mit look equally simple in a list. One is a permissive license with a notice requirement; the other is a community license with conditions. Open the page and read the verdict.

Treating "other" as "none". On Hugging Face, other means the author put a custom license in the repository. Skipping it because no standard identifier appears is how unreviewed terms end up in a product.

Downloading from main. The Hugging Face client downloads from the main branch by default. If you never pass a revision, a later push to the repository changes what your next build pulls.

Pinning to a tag and calling it done. A tag is better than main, but tags can be moved. A commit hash is the only reference that cannot change.

Loading pickle weights from an unknown publisher. Hugging Face's docs say loading a pickle file can run arbitrary code. If safetensors weights exist, use them; if they do not, be stricter about who published the model.

Using a personal account for gated access. The access request shares that person's details and records their acceptance. When they leave, nobody knows what was agreed.

Equating popularity with safety. High download counts mean many people use the model. They say nothing about whether its license fits your product or whether the revision you pulled is the one others reviewed.

Vetting the model and ignoring the loader. The packages that load and serve the model carry CVEs like any other dependency. Scan them with the rest of your code.

Doing the review once. Licenses change on new revisions, models get deprecated, and teams swap models without telling anyone. Put a review date in the intake record and keep an inventory after adoption.

FAQ

Is Gold Open Source free for checking AI models?

Yes. Gold Open Source is free and needs no login. The models directory at gold.safeguard.sh/models and every model page described in this post are public.

Where does the model data in Gold come from?

Safeguard's docs say the AI models section lists open weight models sourced from the Hugging Face Hub, with live download and star counts, plus notable frontier models. The Hugging Face Hub is credited as a data source on Gold's credits page.

Does Gold Open Source scan Hugging Face model files?

The model pages do not show a scan of model files. They show category, popularity, license, weights status, related models and a link to the repository. Treat them as a sourcing and license check, and run file format and loading checks yourself.

What does "Commercial use with conditions" mean on a model page?

It means the license allows commercial use but adds terms. For the Llama 3 Community License, for example, the page names an acceptable use policy, a separate license above a monthly active user threshold, and an attribution requirement. Read the full license before adopting.

What should I do when a model's license shows as "other"?

Read the license in the repository. Hugging Face asks authors who use other to add the license text to a LICENSE file and set license_name in the model card metadata. Gold marks these models "Commercial use unclear" for the same reason.

Why does Hugging Face recommend safetensors over pickle?

Hugging Face's docs explain that loading a pickle file can run arbitrary code, and describe safetensors as a format for storing tensors safely, as opposed to pickle, while staying fast. Prefer safetensors weights where they exist.

How do I pin a Hugging Face model to an exact version?

Pass the revision parameter when you download. Hugging Face's docs show it accepting a branch, a tag, a pull request reference or a commit hash. Use the full commit hash of the revision you tested.

Can Gold tell me which models my code already uses?

No. Gold is a public directory. To find the AI models and AI SDKs inside your repositories, use Safeguard AI-BOM discovery (GA) in the Safeguard platform.

Does the models directory cover API only models?

Yes, it lists notable frontier models as proprietary, with the license marked proprietary and a note that the model is API only with no published weights. For those, the review is about the provider's terms, not files.

Is the license summary on a model page legal advice?

No. Each page says it is plain language guidance, not legal advice, and tells you to confirm against the model's own license before relying on it.

The code around the model

Choosing a model is only half of an AI feature; the code that loads and serves it is made of ordinary open source packages, and those carry known vulnerabilities like any others. The block below covers how Safeguard handles that side, from finding the safe version of a dependency to fixing it when upstream has not.

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. It installs the CLI, opens the interactive terminal and asks the assistant to fix a lodash CVE in a repository: it reads the finding and advisory, asks before any command that changes something, edits package.json to the fixed version, runs the install and tests, prints a summary and pushes nothing. The same flow applies to the Python packages that load your model: scan the repository, then fix the vulnerable loader dependency with a reviewed change.

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

The second demo shows Claude with Safeguard: connecting Claude to Safeguard, signing in with OAuth and choosing which Safeguard tools Claude can use. In Claude you reach the same place by adding Safeguard from the connector directory. Once connected, a developer comparing models can ask about the vulnerabilities in the project that will load the model without leaving the chat.

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

To try it on your own code, download the Safeguard apps and CLI at https://safeguard.sh/download and read the docs at https://docs.safeguard.sh/docs . For a map of every Safeguard capability, see what Safeguard does today, and to turn your model and license rules into enforced checks, see plain English security policies to release gates in Safeguard. If the model will sit behind an LLM application, monitor before you block with the Safeguard AI Gateway covers the runtime side.

Quick check

Sources

• Gold Open Source: AI Models directory
• Gold Open Source: bge-small-en-v1.5 model page
• Gold Open Source: whisper-large-v3 model page
• Gold Open Source: Meta-Llama-3-8B model page
• Gold Open Source: FLUX.1-dev model page
• Gold Open Source: Claude Opus 4 model page
• Safeguard docs: Gold Open Source
• Hugging Face: Model Cards
• Hugging Face: Licenses
• Hugging Face: Pickle Scanning
• Hugging Face: Safetensors
• Hugging Face: Gated models
• Hugging Face: Download files from the Hub
• Hugging Face: Downloading models
• Hugging Face Transformers: Models (loading options)
• OWASP Top 10 for LLM Applications 2025: LLM03 Supply Chain
• NIST SP 800-218A: Secure Software Development Practices for Generative AI and Dual-Use Foundation Models
• NIST AI 600-1: Generative AI Profile
• NIST AI Risk Management Framework

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