Every Safeguard Integration Explained: A Hub for Each Card

Safeguard's Integrations page is a grid of cards, and each card connects one kind of source: a code host, an image registry, an AI model source, a file upload, or a posture and security test. This hub lists every card by group, gives its one line description, and links the deep dive where one is published.

Use it as a map. If you already know which system you need to connect, jump to its group. If you are planning a rollout and want to know what can be connected at all, read the groups in order, then the sections on gates, rollout order and limits at the end.

Key takeaways

• Every integration on the page is generally available (GA). That includes source code (SCM) scanning, container image scanning, AI model scanning and inventory, OpenTelemetry (OTLP) telemetry, file uploads, and every posture and security testing card, IAST included.
• The page groups cards into source code, images, AI models and providers, telemetry, uploads, Safeguard security testing and VAPT. This hub follows the same groups, folding telemetry into AI and VAPT into posture and security testing.
• SCM and image cards carry a "Set up CI/CD" link next to Docs and Connect, so the same source can be scanned from the platform and from your pipeline.
• Policies and gates (GA) sit on top of every connected source. Gate actions are Block, Warn and Notify, and approval for a known risk runs through exceptions.
• Autonomous remediation (GA) can open fix pull requests for connected repositories, and it ships switched off, with every category set to Manual.
• Each card below links to its own deep dive when that post is live. Cards without a live post are named without a link; their docs pages are the place to go for setup.

How the Integrations page is laid out

Before the card list, a short orientation, because the page has a few conventions that apply to every card.

What a card shows

Each card carries a "Secure by default" label and two actions: Docs, which opens the setup guide for that integration, and Connect (or Configure, for cards like MCP Guardrail that generate something rather than connect to something). Source code cards and image cards also show "Set up CI/CD", which leads to the pipeline guide for that host or registry.

Several cards in the AI and upload groups are tagged public or private. Public means the card works with a public URL or a file you upload. Private means you hand over a credential, usually read only, so Safeguard can see an account you own.

Where the page lives and how to filter it

The ESSCM docs describe the page as reachable from Integrations in the sidebar, with tabs for Add Project/Product, Deployment, Configure Scanner and Notification. The general integrations guide also points to Settings → Integrations for adding and managing connections. Filter buttons narrow the grid to All, Source Code (SCM), Container Image, AI Model or Upload.

The common connect flow

The ESSCM integrations guide gives one workflow that holds for most cards:

1. Open Integrations from the sidebar.
2. Pick the integration type: SCM, Container Image, AI Model or Upload.
3. Click Connect on the card.
4. Configure access: a URL for a public source, or credentials for a private one.
5. Review and connect: select the repositories or images and set project settings.
6. Find the connected sources on the Projects page.

The docs walk through a Bitbucket example. On the Public tab you give the configuration a name, paste the repository URL, wait for the page to confirm the URL is valid, and add it to the list before connecting. Private sources follow the same shape with credentials in place of a bare URL.

What every integration promises

The general integrations page in the docs lists four properties that apply to every integration. Each one authenticates with the minimum privileges it needs, uses short lived workload identity where the provider supports it, logs every action to the Safeguard audit stream, and can be disconnected with its data purged in one click. For source control specifically, the same page says write scopes are never enabled without explicit consent per repository.

Those four properties matter more than any single card, because they decide how comfortable your platform team will be connecting the next one.

Source code (SCM)

Source code cards connect a repository host so Safeguard can generate SBOMs and findings from the code itself. Each card pairs with a CI/CD route. Hosted platforms use their native pipelines; the self hosted and legacy version control cards point to Jenkins or any CI.

GitHub

Connect repository. CI/CD: GitHub Actions.

The most common starting point. The GitHub card connects repositories at the organisation level, and the Actions route runs the same scan in your pull request checks.

Bitbucket

Connect repository. CI/CD: Bitbucket Pipelines.

This is the card the docs use for their worked example of the connect flow, public and private.

GitLab

GitLab.com or self-hosted. CI/CD: GitLab CI.

One card covers both the hosted service and a self managed instance, so teams on either do not need a separate path.

Azure DevOps

Connect Azure Repos from an Azure DevOps organization. CI/CD: Azure Pipelines.

The general integrations page lists organisation or project scope, and the pipeline route runs in Azure Pipelines.

Oracle Cloud DevOps

