Every Language and Ecosystem Safeguard Supports Today: A Complete Map

Safeguard's software composition analysis (SCA, GA) covers eight language ecosystems today: npm, pnpm and Yarn for JavaScript and TypeScript, PyPI for Python, Maven and Gradle for Java and Kotlin, Go modules, Cargo for Rust, NuGet for .NET, Composer for PHP and Bundler for Ruby, plus the packages found inside container image layers. Static application security testing (SAST, GA) covers JavaScript and TypeScript, Python and Java. The Safeguard CLI support matrix lists more package managers again, and this post shows each one with the label it has earned.

The map below is built only from two kinds of source: Safeguard's public documentation at docs.safeguard.sh and Safeguard's own offering files. Where those sources disagree, the map uses the stricter label and a numbered note in the conflicts section explains why. If a row does not appear here, do not assume Safeguard covers it.

Key takeaways

• SCA is GA for eight ecosystems. The SCA docs page and the offering files agree on npm, pnpm and Yarn, PyPI, Maven and Gradle, Go modules, Cargo, NuGet, Composer and Ruby Bundler, plus components inside container image layers.
• Deep dependency scanning is GA. Safeguard resolves the full transitive graph for the same eight ecosystems and keeps the path from your project root to each vulnerable package. Safeguard markets the depth as up to 100 levels.
• Vulnerability management is GA, with EPSS and CISA KEV enrichment on every finding.
• Reachability analysis and prioritisation is GA in every language the docs list: JVM languages, Python, JavaScript and TypeScript, Go, Rust, C and C++, C# and .NET, Ruby, PHP, and Swift and Objective-C. The docs add per language notes, such as conservative resolution for Ruby metaprogramming.
• SAST is GA for JavaScript and TypeScript, Python and Java. Other languages are "more to follow" in the docs.
• DAST is GA and is language agnostic, because it tests a running, verified target rather than source.
• License compliance is GA across every ecosystem SCA resolves, plus Linux package copyright files inside container layers.
• Autonomous remediation and Griffin fix pull requests are GA but ship switched off, with every category set to Manual. The AI Remediate docs list full support for the same eight ecosystems.
• The CLI, the local runner, IDE extensions and the MCP server are GA. The CLI support matrix lists further package managers (Swift, C and C++, Elixir, Haskell, Erlang and others) that the SCA page and offering files do not name. This map shows those separately and asks you to confirm them in a trial.
• SBOM generation and analysis is GA for CycloneDX and SPDX, in and out.

Why does a language and ecosystem map matter?

A security tool's language list is the first thing that decides whether it fits your estate, and it is the thing vendors are most tempted to round up. A product that "supports Python" might read requirements.txt but not poetry.lock. It might match vulnerabilities for a language but have no reachability analysis there. It might scan the source of one language and only the dependencies of another. Each of those gaps changes what your team still has to do by hand.

The cost of getting this wrong is quiet. A scanner that does not understand a lockfile does not usually fail loudly. It reports fewer findings, and fewer findings look like good news. You discover the gap later, when an advisory lands for a package your scanner never saw.

What the standards expect

Several standards and government programmes make a complete component inventory a baseline expectation rather than a nice extra.

• OWASP Top 10:2025. The 2025 list includes A03:2025 Software Supply Chain Failures. OWASP's guidance for it includes continuously monitoring CVE, NVD and OSV sources for the components you use and using software composition analysis or SBOM tools to automate that work. That only works for the ecosystems your tool actually reads.
• Executive Order 14028 and the NTIA minimum elements. The order directed the Department of Commerce, with NTIA, to publish the minimum elements for a software bill of materials. NTIA published that report on 12 July 2021. An SBOM that silently omits one of your ecosystems is not a complete record of what you ship.
• CISA's SBOM programme. CISA describes an SBOM as a key building block in software security and supply chain risk management, and as a nested inventory, a list of ingredients that make up software components. Nested is the important word: transitive dependencies count.
• NIST SP 800-218, the Secure Software Development Framework (SSDF) version 1.1, published February 2022. NIST describes it as a core set of high level secure software development practices that also give buyers and suppliers a common vocabulary during acquisition. Expect supplier questionnaires built on it to ask what your tooling covers.
• FIRST EPSS and the CISA KEV catalog. EPSS publishes a daily probability that a CVE will be exploited in the wild in the next 30 days. CISA calls KEV the authoritative source of vulnerabilities exploited in the wild and says organisations should use it as an input to vulnerability prioritisation. KEV entries now point federal agencies to BOD 26-04, Prioritizing Security Updates Based on Risk, which replaced the older BOD 22-01 regime. Both signals only help if the vulnerable component was detected in the first place.

