What Safeguard Does Today: Every Capability, Labelled GA or Early Access

Safeguard is a software supply chain security platform: it inventories what is inside the software you build and buy, ranks the vulnerabilities that matter, opens fix pull requests, enforces policy, and produces the evidence regulators and customers now ask for. The supply chain core (SBOMs, dependency scanning, reachability, remediation, policies, licenses, attestation, compliance, supplier risk and the Gold catalog) is generally available today. Newer areas such as the Trust Center, AI security engines, SAST and DAST, and the desktop and mobile apps are early access, which means real in the product but still maturing.

This post is the hub for a series of product education guides. It lists every capability with its maturity label, explains what the labels mean for a trial or a contract, and tells three kinds of buyer where to start.

Key takeaways

• The problem is regulatory as much as technical. Executive Order 14028, NIST SP 800-218 (the SSDF), OMB M-22-18 and M-23-16, and the EU Cyber Resilience Act turned "know what is in your software and fix it" into something buyers must attest to.
• Four products share one platform: ESSCM (GA), Portal (GA), TPRM (GA) and OSM (GA).
• Generally available (GA): SBOM generation and analysis; SCA, deep transitive dependency scanning and vulnerability management with EPSS and KEV; reachability analysis and prioritisation; autonomous remediation with Griffin fix pull requests (GA, ships switched off); policies, gates and guardrails, including plain English policy creation; license compliance; attestation and signing; CSAF and VEX upload; the compliance and GRC suite; TPRM; OSM, Gold Open Source and Gold Registry; the CLI, local runner, IDE extensions, MCP server and browser extension; Zero AI mode, bring your own model, on-prem and air-gapped deployment; agent identity.
• Early access: fork and patch and the OSM operating model; Trust Center; AI-BOM discovery and AI agent discovery; AI-SPM model artifact scanning; MCP Guardrail; AI Gateway (LLM firewall); SAST and DAST; self-healing containers, Guard runtime protection, PR Guard, AutoTriage and Package Firewall; in-app agentic search, Skills, Workspaces and Connectors; the desktop app and the iOS and Android apps (beta).
• GA means safe to demo and buy as shipping. Early access means scope a pilot first and write acceptance criteria before you plan around it.
• Safeguard runs where your data rules require: SaaS, private VPC, on-prem or fully air-gapped, with AI in the loop, with no LLM at all (Zero AI mode), or with your own approved model.
• Autonomous remediation ships switched off, with every category set to Manual. Nothing changes your code until you turn it on.

What problem does a software supply chain security platform solve?

Most of the code in a modern application was written by someone else: hundreds of open source packages, a base image with its own operating system packages, build actions, and increasingly AI models and agent tools. Each is a supplier, and almost none signed a contract with you.

Without a platform that tracks this, three things go wrong. You cannot answer "are we affected?" when a new vulnerability lands, because nobody has a current list of which products contain which component version. The vulnerability list you do have is too long to act on, because it includes every known CVE in every transitive dependency whether or not your code calls the affected function. And when a customer or regulator asks you to prove what you ship, the answer is a spreadsheet assembled by hand.

A software supply chain security platform closes those gaps. It keeps a software bill of materials (SBOM) for everything you build, matches components against vulnerability data, decides which findings matter, helps fix them, blocks releases that break your rules, and turns the work into evidence.

Which rules made it a buying requirement?

Executive Order 14028 (May 2021). Section 4 of the order, "Enhancing Software Supply Chain Security", told NIST to publish guidance on secure development practices. Section 4(e) lists what that guidance must cover, and it reads like a feature list for this category: automated tools that check for known and potential vulnerabilities and remediate them, operating "at a minimum prior to product, version, or update release" (4(e)(iv)); accurate and current provenance data for code and components (4(e)(vi)); "providing a purchaser a Software Bill of Materials (SBOM) for each product" (4(e)(vii)); and attesting to secure development practices and to the integrity and provenance of open source software (4(e)(ix) and (x)). Section 4(f) asked the Commerce Department to publish minimum elements for an SBOM within 60 days.

NIST SP 800-218, the Secure Software Development Framework (SSDF) version 1.1 (February 2022). The SSDF is the practice catalogue that federal attestation now points to. Several of its tasks map directly onto what a supply chain platform automates:

• PO.1.3: communicate security requirements to all third parties who provide commercial software components.
• PS.3.2: collect, safeguard, maintain and share provenance data for all components of each software release, with an SBOM given as the example.
• PW.4.1: acquire and maintain well secured software components from third parties.
• PW.4.4: verify that acquired commercial, open source and other third party components comply with your requirements throughout their life cycles.
• RV.1.1: gather information about potential vulnerabilities in the software and the third party components it uses, for example by monitoring vulnerability databases.

OMB M-22-18 (14 September 2022) and M-23-16 (9 June 2023). M-22-18 requires federal agencies to obtain a self-attestation from a software producer, conforming to the NIST guidance, before using the software. It says agencies may also require an SBOM, which must be in one of the formats named in the NTIA minimum elements report. Where a producer cannot attest to every practice, the agency can accept a Plan of Action and Milestones (POA&M). M-23-16 reset the deadlines: agencies must collect attestations for critical software three months after OMB approves the CISA common attestation form, and for all covered software six months after that approval. If you sell software to the US government, your customer now needs an attestation from you, and the SSDF is what you are attesting to.

The EU Cyber Resilience Act, Regulation (EU) 2024/2847. According to the European Commission, the CRA entered into force on 10 December 2024. Its reporting obligations, which require manufacturers to report actively exploited vulnerabilities, apply from 11 September 2026, and its main obligations apply from 11 December 2027. The Commission describes the Act as mandatory cybersecurity requirements for manufacturers covering the planning, design, development and maintenance of products with digital elements, including vulnerability handling across the product life cycle. If you place software or connected hardware on the EU market, the reporting clock is already running.

CISA Secure by Design. CISA's programme argues that the security burden belongs with the producers of technology, not their customers, and that every provider "must take ownership at the executive level". It is guidance rather than law, but it shapes procurement questionnaires. CISA's SBOM pages describe VEX as an attestation that says whether a product is affected by a known vulnerability, and CISA has published 2026 updates to the SBOM minimum elements.

Together these rules ask the same four questions of every software producer: what is in it, is it vulnerable, how do you know, and can you prove it. The table below maps them to what Safeguard does and to the work that stays with you.

No platform satisfies these rules by itself. What it can do is make the evidence a by-product of work you have to do anyway.

What are Safeguard's four products, and what job does each do?

Safeguard sells four products on one platform. They share one findings model, one policy engine and one evidence store, and every product is a section of the same web app at app.safeguard.sh. A tenant can hold any combination.

ESSCM, the Enterprise Software Supply Chain Manager (GA)

ESSCM is the flagship and where most evaluations start. It covers the software you build: source repositories, container images, AI model dependencies and CI/CD pipelines. Safeguard's ESSCM docs list GitHub, GitLab, Bitbucket and Azure Repos as source code inputs, and Docker Hub, ECR, GCR, ACR and private registries for container images. You can also upload manifest files, SBOMs, and CSAF or VEX documents.

From those inputs ESSCM builds an SBOM per project, matches components against vulnerability data, ranks findings with reachability, and offers AI Remediate, where Griffin drafts the fix. Each project has tabs for its dependencies, attestation, provenance, vulnerabilities, mitigations, security posture, code quality, suppliers and licenses, and findings. Policies and gates sit across all of it. The ESSCM docs give the getting started path as: create an account, configure credentials, generate your first SBOM, review vulnerabilities, and enable AI Remediate.

Deep dives: SBOM generation and analysis, reachability, EPSS and KEV, autonomous remediation, policies to release gates and container images per environment.

Portal (GA)

The name Portal covers two things, so it is worth being precise. In Safeguard's product material it is both the free entry point to the platform and the product you use to publish, share and manage SBOMs for people outside your company.

As a product, Portal is the SBOM command centre. Publishing moves an artifact from ESSCM into Portal and creates an immutable copy; sharing distributes that copy as it is. The Portal docs list a centralised SBOM repository organised by products, versions and teams, secure sharing with access controls, time limited links and download tracking, EO 14028 compliance verification with required field validation, and audit trails that record who accessed what and when.