Scan Oracle Cloud DevOps code repositories. CI/CD: Jenkins or any CI.

Deep dive: Scan Oracle Cloud DevOps repositories and OCIR images with Safeguard. The same post covers the Oracle Container Registry card in the images group.

Subversion (SVN)

Scan Subversion repositories: trunk, branches and tags, public or private, with commit hooks or polling. CI/CD: Jenkins or any CI.

Deep dive: Scan Subversion (SVN) repositories with Safeguard.

Mercurial

Scan Mercurial repositories on any server (hgweb, Heptapod, RhodeCode, SourceHut): branches, bookmarks and tags, with commit hooks or polling. CI/CD: Jenkins or any CI.

Deep dive: Scan Mercurial repositories with Safeguard.

Perforce (Helix Core)

Scan Perforce Helix Core depots and streams at a changelist, with change-commit triggers or polling; fixes as patches or shelved changelists. CI/CD: Jenkins or any CI.

Deep dive: Scan Perforce Helix Core depots and streams with Safeguard.

Git

Generic Git URL. CI/CD: Jenkins or any CI.

The catch all for any Git server that does not have its own card. Give it a URL, and the Jenkins or any CI route covers the pipeline side.

Picking among the SCM cards

The choice is usually made for you by where the code lives. Two cases need a moment of thought.

The first is a host that has its own card and also speaks plain Git. Prefer the named card. It carries the native CI route and, for the hosted platforms, the deeper connection the docs describe, such as webhooks and pull request status.

The second is a mixed estate: product code on a hosted Git platform, an older service still in Subversion, game or hardware assets in Perforce. Connect each host through its own card. The findings land in the same Projects view, and the same policies apply to all of them, so the version control system stops being the thing that decides how well a codebase is covered.

Registries and container images

Image cards scan the container images you build and store, so the SBOM and findings reflect what actually ships, not only what the source tree declares. Each image card also shows "Set up CI/CD", for scanning images as part of the build that produces them.

Amazon ECR

Use container images.

Deep dive: Scan images in Amazon ECR, Azure Container Registry, Docker Hub and GCP with Safeguard.

OCI Registry

Open Container Initiative.

The generic card for any registry that speaks the OCI distribution protocol and does not have a card of its own. There is no dedicated post for this card yet; its docs page has the setup.

Oracle Container Registry (OCIR)

Scan images in Oracle Container Registry, public or private.

Deep dive: Scan Oracle Cloud DevOps repositories and OCIR images with Safeguard.

Podman

Scan the images on a Podman host, over SSH or mutual TLS.

Deep dive: Scan Podman, Apptainer SIF and WebAssembly images with Safeguard.

Apptainer / Singularity (SIF)

Scan Apptainer and Singularity images (SIF) from a library or an OCI registry, with their signatures checked.

Deep dive: the same Podman, Apptainer SIF and WebAssembly post.

WebAssembly (Wasm)

Scan WebAssembly (Wasm) components and modules stored as OCI artifacts, public or private.

Deep dive: the same Podman, Apptainer SIF and WebAssembly post.

GCP Cloud Source

Google container sources.

Deep dive: the ECR, Azure Container Registry, Docker Hub and GCP post.

Docker Hub

Connect Docker repositories.

Deep dive: the ECR, Azure Container Registry, Docker Hub and GCP post.

Azure Container Registry

Scan container images in Azure Container Registry, public or private.

Deep dive: the ECR, Azure Container Registry, Docker Hub and GCP post.

Sonatype Nexus Repository

Scan Docker images in Sonatype Nexus Repository: hosted, proxy and group repositories, every tag, pinned to the digest.

Deep dive: Scan images in JFrog Artifactory, Sonatype Nexus, Harbor and Red Hat Quay with Safeguard.

JFrog Artifactory

Scan Docker and OCI images in JFrog Artifactory or JFrog Container Registry, SaaS or self-hosted, pinned to the digest.

Deep dive: the same Artifactory, Nexus, Harbor and Quay post.

Harbor

Scan images in Harbor projects with a robot account, every tag pinned to the digest, with Harbor's own scan shown beside ours.

Deep dive: the same Artifactory, Nexus, Harbor and Quay post.

Red Hat Quay

Scan images on quay.io or self-hosted Red Hat Quay with a robot account or OAuth token, every tag pinned to the digest.

Deep dive: the same Artifactory, Nexus, Harbor and Quay post.