How ecosystems are named in the data

Two open specifications explain why "language" is the wrong unit and "ecosystem" is the right one. The Package URL (purl) specification identifies a package as scheme:type/namespace/name@version, with types such as npm, pypi and maven. The OSV schema, used across open source vulnerability databases, records an ecosystem field on every affected package. Vulnerability matching happens per ecosystem and per package manager, not per programming language. Kotlin code built with Gradle resolves from Maven repositories; TypeScript code resolves from the npm registry whichever of npm, Yarn or pnpm installed it.

Safeguard's deep dependency scanning docs say each node in the graph is resolved by purl and version against Safeguard's vulnerability knowledge graph. That is why the map below is organised by ecosystem and package manager, with the language as a label.

How this map was built

Every row comes from one of these sources, in this order of authority:

1. Safeguard's offering files, the internal source of truth for what Safeguard sells and at what maturity. They list SCA ecosystems, the SAST languages and the remediation ecosystems.
2. docs.safeguard.sh pages: the CLI support matrix, Software Composition Analysis, Deep Dependency Scanning, Vulnerability Prioritization (Reachability Analysis), Application Security Testing (SAST and DAST), License Compliance, AI Remediate, Generate SBOM, Container Images and the CI/CD container images page.

The rules were simple. A row is marked GA only when the offering files and the SCA docs page both name it. A row that only the CLI support matrix names is shown in a separate table, labelled "CLI matrix only, confirm", because the platform SCA page does not list it. Where two pages disagree on a detail, the stricter reading wins and the disagreement is listed in the conflicts section. Nothing here comes from reading product source code.

The map: ecosystems Safeguard covers today

This is the core table. Every capability carries its maturity label. "Not listed" means no Safeguard docs page or offering file names that combination today, so do not plan around it.

Notes for the table: the SCA docs say manifests and lockfiles are both honoured, so resolution matches what actually installs. Dynamic reachability relies on a runtime collector recording which modules and functions load in your workloads, so it only applies where you run that collector. The license column means the license data Safeguard computes per component; policy enforcement on top of it is covered under license compliance below.

Ecosystems the CLI support matrix lists, which the SCA page does not

The CLI support matrix marks each of these "Full Support" (Go Dep is "Limited Support"), but PDM and Paket files are listed in docs, not read by the CLI today. The platform SCA page and the offering files do not name them. Treat them as CLI matrix only, confirm until a trial on your own repositories shows the findings you expect (note 1).

Kotlin through Gradle sits in both tables on purpose. Gradle is in the confirmed SCA set, so a Kotlin project built with Gradle is covered; the separate Kotlin line in the CLI matrix simply names the Kotlin DSL file.

Ecosystem by ecosystem

Each of the eight confirmed ecosystems has its own detailed post in this series. The notes below cover only what matters for choosing and deploying.

JavaScript and TypeScript

npm, Yarn (Classic and Berry) and pnpm are all named with their lockfiles. The deep dependency docs say Safeguard resolves workspaces, peer dependencies and optional dependencies. Reachability is GA for both static and dynamic analysis, and the docs say it handles CommonJS, ESM and webpack bundles. It is also one of the SAST languages, so, as with Python and Java, you can see SCA (GA) and SAST (GA) findings side by side today. Detail: SCA for JavaScript and TypeScript in Safeguard and SAST for JavaScript and TypeScript in Safeguard.

Python