As an entry point, Safeguard's product material describes a free signup that lets you scan one existing repository plus one open source repository from GitHub, GitLab or Bitbucket, one project per month, with SCA only. The Portal docs page now separates the platform's Free plan from Portal's own free rung, so when you sign up or scope a purchase, say which one you mean.

Deep dive: publish versus share and VEX and CSAF.

TPRM, the Third-Party Risk Manager (GA)

TPRM handles the software you buy. You add vendors to a directory, categorise them by risk tier, request SBOMs from them with templates and follow ups, then validate what comes back. TPRM scores each vendor (on a 0 to 100 scale where higher is better, the opposite direction to component risk scores elsewhere in the platform), uses EPSS and KEV in that scoring, and monitors continuously for new critical vulnerabilities, KEV additions and changes in risk. The TPRM docs give the starting path as: add vendors, categorise by risk tier, request SBOMs from high risk vendors, review and validate submissions, and enable continuous monitoring.

Deep dive: supplier software risk under DORA, NIS2 and M-22-18.

OSM, the Open Source Manager (GA)

OSM is open source intelligence: a package by package view of vulnerabilities with CVE, CVSS, EPSS and fixed version ranges, attestation verification (SLSA provenance and Sigstore signatures), license detection and compatibility analysis, and dependency health. It is also the front door to Gold. The Gold Directory in OSM lists packages that meet the Gold bar, and the Gold Registry serves hardened builds of them. The fork and patch flow, where Safeguard patches a vulnerable upstream package itself, is early access.

Deep dives: Gold Open Source in your workflow, reading a Gold Registry evidence page, fork and patch (early access) and open source license obligations.

Which capabilities are generally available today, and which are early access?

This is the central table of the series. Every capability carries the label Safeguard's own capability catalogue gives it. Where Safeguard's own sources disagreed with each other, the stricter label is used, and the reason is noted.

What sits in each group

The GA group is the supply chain core: the full loop from inventory to fix to evidence. If you need something in production next quarter, choose from this group.

The early access group is mostly the newer perimeter: AI and agent security, first party application testing, runtime engines, and the native apps. They are real in the app, but depth varies and some are switched on per tenant. Note that the Trust Center is early access even though the compliance suite under it is GA.

Deep dives for the early access items: Trust Center, AI-BOM discovery, MCP Guardrail, AI Gateway and the OWASP LLM Top 10, DAST scope and human approval in the desktop and mobile apps. The GA governance pieces are covered in continuous compliance and attestation and provenance.

What do GA and early access mean in practice for a buyer?

Safeguard's capability catalogue defines the two labels plainly. GA means generally available: in the product today, safe to demo, and sold as shipping. Early access means recently shipped and maturing: real in the app, but depth varies, so Safeguard positions it as "available, expanding" and offers a scoped demo before promising outcomes.

Those definitions translate into three practical rules for an evaluation.

Demo scope. For a GA capability, ask to see it on your own code or your own SBOM, not on a demo tenant. A GA reachability result on your real repository tells you far more than a polished walkthrough. For an early access capability, ask for a scoped demo against a specific use case you care about, and ask what is behind a feature flag in your tenant. Some engines are switched on per tenant, and a demo tenant may have flags on that yours will not.

Contract wording. Put GA capabilities in the order form or statement of work as deliverables. Put early access capabilities in as a named pilot with written acceptance criteria: what it must find, on which assets, by when. Do not let an early access capability carry a hard requirement in an RFP response or a security questionnaire unless Safeguard has confirmed it in writing for your case. This protects both sides; a capability that is still maturing should not become a breach of contract.

Change over time. Labels move as capabilities mature. Ask for the label at signature time, record it, and recheck it at renewal against docs.safeguard.sh.

Keep deployment readiness separate from certification. Air-gapped deployment is a GA capability; for audit and certification status, rely on Safeguard's own Trust Center wording, not on a summary.

Which surfaces can you use Safeguard from?

Every surface talks to the same platform and the same findings, so the choice is about where your people already work and where your code is allowed to go.

Web app

The web app is where the four products live. Single sign-on through SAML 2.0, OIDC and OAuth social login is available for Enterprise tenants. A global search bar accepts filter syntax across all products, so a query such as the one below, taken from the web app docs, narrows results to critical, reachable vulnerabilities in one project:

severity:critical AND reachable:true AND project:payments-service

The web app docs also note two things buyers often miss. Data residency is fixed when you sign up: US tenancy stores data in two US regions and EU tenancy in two EU regions, and moving between them needs a data migration engagement. And the web app is not built for offline use; air-gapped work runs on an air-gapped deployment instead.

CLI and local runner

The CLI scans directories, Git repositories, container images and existing SBOMs on your own machine and sends only the results to the platform. The docs show installation as:

# macOS and Linux
curl -fsSL https://cli.safeguard.sh/install | bash

# Windows
irm https://cli.safeguard.sh/install.ps1 | iex

Run safeguard to open the interactive terminal, type /login to authenticate, then /scan . to scan the current folder. The docs also list safeguard scan to build an SBOM and match it against vulnerability databases, safeguard validate for CycloneDX, SPDX and VEX documents, safeguard agent for the interactive assistant and safeguard exec for one non-interactive turn in scripts and CI. For networks with no internet access, the docs list an update command with an import option that loads a vulnerability database downloaded elsewhere:

safeguard update --import

The local runner is not a separate product. It is the same CLI: once you sign in, the machine polls the platform for scan jobs assigned to it, runs each one with its own local scan server, and uploads the resulting SBOM and findings. All traffic is outbound HTTPS that the runner opens, and nothing connects to it. For headless use the docs show:

safeguard runner start --workspace ./path/to/repo
safeguard runner status
safeguard runner stop

The docs say the runner long polls by default. On a network that forbids held connections, the docs show a poll wait option set to zero so the runner polls at a fixed interval instead, and a permission mode option that sets how much the assistant may do without asking, from supervised to autonomous:

safeguard runner start --workspace ./path/to/repo --poll-wait 0
``` The [repo connection, CLI or local runner](/resources/blog/repo-connection-cli-or-local-runner-choosing-how-safeguard-touches-your-code) guide in this series compares the three ways Safeguard can touch your code.

### IDE extensions, MCP server and browser extension

The IDE extensions put scanning and remediation inside the editor. The MCP server lets an assistant such as Claude or ChatGPT query vulnerabilities, read SBOMs and generate remediation without leaving the conversation. The download page describes adding Safeguard from Claude's connector directory with a single OAuth sign in and no API key to paste, and installing it from ChatGPT's directory. The [IDE and connector directory guide](/resources/blog/safeguard-in-your-ide-and-in-claude-and-chatgpt-connector-directories) covers both. The browser extension adds Griffin search in a side panel, and the separate Gold Open Source extension looks up a package, CVE, model or MCP server on gold.safeguard.sh without an account.

### Desktop and mobile apps (early access, beta)

The desktop app wraps the web app and adds a local panel for your filesystem, a local shell, scans and MCP servers. Safeguard's capability catalogue labels it early access and beta, as it does the iOS and Android apps, whose job today is mostly review and approval: reading findings and approving or denying a command an agent wants to run.

## How does Safeguard deploy, and can it run with no AI or with your own model?

Safeguard is cloud agnostic and offers four deployment models, all of which Safeguard's capability catalogue describes as available today (GA).

1. **SaaS.** Multi-tenant cloud with US and EU tenancy. Fastest to start.
2. **Private VPC or dedicated tenancy.** Single tenant isolation for Enterprise accounts, deployable on the major clouds.
3. **On-prem.** The full platform inside your own data centre.
4. **Air-gapped.** The complete stack, including Safeguard's own models, with no outbound connection.

The air-gapped docs explain how that last one stays current without a network. Safeguard ships a signed snapshot bundle on a cadence you choose, from hourly to quarterly. It contains vulnerability feed deltas (from sources including NVD, the GitHub Advisory Database, OSV, CISA KEV and daily EPSS), Gold artifact deltas, policy template updates and platform binaries. A receiver in your DMZ verifies the signatures and pushes deltas to the control plane, and the docs state that no component inside the perimeter ever calls outbound. Delivery can be a one-way diode, signed removable media carried by a courier, a short scheduled sync window, or a pull replica.

### The AI modes

AI is configurable per tenant, and this is the part regulated buyers usually care about most. Safeguard's capability catalogue describes four modes, all GA:

- **Full AI.** Safeguard's own models are in the loop. Griffin handles remediation and reasoning, Eagle handles discovery, and Lino (listed as Lion in the model catalogue) handles compliance mapping and narrative.
- **Zero AI.** The platform runs deterministically with no LLM anywhere in the loop. The scanners still work; you lose the AI features such as drafted fixes and natural language search.
- **Bring your own model.** Plug in a model from a provider you have already approved instead of Safeguard's.
- **Local and on-prem models.** Safeguard's models run as quantized builds inside your environment, on your GPUs, with CPU only builds available for triage and summarisation where GPU time is scarce.

The AI models docs state that customer source code, SBOMs and telemetry are never used to train shared models, that per tenant fine tunes are opt in and stay inside the tenant boundary, and that inference request bodies are not retained beyond 24 hours by default, with Enterprise tenants able to configure retention. These models are built for security work such as reachability reasoning, patch drafting and compliance mapping, not as general purpose assistants.

For the network side, Safeguard's capability catalogue describes a polling architecture with no open or persistent inbound connections, encrypted communication and tenant isolation for enterprises. The [SaaS, private VPC, on-prem or air-gapped guide](/resources/blog/saas-private-vpc-on-prem-or-air-gapped-pick-by-data-class) helps you pick by data class.

## A first evaluation, step by step

This is the shortest honest path from signup to a decision, using only flows and commands that Safeguard's docs show. Where the docs do not show a screen, the step describes the outcome instead.

1. **Decide residency and AI mode before you sign up.** Tenancy (US or EU) is fixed at signup. If your policy forbids sending code to an AI model, ask for Zero AI mode from day one rather than switching later.
2. **Sign in to the web app.** Use app.safeguard.sh for US tenancy or eu.app.safeguard.sh for EU. Enterprise tenants can configure SSO under Settings, Authentication, Single Sign-On.
3. **Get code in, one of three ways.** Connect a repository from the integrations area (the GA path for GitHub, GitLab and Bitbucket); or install the CLI and scan locally; or start the local runner if the repository must never leave your machine.
4. **Scan.** In the CLI, run `safeguard`, then `/login`, then `/scan .`. Through a repository connection, the platform scans on connect and then continuously.
5. **Read the SBOM.** Open the project and review the dependency tree, licenses and attestation. Export it in SPDX or CycloneDX if a customer has asked for one.
6. **Read the vulnerabilities in priority order.** Reachability, EPSS and KEV push the findings that are actually callable and actively exploited to the top. Use the global search filter shown earlier to see only critical, reachable issues.
7. **Write one policy and one gate.** Start with a single rule you would already enforce by hand, for example blocking a release that carries a KEV listed vulnerability on a reachable path. Remember that policies and gates are evaluated in the platform, not by the CLI.
8. **Try remediation deliberately.** Autonomous remediation ships switched off, with every category set to Manual. Turn on one category for one repository, let Griffin open a fix pull request, and review it like any other pull request before merging.
9. **Produce one piece of evidence.** Publish an SBOM to Portal, or map one framework you care about in the compliance suite, and check that the output is something your auditor or customer would accept.
10. **Record what you saw, with labels.** Note each capability's label and whether it met your criteria. That list becomes your contract scope.

## Where should each kind of buyer start?

### A small engineering team

Start with the free entry point and the CLI. Scan one repository and see whether the reachability ranked list is short enough to act on. Use [Gold Open Source](https://gold.safeguard.sh), free and without login, to look up any package or CVE. Turn on one remediation category once you trust the results, and skip the compliance suite and early access engines until you need them.

### A regulated enterprise

Settle the questions your security review will ask first: deployment (private VPC, on-prem or air-gapped), AI mode (Zero AI, your own model or Safeguard's models running locally) and whether the local runner keeps code on your machines. Then run the GA core on a representative slice of your estate: ESSCM on a few critical services, policies and gates in CI, and TPRM for your highest risk suppliers. Treat any early access capability as a separate, scoped pilot.

### A compliance lead

Start in the compliance suite (GA). Enable the frameworks you are actually audited against, connect the evidence sources that are live today (roughly 50, with more available on request), and look at which controls the platform tests automatically. Then link the supply chain evidence: SBOMs for the M-22-18 and CRA conversations, attestation for SSDF PS.3.2, supplier SBOMs from TPRM for vendor risk. If you need a public posture page, the Trust Center is early access; pilot it with one framework before you send the link to customers.

## What Safeguard does not do

Knowing the edges is as useful as knowing the features. These are the limits to plan around today.

- **It does not patch what you do not build.** When the vulnerable code lives in a vendor appliance, a hosted service or an operating system you run but do not build, the fix still has to come from that vendor or distribution. Safeguard can tell you the vulnerable component is there and track the supplier through TPRM, but it does not replace your patch process for those systems.
- **Early access items are real but uneven.** The Trust Center, AI-BOM and agent discovery, AI-SPM, MCP Guardrail, the AI Gateway, SAST and DAST, the runtime engines and the desktop and mobile apps vary in depth. Some are switched on per tenant. The AI Gateway runs in monitor mode today, with enforce mode gated and still rolling out.
- **Not every connector is live.** The compliance catalogue lists far more evidence connectors than are live today. Roughly 50 are live; the rest are built on request. Check that the systems you need are in the live set before you plan an audit around automated evidence.
- **Reachability is not equal across languages.** The docs mark static reachability for Ruby and PHP, and both static and dynamic reachability for Swift and Objective-C, as Preview. Findings the analyser cannot decide, for example through reflection or native code, are marked unknown and treated as potentially reachable.
- **Pipeline configuration checks are not in the app yet.** The docs describe CI/CD Security rules for GitHub Actions and GitLab CI files, but state that the feature is not offered in the app at the moment. Running a Safeguard scan inside your pipeline is a different, available feature.
- **The REST API is not the integration path today.** Several docs pages describe `/v1` REST endpoints that are not yet available. Use the web app, CLI, CI integration or MCP server instead.
- **It does not file your regulatory reports or sign your attestations.** Safeguard can produce the SBOMs, vulnerability records and evidence behind an M-22-18 attestation or a CRA report. A named person at your company still signs the attestation and submits the report.
- **Remediation does nothing until you turn it on.** Autonomous remediation ships switched off. Even when enabled, a pull request is a proposal; your review and your tests decide what merges.

## Common mistakes

**Treating the whole platform as one maturity level.** The core is GA and the perimeter is early access. A procurement checklist that ticks "AI Gateway: yes" on the strength of a demo has turned a pilot into a commitment.

**Choosing the tenancy region late.** Residency is fixed at signup. Teams that sign up on the default and then discover an EU data requirement face a migration engagement.

**Expecting the CLI to enforce gates.** Gates are evaluated in the platform, so a pipeline that only runs a local scan has not enforced anything yet.

**Turning on every remediation category at once.** Start with one category on one repository, read the pull requests, then widen. The default is Manual for a reason.

**Saying "Portal" without saying which one.** The free entry point and the SBOM publish and share product share a name. Be specific in tickets, purchase orders and internal docs.

**Reading framework coverage as evidence coverage.** Automated evidence depends on which connectors are live for your systems.

## FAQ

### What does Safeguard do?

It secures the software you build and buy: SBOMs, dependency and image scanning, reachability ranked vulnerabilities, fix pull requests, policies and gates, licenses, attestation, supplier risk and compliance mapping. Those core capabilities are GA.

### Is Safeguard generally available or still in beta?

Both, depending on the capability. The supply chain core and the four products (ESSCM, Portal, TPRM, OSM) are GA. The Trust Center, AI security engines, SAST and DAST, runtime engines and the desktop and mobile apps are early access, and the desktop and mobile apps are labelled beta.

### What is the difference between ESSCM, Portal, TPRM and OSM?

ESSCM secures the software you build. Portal publishes and shares SBOMs with people outside your company, and is also the name of the free entry point. TPRM manages the risk in software you buy from vendors. OSM gives package level intelligence on open source and leads into the Gold catalogue of hardened components.

### Can Safeguard run without sending my code to an AI model?

Yes. Zero AI mode (GA) runs the platform deterministically with no LLM in the loop. You can also bring your own approved model, or run Safeguard's models inside your own environment. The local runner (GA) keeps source code on your machine and uploads only the SBOM and findings.

### Does Safeguard support air-gapped deployment?

Yes, air-gapped deployment is GA. Updates arrive as signed snapshot bundles on a cadence you choose, verified by a receiver in your DMZ, and the docs state that nothing inside the perimeter calls outbound. Safeguard's own models can run inside the perimeter as quantized builds.

### Does Safeguard automatically change my code?

Not by default. Autonomous remediation (GA) ships switched off, with every category set to Manual. When you enable it, Griffin opens pull requests that you review and merge through your normal process.

### Which SBOM formats does Safeguard support?

SPDX and CycloneDX, for both import and export, plus many other export formats for reporting. The CLI's `safeguard validate` command checks CycloneDX, SPDX and VEX documents.

### Can I use Safeguard from Claude or ChatGPT?

Yes. The MCP server (GA) lets an assistant query findings, read SBOMs and generate remediation. Safeguard is listed in the Claude connector directory as a community connector, and the download page describes installing it from ChatGPT's directory as well.

### Is there a free way to try Safeguard?

Yes. Gold Open Source at gold.safeguard.sh is free and needs no login. The platform also has a free entry point: a free signup that lets you scan one existing repository plus one open source repository from GitHub, GitLab or Bitbucket, one project per month, with SCA only.

## Fix it without waiting for upstream

Every capability in this post exists to shorten the time between "this component is vulnerable" and "the fixed version is running in production". The block below is how Safeguard approaches that gap, from the GA remediation and Gold catalogue to the early access fork and patch flow.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

### 1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

### 2. Gold Open Source: the safe version in seconds, free

[gold.safeguard.sh](https://gold.safeguard.sh) is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The `safeguard-sh/gold-scan-action` GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

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

[registry.safeguard.sh](https://registry.safeguard.sh) provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

| Your situation | What to use |
|---|---|
| A fixed version exists | Autonomous remediation opens the upgrade pull request; Gold Open Source confirms the safe version |
| You need to know today whether you are affected | Gold Open Source lookup and "Am I affected?" checker, free and without login |
| You want vulnerable versions to stop shipping | The Gold scan GitHub Action in CI, plus Safeguard policies and gates |
| Upstream has no fix yet, or will not ship one | A custom Gold request; fork and patch (early access) |
| You want to start clean on new projects | Pull hardened components and images from Gold Registry |

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 CLI demo is a real terminal session: install, run `safeguard` to open the interactive terminal, and ask it to fix the lodash CVE in a repository. It reads the finding and the advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing, then shows `/permissions`, `/model` and `/scan .`. It shows the GA scan and fix loop on one repository, steps four to eight of the evaluation above.

<iframe src="/demos/safeguard-cli-in-action/embed" title="Interactive demo: Safeguard CLI in action" width="100%" height="560" loading="lazy" allowFullScreen></iframe>

Click through it at your own pace, or [open it full screen](/demos/safeguard-cli-in-action).

The Claude demo connects Claude to the Safeguard MCP server with OAuth and then chooses which tools Claude can use. If your team already works inside an assistant, this is how the GA MCP server brings Safeguard's findings into that conversation without a new interface to learn.

<iframe src="/demos/claude-with-safeguard/embed" title="Interactive demo: Claude with Safeguard" width="100%" height="560" loading="lazy" allowFullScreen></iframe>

Click through it at your own pace, or [open it full screen](/demos/claude-with-safeguard).

The desktop app demo is a real session in the early access desktop app: the CLI session shows in the conversation list, you ask for work on your computer, pick the folder, then Approve or Deny each command and file edit, and it ends with the upgrade done and tests passing. It shows what human approval looks like when an assistant works on a local repository.

<iframe src="/demos/safeguard-desktop-app-in-action/embed" title="Interactive demo: Safeguard desktop app in action" width="100%" height="560" loading="lazy" allowFullScreen></iframe>

Click through it at your own pace, or [open it full screen](/demos/safeguard-desktop-app-in-action).

To try it yourself, download the CLI or an app from [safeguard.sh/download](https://safeguard.sh/download) and start with the [Safeguard docs](https://docs.safeguard.sh/docs). For more background, see [what is Safeguard](/resources/blog/what-is-safeguard-questions-answered), [how Safeguard works](/resources/blog/how-safeguard-works-faq), the [platform FAQ](/resources/blog/safeguard-platform-faq) and [which Safeguard surface should I use](/resources/blog/which-safeguard-surface-should-i-use).

## Quick check

<details>
<summary>A vendor demo shows Safeguard's AI Gateway blocking a prompt injection. Can you list "LLM firewall enforcement" as a delivered requirement in your contract?</summary>

Not as a GA deliverable. The AI Gateway is early access, it runs in monitor mode today, and enforce mode is gated and rolling out. Write it into the contract as a scoped pilot with acceptance criteria, and recheck its label at signature time.

</details>

<details>
<summary>Your bank will not let any vendor clone its repositories or send code to an outside AI model. Which Safeguard options cover both constraints?</summary>

The local runner, which scans on your own machine and uploads only the SBOM and findings, combined with Zero AI mode, which runs the platform with no LLM in the loop. Both are GA. Private VPC, on-prem or air-gapped deployment are further options if the platform itself must sit inside your perimeter.

</details>

## Sources

- [Safeguard docs: About Safeguard](https://docs.safeguard.sh/docs)
- [Safeguard docs: Product Offering](https://docs.safeguard.sh/docs/product-offering)
- [Safeguard docs: Web Application](https://docs.safeguard.sh/docs/web-app)
- [Safeguard docs: Enterprise Software Supply Chain Manager](https://docs.safeguard.sh/docs/esscm)
- [Safeguard docs: Portal](https://docs.safeguard.sh/docs/portal)
- [Safeguard docs: Third Party Risk Manager](https://docs.safeguard.sh/docs/tprm)
- [Safeguard docs: Open Source Manager](https://docs.safeguard.sh/docs/osm)
- [Safeguard docs: Vulnerability Prioritization (Reachability Analysis)](https://docs.safeguard.sh/docs/reachability-analysis)
- [Safeguard docs: Safeguard CLI](https://docs.safeguard.sh/docs/cli)
- [Safeguard docs: Local Runner](https://docs.safeguard.sh/docs/runner)
- [Safeguard docs: Desktop Application](https://docs.safeguard.sh/docs/desktop-app)
- [Safeguard docs: CI/CD Security](https://docs.safeguard.sh/docs/cicd-security)
- [Safeguard docs: Air-Gapped Deployment](https://docs.safeguard.sh/docs/air-gapped-deployment)
- [Safeguard docs: AI Models](https://docs.safeguard.sh/docs/ai-models)
- [Safeguard: All Products](https://safeguard.sh/products)
- [Safeguard: Capabilities](https://safeguard.sh/capabilities)
- [Safeguard: Download](https://safeguard.sh/download)
- [Safeguard: MCP](https://safeguard.sh/mcp)
- [Gold Open Source](https://gold.safeguard.sh)
- [Executive Order 14028, Improving the Nation's Cybersecurity (Federal Register, via GovInfo)](https://www.govinfo.gov/content/pkg/FR-2021-05-17/html/2021-10460.htm)
- [NIST SP 800-218, Secure Software Development Framework Version 1.1](https://csrc.nist.gov/pubs/sp/800/218/final)
- [NIST SP 800-218 full text (PDF)](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-218.pdf)
- [OMB M-22-18, Enhancing the Security of the Software Supply Chain through Secure Software Development Practices (PDF)](https://bidenwhitehouse.archives.gov/wp-content/uploads/2022/09/M-22-18.pdf)
- [OMB M-23-16, Update to Memorandum M-22-18 (PDF)](https://bidenwhitehouse.archives.gov/wp-content/uploads/2023/06/M-23-16-Update-to-M-22-18-Enhancing-Software-Security.pdf)
- [European Commission: Cyber Resilience Act](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act)
- [CISA: Secure by Design](https://www.cisa.gov/securebydesign)
- [CISA: Software Bill of Materials](https://www.cisa.gov/sbom)
- [CISA: Known Exploited Vulnerabilities Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)
- [FIRST: Exploit Prediction Scoring System](https://www.first.org/epss/)
- [SLSA v1.0: Security levels](https://slsa.dev/spec/v1.0/levels)
- [CycloneDX specification overview](https://cyclonedx.org/specification/overview/)
- [SPDX specifications](https://spdx.dev/use/specifications/)

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