Why "pinned to the digest" shows up so often

Several registry cards say every tag is pinned to the digest. A tag is a movable label; the digest is the content hash of the image. If a scan records only the tag, the result can quietly stop describing what the tag points to after the next push. Pinning to the digest ties the SBOM and its findings to the exact bytes that were scanned, which is what you want when someone later asks whether a given deployment was covered.

Registry cards versus scanning in the build

You do not have to choose. Scanning in CI catches a problem before the image is pushed. Scanning the registry covers images that were pushed before you connected anything, images built by other teams, and base images you pull but never build. Most teams end up with both: the CI route for what they build, the registry card for everything already sitting there.

AI model sources and AI telemetry

The AI cards fall into three kinds. Public model hubs, where you scan a model by URL. Private AI platforms, where Safeguard inventories what your account runs, read only. And telemetry, where your AI tools send their logs, metrics and traces to Safeguard. AI model scanning and AI inventory are both GA.

Model hubs (scan by URL or token)

Hugging Face (public)

Connect AI models.

Deep dive: Scan models from Hugging Face, Kaggle, ModelScope and Civitai with Safeguard.

Kaggle Models (public)

Scan Kaggle models: public by URL, or your own with an API token.

Deep dive: the same model hubs post.

Civitai (public)

Scan Civitai models (text only, no images; mature content marked).

Deep dive: the same model hubs post.

ModelScope (public)

Scan ModelScope models: public by URL, or your own with an SDK token.

Deep dive: the same model hubs post.

Cloud AI platforms (read only inventory and checks)

Amazon SageMaker AI (private)

Inventory SageMaker AI models, Model Registry, endpoints and JumpStart models, read-only, and check their exposure, encryption, roles and licences.

Deep dive: Inventory AI models in SageMaker, Vertex AI and Azure AI Foundry with Safeguard.

Google Vertex AI (private)

Inventory Vertex AI models, endpoints and Model Garden models, read-only, and check their exposure, encryption, identities and licences.

Deep dive: the same SageMaker, Vertex AI and Azure AI Foundry post.

Microsoft Azure AI Foundry (private)

Inventory Azure AI Foundry and Azure Machine Learning workspaces, endpoints and deployments, read-only, and check exposure, keys and roles.

Deep dive: the same SageMaker, Vertex AI and Azure AI Foundry post.

Model API and hosting providers (read only inventory)

OpenRouter (private)

Inventory OpenRouter keys, credits and model usage (read only).

Deep dive: Inventory Replicate, Together AI, Fireworks AI and OpenRouter usage with Safeguard.

Replicate (private)

Inventory your Replicate deployments, trainings and the models they use, with each model's licence and version.

Deep dive: the same Replicate, Together AI, Fireworks AI and OpenRouter post.

Together AI (private)

Inventory your Together AI dedicated endpoints and fine-tunes, with each model's licence and source.

Deep dive: the same Replicate, Together AI, Fireworks AI and OpenRouter post.

Fireworks AI (private)

Inventory your Fireworks AI models, deployments and fine-tuning jobs, with each model's source.

Deep dive: the same Replicate, Together AI, Fireworks AI and OpenRouter post.

Audit activity and telemetry

Anthropic Claude Compliance (private)

Stream Claude audit & compliance activity.

This card brings your organisation's Claude audit and compliance activity into Safeguard. The dedicated post covers it in full: Stream Claude audit and compliance activity into Safeguard.

OpenTelemetry (OTLP) (private)

Send Claude Code, Codex and any OpenTelemetry collector's logs, metrics and traces to Detection & Response and Security Operations.

Deep dive: Send Claude Code and Codex telemetry to Safeguard with OpenTelemetry (OTLP).

How the AI cards fit together

The three kinds answer different questions. The model hub cards answer "what is inside this model we want to use", before anyone deploys it. The cloud platform and provider cards answer "what models are we already running, where, under which keys and licences", which is usually the harder question for a security team that was not in the room when the endpoints were created. The telemetry cards answer "what are our AI coding tools and agents doing right now".

A useful rule: if a team cannot list which hosted models and endpoints it runs, start with the inventory cards. If the list exists but nobody has looked inside the models, start with the hub cards. If both are in hand and the worry is agent behaviour, OTLP is the next connection.

Uploads