The CLI matrix lists pip, Pipenv and Poetry, and the deep dependency page additionally lists uv.lock and pyproject.toml; uv.lock is listed in docs, not read by the CLI today. Reachability is GA for both modes and the docs say it handles virtualenv layouts. Python is one of the SAST languages (GA). AI Remediate lists pip, poetry and pipenv; it does not list uv, Conda or PDM. Detail: SAST for Python in Safeguard and SCA for Python in Safeguard.

Java and Kotlin

Maven and Gradle are confirmed, including gradle.lockfile. The reachability table groups Java, Kotlin and Scala as JVM and marks both modes GA, with "high fidelity analysis of compiled code". Java is one of the SAST languages (GA); Kotlin is not named for SAST. Detail: SAST for Java in Safeguard and SCA for Java and Kotlin in Safeguard.

Go

Go modules with go.mod and go.sum are confirmed. Reachability is GA for both modes and described as module aware. The legacy Dep tool appears in the CLI matrix as Limited Support only. Go is not a listed SAST language. Detail: SCA for Go modules in Safeguard.

Rust

Cargo with Cargo.toml and Cargo.lock is confirmed, with GA reachability for both modes described as Cargo aware call path extraction. Detail: SCA for Rust in Safeguard.

C# and .NET

NuGet with project files and packages.lock.json is confirmed, and reachability is GA for both modes and described as NuGet aware. Paket (listed in docs, not read by the CLI today), *.deps.json, and Visual Basic and F# project files appear only in the CLI matrix. Detail: SCA for .NET and C# in Safeguard.

Ruby

Bundler with Gemfile.lock is confirmed. Static and dynamic reachability are both GA. The docs describe the static analysis as "conservative resolution for metaprogramming", which means more findings may come back Unknown and be treated as potentially reachable. Detail: SCA for Ruby in Safeguard.

PHP

Composer with composer.lock is confirmed. Static and dynamic reachability are both GA; the docs describe it as Composer aware and Symfony and Laravel aware. Detail: SCA for PHP in Safeguard.

Reachability by language: what the docs say per language

Reachability analysis and prioritisation is GA as a capability. The docs add a note per language, because call graphs are easier to build for some languages than others.

Safeguard sorts each finding into one of four classes: reachable, conditionally reachable, unreachable, or unknown. Unknown covers cases the analyser cannot decide, such as dynamic dispatch, reflection or native code, and Safeguard marks those conservatively as potentially reachable. Where the docs note conservative resolution, as for Ruby metaprogramming, expect more Unknown verdicts, and you should not treat an unreachable verdict as the only reason to defer a KEV listed finding.

Two cautions about this table. First, C and C++ and Swift have reachability rows, but their package managers are in the "CLI matrix only, confirm" group, so the reachability label alone does not tell you SCA covers your C++ or Swift project (note 4). Second, Elixir, Haskell and Erlang have no reachability row at all.

For how reachability combines with EPSS, KEV and business context into one priority score, see prioritise vulnerabilities with reachability, EPSS and KEV in Safeguard.

SAST languages and DAST

SAST and DAST are both GA. Safeguard's Application Security Testing page says the platform wiring, the unified findings model and the DAST safety controls are in place, and that detection depth expands over time (note 6).

The CLI command the docs show for SAST is:

safeguard appsec sast --dir ./src --tenant-id <tenant> --product-id <product>

The docs also say there is no CLI command for listing AppSec findings yet; you read them in the app's AppSec views. The CWE mapping lines up with lists such as MITRE's 2025 CWE Top 25, which is a reasonable way to sort SAST output once you have it.

If your main language is Go, Rust, C#, Ruby or PHP, Safeguard's SAST does not cover your first party code today. SCA still covers your dependencies in those ecosystems at GA. For DAST scope and safety controls, see Safeguard DAST scope: verified targets. For API targets, see DAST for APIs from an OpenAPI spec in Safeguard.

Containers and operating system packages

SCA covers components inside container image layers at GA. The Container Images docs say Safeguard analyses base image layers, packages from package managers such as apt, yum, apk, npm and pip, application dependencies, configuration and manifest files, and embedded binaries. In practice that means one image scan returns both the Debian, Red Hat family or Alpine packages in the base image and the language packages your build copied in.