Upload cards are for sources you cannot or do not want to connect: a vendor's binary, a single manifest, an SBOM from a supplier, a VEX statement. All five upload cards are public, meaning you bring the file.

Upload App Binary (public)

Upload and scan an app binary: Windows EXE/MSI/DLL, Android APK or iOS IPA.

Deep dive: Scan app binaries (EXE, MSI, APK and IPA) with Safeguard.

Upload Manifest File (public)

Upload and scan Manifest files.

The quickest way to check one project's declared dependencies without connecting its repository. There is no dedicated post for this card yet.

Database Change-log Scanner (public)

Review database migrations and change logs for security impact.

Deep dive: Review database migrations and change logs for security impact with Safeguard.

Upload SBOMs (public)

Upload SBOMs and scan for vulnerabilities.

This is how a supplier's SBOM, or one produced by another tool in your pipeline, becomes a project with findings. There is no dedicated post for this card yet.

Upload CSAF/VEX (public)

Upload your CSAF/VEX.

CSAF and VEX upload (GA) lets you bring in advisories and exploitability statements so findings reflect what a vendor or your own team has said about whether a product is affected. There is no dedicated post for this card yet.

When to upload instead of connect

Uploads suit one off checks and third party software. For your own code and images, a connected card is better because it rescans as things change; an upload is a snapshot. A reasonable split is to connect everything you build and upload what you receive.

Posture and security testing

This group covers the Safeguard security testing cards and the VAPT scans that run from the CLI. Most of these test something live: an application, an API, a cluster, a cloud account, a database, a network. That changes the rules of engagement, so several cards require you to verify or scope the target first.

Safeguard security testing

MCP Guardrail (Configure)

Generate guardrail proxy URLs for MCP servers.

MCP Guardrail (GA) is the one card in the grid that says Configure rather than Connect, because it produces something for you to use: a proxy URL that sits in front of an MCP server. There is no dedicated post for this card yet.

Safeguard DAST

First-party dynamic testing of verified targets.

DAST (GA) tests a running web application only after you prove you own it. The application security testing docs list DNS TXT record, uploaded file, meta tag or verified email domain as ways to verify, and active checks stay off until verification succeeds. There is no dedicated post for this card yet.

Safeguard Red Team

Defensive adversary emulation of in-scope targets.

Deep dive: Safeguard Red Team: defensive adversary emulation.

Safeguard Package Firewall

Supply-chain package firewall for dependencies.

The Package Firewall (GA) runs as an install time proxy in front of npm and pip. It blocks malicious, typosquatted and dependency-confusion packages before they reach a machine or a build, with allow, warn and block outcomes plus an audit mode for a baseline first.

Deep dive: Gate npm and pip installs by policy with the Package Firewall.

Safeguard API Security

Authenticated API testing: BOLA/IDOR, auth & data exposure.

Deep dive: Safeguard API security testing: BOLA, IDOR, auth and data exposure.

Safeguard IaC Security

Terraform, CloudFormation, Helm & Kubernetes manifest checks.

Deep dive: IaC security for Terraform, CloudFormation, Helm and Kubernetes manifests.

Kubernetes / KSPM

Cluster posture: CIS, Pod Security, RBAC & exposure.

Deep dive: Kubernetes posture (KSPM) in Safeguard: CIS, Pod Security, RBAC and exposure.

Database Security Posture

Live database posture: TLS, auth rules, grants, audit logging & encryption at rest.

Deep dive: Database security posture in Safeguard: TLS, auth, grants, audit logging and encryption.

Safeguard IAST

Scan a live app URL with a headless browser, or upload IAST results (SARIF).

Deep dive: Safeguard IAST: live app scans and SARIF upload.

Cloud Security (CSPM)

Cloud posture: AWS, Azure & GCP misconfiguration checks. Connect cloud credentials to scan.

Deep dive: Cloud security posture (CSPM) in Safeguard for AWS, Azure and GCP.

OSINT

Public footprint + data-leak/breach exposure for a domain, email or username.

Deep dive: OSINT footprint and breach exposure checks in Safeguard.

VAPT (on-prem, run from the CLI)

The VAPT cards run from the Safeguard CLI on infrastructure you own, and the ESSCM docs say results upload to your console as projects. All four are covered in one post: VAPT with the Safeguard CLI: network, device, Wi-Fi and Active Directory scans.

Network Scan

Network attack surface, service/version detection & CVE checks, run from the CLI on the target network.

Device Scan

LAN/IoT device discovery & exposure, run from the CLI on the local network.

Wi-Fi Scan

Wi-Fi posture: open/weak-encryption/rogue-AP networks in range. Requires a wireless adapter, run from the CLI on-site.

Active Directory Scan

Active Directory identity-posture review, run from the CLI with domain access.

Grouping the testing cards by what they touch

It helps to sort these cards by the thing they need access to, because that decides who has to approve the connection.

How every card feeds policies and gates

Connecting a source is half the job. The other half is deciding what happens when a finding from that source breaks a rule. That is where policies and gates (GA) come in, and they work the same way whichever card the finding came from.

The ESSCM docs separate the two. A policy is a rule that evaluates your SBOMs and produces findings: a severity ceiling, a CVSS or EPSS threshold, a licence rule, a component age or maintenance rule. A gate is the checkpoint that enforces policies, in the platform and in CI.

Each policy has an Action that decides what a failed policy does to the gate:

When a team has a legitimate reason to ship with a known finding, the route is an exception, not a weaker policy. The docs describe the flow: request an exception, pick the policy and finding, give a business justification, set an expiry date, and submit for approval. Approvers are notified, decide, and the decision is kept in the audit trail.

For pipelines, the policies and gates page says gates are evaluated by the platform on the scans it runs for your connected repositories, and that with policy outcomes on for your workspace this command fails a CI job when the gate fails:

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

We have not run that command for this post; it is shown exactly as the docs page gives it. Replace the placeholder with your gate's name. The policy outcomes page adds that the command exits zero when the gate is Passed or Warning and non zero when it is Failed, printing the Block policies that failed. It also says Notify sends to the in app bell, connected chat integrations and email, and does not repeat the same failure on every evaluation.

A practical habit: start new sources on Warn or Notify for a sprint, read what would have failed, then move the policies that matter to Block. That keeps a fresh integration from turning every build red on the first day.

Where to start: a decision table

If you are connecting Safeguard for the first time, start from the asset you most need to see, not from the order of the cards.

A rollout order that works for most teams

1. Connect one code host. Pick the host where most active code lives, connect a handful of repositories, and look at the Projects page before connecting the rest.
2. Add the CI/CD route for that host. The card's "Set up CI/CD" link leads to the pipeline guide. Run it with policies on Warn first.
3. Connect the registry your production images come from. This closes the gap between what the code declares and what the image contains.
4. Turn on the Package Firewall in audit mode. The docs recommend starting in audit mode to get a baseline before moving to warn or block.
5. Bring in what you receive. Upload supplier SBOMs and any CSAF or VEX documents you hold.
6. Inventory AI. Connect the cloud AI platform or provider cards your teams use, then the model hub cards for models under evaluation.
7. Add posture and live testing. CSPM and Kubernetes / KSPM for configuration; DAST and API Security for running applications; VAPT from the CLI for networks you own.
8. Move the policies that matter to Block. Keep exceptions for the rest, with expiry dates.

Each step stands on its own. A team that stops after step three still has a working inventory of code and images with gated pipelines.

What Safeguard does not do

• It does not see what you have not connected. A card does nothing until someone connects it, and a public card only scans the URL or file you give it. Coverage is exactly as wide as the sources you add.
• It does not test targets you do not own or have not scoped. DAST works on verified targets and Red Team on in-scope targets. Getting permission, and deciding what is in scope, stays with you.
• It does not replace the controls on the other side of a connection. Private cards read with the credentials you supply. Rotating those credentials, keeping them narrowly scoped and removing them when a project ends are still your team's jobs.
• It does not fix vendor software for you. Uploading a supplier's binary or SBOM tells you what is in it; the fix for code you do not build has to come from that supplier.
• It does not decide your risk appetite. Policies, thresholds and who may approve an exception are choices you make. Safeguard enforces them once set.
• It does not merge fixes on its own by default. Autonomous remediation ships switched off with every category on Manual, so pull requests wait for a human unless you change that.
• VAPT scans do not run from the cloud. Network, Device, Wi-Fi and Active Directory scans run from the CLI on your network, and Wi-Fi needs a wireless adapter on site.

Common mistakes