Where you connect images from depends on the surface:

The CLI usage docs add that safeguard scan --image can read local Podman images and OCI or Docker archives as well as registry references. Two related posts go further: scan container images in Safeguard and track container images per environment in Safeguard.

Binaries and SBOM formats

Not every component arrives through a lockfile. The offering files list "Artifactory and binaries" as one of the scan input types, and the CLI support matrix names the formats:

Binary analysis finds known components from what is embedded in the file. It is a different, usually less complete, view than reading a lockfile, so prefer the source scan where you have the source (note 7).

For SBOMs, SBOM generation and analysis is GA. The CLI matrix lists these inputs and outputs:

CycloneDX is standardised as ECMA-424 and SPDX as ISO/IEC 5962:2021, according to their own specification pages. Importing a supplier's SBOM is the way to cover an ecosystem you cannot scan from source: Safeguard matches the components the SBOM lists, whatever language produced them. CSAF and VEX upload (GA) sits alongside this for stating that a CVE does not affect you; see ingest and share VEX and CSAF in Safeguard.

Where you can run Safeguard

"Supports a language" also means "runs where that team works". These are the surfaces the docs and offering files name.

To connect repositories for continuous scans instead of scanning locally, see connect GitHub to Safeguard and connect GitLab to Safeguard. For IDE and assistant setup, see Safeguard in your IDE and in Claude and ChatGPT connector directories.

Step by step: check your own stack against the map

This walkthrough uses only commands that Safeguard's docs show, plus ordinary shell commands for finding files in your repository.

1. List the lockfiles and manifests you actually ship. In each repository, find what the build reads. A plain shell search is enough:

   git ls-files | grep -E '(package-lock\.json|yarn\.lock|pnpm-lock\.yaml|bun\.lockb|requirements\.txt|Pipfile\.lock|poetry\.lock|uv\.lock|pdm\.lock|pom\.xml|build\.gradle(\.kts)?|gradle\.lockfile|go\.sum|Cargo\.lock|packages\.lock\.json|\.csproj|Gemfile\.lock|composer\.lock|Package\.resolved|Podfile\.lock|conan\.lock|vcpkg\.json|mix\.lock|rebar\.lock|Dockerfile)$'
   

2. Sort each file into one of three buckets. Confirmed (the core map table), CLI matrix only (the second table), or not listed. Put uv.lock, pdm.lock and Paket files in the last bucket: they are listed in docs, not read by the CLI today. Anything not listed needs a different plan, such as importing an SBOM your build tool generates.

3. Install the CLI and sign in. The CI docs show the install script, and the CLI usage docs show sign in through an OAuth device code flow:

   curl -fsSL https://cli.safeguard.sh/install | bash
   safeguard login
   safeguard whoami
   

4. Scan one repository locally. safeguard scan builds an SBOM, matches it against vulnerability databases and writes JSON results under ./output by default. To resolve transitive dependencies to a chosen depth, the deep dependency docs show the flags below. The CLI default depth is shallower than 100, so set it explicitly when depth matters:

   safeguard scan --dir .
   safeguard scan --dir . --resolve-transitive --transitive-depth 100
   

   Results include vuln.json, license.json and collection.json in a folder per scan. The CLI docs say --resolve-transitive resolves transitive dependencies through deps.dev, which matters if you plan an air gapped run.

5. Check what was found, ecosystem by ecosystem. Open the results and confirm each lockfile from step 1 produced components. For a CLI matrix only ecosystem, this is the trial that tells you whether it works for your projects. An empty result for a file you know has dependencies is the signal to raise with Safeguard before you rely on it.

6. Put the results in the platform. The CLI usage docs say that to see results alongside your other projects, you scan from the interactive terminal while signed in; the runner uploads the SBOM and findings, never your source:

   safeguard
   

   Then type /login if needed and /scan . in the terminal.

7. Scan your container images. Locally, or in CI per environment:

   safeguard scan --image nginx:latest
   safeguard ci scan --image "ghcr.io/acme/api:$TAG" --environment prod --wait --fail-on critical
   

   The CI form needs a key with scans:trigger and scans:read, stored as SAFEGUARD_API_KEY, per the CI/CD container images docs.