• Connecting through the generic card when a named one exists. The Git and OCI Registry cards are for hosts without their own card. A named card brings its CI route and a fuller connection.
• Scanning tags instead of digests. If your process records only tags, a later push changes what the result describes. Use the registry cards that pin to the digest.
• Turning every policy to Block on day one. The first scan of a large estate surfaces old findings. Start on Warn or Notify, then tighten.
• Treating an upload as ongoing coverage. An uploaded SBOM or binary is a snapshot. If you build it yourself, connect the source instead.
• Forgetting the AI platforms. Teams connect code and images and stop. Hosted models and endpoints often sit in a separate cloud account nobody connected.
• Using exceptions without expiry dates. An exception without an end date becomes a permanent hole. The exception form asks for an expiry for a reason.
• Handing over broad credentials. Give each private card the narrowest read only access its docs page lists. The docs say every integration authenticates with the minimum privileges it needs; your token should match.

FAQ

What integrations does Safeguard support?

The Integrations page groups cards into source code (SCM), container images and registries, AI models and AI providers, OpenTelemetry telemetry, uploads, Safeguard security testing, and VAPT scans run from the CLI. Each card is listed in this hub with its one line description.

Are all Safeguard integrations generally available?

Yes. Every card on the page is GA, including IAST, MCP Guardrail, DAST and the Package Firewall.

Can Safeguard scan repositories outside GitHub, GitLab and Bitbucket?

Yes. There are cards for Azure DevOps, Oracle Cloud DevOps, Subversion, Mercurial, Perforce Helix Core and any Git URL. The non hosted ones use commit hooks or polling, and their CI route is Jenkins or any CI.

Which container registries can Safeguard scan?

Amazon ECR, Docker Hub, Azure Container Registry, GCP container sources, Oracle Container Registry, Sonatype Nexus Repository, JFrog Artifactory, Harbor, Red Hat Quay and any OCI registry, plus images on a Podman host, Apptainer and Singularity SIF images, and WebAssembly components stored as OCI artifacts.

Does Safeguard need write access to my repositories?

Not to scan. The general integrations page says write scopes are never enabled without explicit consent per repository. Write access matters only if you want fix pull requests from autonomous remediation, which ships switched off.

How do I scan an AI model before my team uses it?

Use the Hugging Face, Kaggle Models, ModelScope or Civitai card with the model's public URL, or a token for your own private models where the card supports it. The model hubs deep dive covers the details.

Can I scan software I did not build?

Yes, through uploads. Upload App Binary takes Windows EXE, MSI and DLL files, Android APK and iOS IPA files. Upload SBOMs takes a supplier's SBOM, and Upload CSAF/VEX takes their advisories and exploitability statements.

What do Block, Warn and Notify do in a gate?

Block fails the gate. Warn passes it with a warning naming the policy. Notify passes it and sends a notification. Approval for a known finding runs through an exception with a justification and an expiry date.

What does the Package Firewall block?

It sits in front of npm and pip installs as a proxy and blocks malicious, typosquatted and dependency-confusion packages at install time. You can run it in audit mode first to see what it would have blocked.

Do VAPT scans need anything installed?

They run from the Safeguard CLI on the network you are testing. The Wi-Fi scan also needs a wireless adapter on site, and the Active Directory scan needs domain access.

Before the fixes

Every card on this page ends in the same place: a list of findings, most of them in open source dependencies and container images you did not write. The section below is how Safeguard helps close those findings once a connected source has surfaced them.

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 Safeguard CLI demo is a real terminal session: the CLI is asked to fix a lodash CVE in a repository, reads the finding and the advisory, edits package.json, runs the install and tests with approval, and pushes nothing. Since CLI v11.10.0 it asks before any command that changes something, not before every command. The CLI is also where the VAPT scans and the CI gate check run, so it is a fair picture of the command line side of this page.

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

The local runner demo shows setting up the runner on your own machine, approving it with its device code, and then scanning from the terminal. It does not show the Integrations page itself, but it shows Safeguard work running on a machine you control, which is how the on site and self hosted parts of this catalog run.

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

Quick check

Sources

• Safeguard docs: Integrations
• Safeguard docs: ESSCM Integrations
• Safeguard docs: Policies and Gates
• Safeguard docs: Package Firewall
• Safeguard docs: CI/CD Integration
• Safeguard docs: Policy outcomes and actions
• Safeguard docs: Application Security Testing (SAST and DAST)

To try any of these yourself, download Safeguard or start from the docs.

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