8. Bring in SBOMs for anything you cannot scan from source. Validate first, then scan:

   safeguard validate sbom.json --strict -o report.json
   safeguard scan --sbom sbom.json
   

9. Read reachability with its label in mind. In ESSCM, the Vulnerabilities tab has Priority and Reachability columns. The docs list filters such as reachable:true, kev:true and epss:>0.3. For Ruby, PHP and Swift, read the docs' per language notes and expect more Unknown verdicts.

10. Add SAST (GA) where the language fits. For JavaScript and TypeScript, Python or Java, add a Safeguard SAST integration from the Integrations page, or run the safeguard appsec sast command shown earlier, and read findings in the AppSec views.

11. Decide on fix pull requests. For the eight ecosystems in the AI Remediate table, Griffin can open fix pull requests (GA). Autonomous remediation ships switched off, every category set to Manual, so nothing opens until you turn a category on. See autonomous remediation in Safeguard.

12. Gate in the platform, not in the scan exit code. The CLI docs say safeguard scan exits 0 when the scan ran whatever it found, 1 when the command failed, and 2 when results were written but the vulnerability scan did not run. There is no severity threshold flag on safeguard scan; gating is done by policy gates in the platform (GA). See plain English security policies to release gates in Safeguard.

What the output looks like

The deep dependency docs show the transitive path view you get when you click a finding in ESSCM:

your-app
  └─ @company/tools @2.1.0
     └─ lodash @4.17.21      ← vulnerable here (CVE-2021-23337)

The same docs say the view explains the chain of imports, whether the chain is reachable, whether an alternative path exists, and what the safe version would be. The SCA docs list what each finding carries: the component and version, CVE or GHSA identifiers, severity with EPSS and KEV context, the full transitive path, the reachability verdict where available, and the safe upgrade target.

Decision table: your stack, what you get today, what you still own

Where the sources disagree

These are the conflicts found while building the map, and how each one was resolved. In every case the stricter reading is the one in the tables above.

1. CLI matrix versus SCA page. The CLI support matrix marks Bun, Conda, PDM, SBT, Paket, *.deps.json, Swift PM, CocoaPods, Conan, vcpkg, Mix, Cabal, Stack and Rebar3 as Full Support, and Go Dep as Limited. The SCA docs page and the offering files list eight ecosystems and do not name these. Resolution: shown separately as "CLI matrix only, confirm", not as GA. PDM and Paket files are additionally marked listed in docs, not read by the CLI today.
2. uv, PDM and Paket. The deep dependency docs list uv.lock, and the CLI support matrix lists pdm.lock and Paket files, but the CLI does not read any of the three today. Resolution: all three are marked listed in docs, not read by the CLI today; no SCA or fix PR claim is made for them.
3. Python, .NET and JavaScript extras. Conda, PDM, Paket and Bun appear only in the CLI matrix and not in the AI Remediate table. Resolution: no fix PR claim for them.
4. Reachability rows without a confirmed SCA ecosystem. The reachability table lists C and C++ as GA and Swift and Objective-C as GA, but the SCA page and offering files do not list their package managers. Resolution: the reachability label is shown, and the SCA row is "CLI matrix only, confirm".
5. Reachability per language. The offering files mark reachability GA as a capability without a per language grade, while the reachability docs page grades Ruby, PHP and Swift static analysis differently from the other languages. Resolution: GA for every listed language, as Safeguard now states, with the docs' per language notes kept.
6. SAST and DAST maturity. The offering files differed on the SAST and DAST label. Resolution: GA, as Safeguard now states, with the SAST language list exactly as the docs give it.
7. Binary formats. The offering files name "Artifactory and binaries" as an input type but do not list formats; the CLI matrix lists them. Resolution: formats shown from the CLI matrix, with the caution that binary analysis is a partial view.
8. SPDX serialisations. The offering files describe SPDX as JSON, XML and RDF. The CLI support matrix lists SPDX JSON, tag-value and RDF and does not list SPDX XML. Resolution: the docs list is used and SPDX XML is not claimed.
9. How the CLI is packaged. One offering file describes the CLI as a Node.js package; the CLI support matrix and CI docs describe a static binary installed by a script for five OS and architecture targets. Resolution: the docs description is used for install steps.
10. Container registry lists. The Integrations page names four registry cards, the CLI matrix names ten registries, and the CI docs mention further registry cards. These are different surfaces rather than a contradiction, so each is listed against its own surface.

What Safeguard does not do

• It does not scan every language. Elixir, Haskell and Erlang appear only in the CLI matrix, with no reachability and no fix PR support listed. Languages with no package manager in the CLI matrix and no row on the SCA page are not covered from source.
• SAST does not cover most languages yet. It is GA for JavaScript and TypeScript, Python and Java. Go, Rust, C#, Ruby, PHP, Kotlin, Swift and C and C++ first party code have no SAST row today.
• Reachability is not equally strong everywhere. The docs note conservative resolution for Ruby metaprogramming, and every language can return Unknown for reflection, dynamic dispatch or native code. A reachability verdict ranks work; it does not prove a finding is safe to ignore.
• The safeguard scan command does not fail a build on findings. It exits 0 whatever it finds. If you want a pipeline to stop, use policy gates in the platform or the --fail-on flag that the CI image scan docs show for safeguard ci scan.
• Fix pull requests do not cover every package manager. The AI Remediate table lists npm, yarn, pnpm, pip, poetry, pipenv, Maven, Gradle, Go modules, Cargo, Bundler, NuGet and Composer. Nothing else is listed, and autonomous remediation ships switched off with every category set to Manual.
• It does not patch what you do not build. Host kernels outside your images, vendor appliances and hosted services still need fixes from their vendors.
• It does not replace an accurate SBOM from your suppliers. For third party software, coverage is only as good as the SBOM you receive.

Common mistakes

• Reading "supports Python" as "supports my Python". Check your exact lockfile against the map. A Poetry project and a Conda project sit in different rows with different labels.
• Scanning manifests without lockfiles. A manifest states ranges; a lockfile states what installed. The SCA docs say both are honoured; give Safeguard both so resolution matches what actually ships.
• Treating the reachability table as the SCA table. C and C++ have a GA reachability row, but their package managers are CLI matrix only. Confirm SCA first.
• Treating reachability notes as fine print. For Ruby, PHP and Swift, read the docs' per language notes, expect more Unknown verdicts and keep KEV listed findings at the top regardless.
• Expecting SAST for every repository. If the repository is Go or Rust, SAST will not cover first party code today, whatever the label on the SCA side says.
• Gating on the scan exit code. A clean exit from safeguard scan means the scan ran, not that nothing was found.
• Forgetting containers. Teams scan source and miss that the base image carries its own OS packages. Scan the image your pipeline builds, per environment.
• Assuming fix PRs are on. Autonomous remediation ships with every category set to Manual.

FAQ

What languages does Safeguard support?

Safeguard SCA (GA) covers JavaScript and TypeScript, Python, Java and Kotlin, Go, Rust, C# and .NET, Ruby and PHP through their package managers, plus packages in container image layers. SAST (GA) covers JavaScript and TypeScript, Python and Java. The CLI support matrix lists more package managers, including Swift, C and C++, Elixir, Haskell and Erlang, which this map labels "CLI matrix only, confirm".

Does Safeguard support Swift and iOS projects?

The CLI support matrix lists Swift Package Manager and CocoaPods, and the reachability docs list Swift and Objective-C for both static and dynamic analysis, which this map labels GA. The SCA docs page and the offering files do not list them, so confirm results on your own project. The CLI matrix also lists .ipa files for binary analysis.

Does Safeguard support C and C++?

The CLI matrix lists Conan and vcpkg, and the reachability docs mark C and C++ GA. The SCA page does not list them, so this map shows C and C++ as CLI matrix only. If your C or C++ dependencies are vendored rather than managed by Conan or vcpkg, an SBOM from your build is the more reliable route.

Which Python lockfiles does Safeguard read?

The CLI matrix lists requirements.txt (pip), Pipfile and Pipfile.lock (Pipenv), pyproject.toml and poetry.lock (Poetry), environment.yml and conda-lock.yml (Conda), and pyproject.toml and pdm.lock (PDM). The deep dependency docs also list uv.lock. The CLI does not read uv.lock or pdm.lock today. Fix pull requests are listed for pip, Poetry and Pipenv.

Is reachability analysis available for every language?

Not every language. Reachability is GA for JVM languages, Python, JavaScript and TypeScript, Go, Rust, C and C++, C# and .NET, Ruby, PHP, and Swift and Objective-C. Elixir, Haskell and Erlang have no reachability row.

Is Safeguard SAST generally available?

Yes. SAST is GA, and the languages the docs list are JavaScript and TypeScript, Python and Java, with more to follow.

Does Safeguard scan Kotlin?

Kotlin dependencies built with Gradle are covered by SCA (GA), and JVM reachability, which includes Kotlin, is GA. Kotlin is not a listed SAST language.

Can Safeguard scan container images and OS packages?

Yes. SCA covers components inside container image layers (GA), including OS packages from apt, yum and apk, according to the Container Images docs. You can scan with safeguard scan --image or per environment in CI with safeguard ci scan --image.

Which SBOM formats can Safeguard import and export?

The CLI support matrix lists CycloneDX JSON and XML (1.4 to 1.6) and SPDX JSON, tag-value and RDF (2.2 and 2.3) as inputs, and those plus CSV, custom JSON, SARIF and JUnit XML as outputs.

Can Safeguard open fix pull requests for my ecosystem?

The AI Remediate docs list full support for npm, yarn, pnpm, pip, poetry, pipenv, Maven, Gradle, Go modules, Cargo, Bundler, NuGet and Composer. Autonomous remediation is GA and ships switched off, with every category set to Manual.

A language map tells you where Safeguard can find a vulnerable component; it does not tell you how fast the fix arrives. For the eight ecosystems with fix pull request support, and for container images, the block below covers the wider options Safeguard offers when the fix is slow to arrive or does not exist yet, including the fork and patch flow.

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 it to "fix the lodash CVE in this repo": the assistant reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing, then shows /permissions, /model and /scan. The demo uses an npm project; for the other confirmed ecosystems the shape is the same, with the change landing in that ecosystem's manifest or lockfile.

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

The second demo sets up the local runner on your own machine, approves it with its device code, and then scans from the terminal. This is the route to use when you want to try the "CLI matrix only" ecosystems on real repositories without sending source anywhere. For the trade offs between connecting repositories and running locally, see repo connection, CLI or local runner.

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

The third demo connects Claude to Safeguard: you add Safeguard from Claude's connector directory, sign in with OAuth, and choose which tools Claude can use. Once connected, you can ask which of your projects use a given ecosystem or which Ruby or PHP findings came back Unknown, and Claude answers from your own Safeguard data.

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

To try the map against your own repositories, install the CLI from https://safeguard.sh/download and start with the docs at https://docs.safeguard.sh/docs .

Quick check

Sources

• Safeguard docs: CLI support matrix
• Safeguard docs: Software Composition Analysis
• Safeguard docs: Deep Dependency Scanning
• Safeguard docs: Vulnerability Prioritization (Reachability Analysis)
• Safeguard docs: Application Security Testing (SAST and DAST)
• Safeguard docs: License Compliance
• Safeguard docs: AI Remediate
• Safeguard docs: Generate SBOM
• Safeguard docs: Container Images integrations
• Safeguard docs: CI/CD container images
• Safeguard docs: CLI usage
• OWASP Top 10:2025, A03 Software Supply Chain Failures
• NTIA, The Minimum Elements For a Software Bill of Materials
• CISA, Software Bill of Materials
• NIST SP 800-218, Secure Software Development Framework version 1.1
• FIRST, Exploit Prediction Scoring System
• CISA, Known Exploited Vulnerabilities Catalog
• Package URL specification
• OSV schema
• CycloneDX specification overview
• SPDX specifications
• MITRE CWE Top 25

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