SCA vs SAST vs DAST in Safeguard: which scanner finds what, and when

In Safeguard, SCA (GA) finds known vulnerabilities and license risk in the open source packages you import, SAST (GA) traces untrusted input through the code you wrote, and DAST (GA) sends safe requests to a running application you have proved you own. Run SCA on every change and continuously after release, SAST on pull requests and pipelines, and DAST against a verified staging or production target.

The three scanners look at different evidence. SCA reads manifests, lockfiles, SBOMs and container layers. SAST reads source code without running it. DAST reads the responses of a live application. None of them can see what the other two see, which is why a mature programme runs all three and why Safeguard puts their output in one findings model instead of three inboxes.

This post explains each scanner as it ships in Safeguard today, where each one runs in the software development life cycle, where they overlap, where they leave gaps, and how to wire them together step by step. It is a hub: the per-language and per-target posts linked throughout go deeper on each one.

Key takeaways

• SCA is GA. It resolves your full dependency graph across npm, pnpm and Yarn, PyPI, Maven and Gradle, Go modules, Cargo, NuGet, Composer and Bundler, plus components inside container image layers, and matches every package and version against CVE and GHSA advisories with EPSS and CISA KEV context.
• SAST is GA. Phase 1 languages are JavaScript and TypeScript, Python and Java. Each finding carries a source to sink dataflow trace, a CWE and OWASP mapping, a severity and a code location. No build is required.
• DAST is GA. It tests only targets you have verified (DNS TXT, file upload, meta tag or email domain), keeps every request inside an allow-listed scope, rate limits itself and runs non-destructive checks by default.
• Reachability analysis is GA, including static reachability for Ruby, PHP and Swift or Objective-C. It decides which SCA findings land first in the queue.
• Autonomous remediation is GA and ships switched off, with every category set to Manual. It opens fix pull requests for dependency findings when you turn it on.
• Policies and gates are GA. The CLI's safeguard scan does not fail a build on findings; gating is done by policy gates in the platform.
• The CLI and local runner are GA. SAST can run on a local runner so source code never leaves your perimeter.
• SAST, DAST and SCA findings share one model with correlation keys, so a DAST-confirmed runtime issue can be linked to the SAST sink that caused it.

What each scanner actually looks at

Before comparing products, it helps to be exact about evidence. A scanner can only report on what it can observe.

SCA: the code you imported

Software composition analysis answers one question: which third-party components are in this software, and which of them have known problems? It works from the dependency graph. It does not read your business logic at all.

Safeguard's SCA docs describe it as an inventory of "every open-source component you ship", direct and transitive, resolved against a continuously updated vulnerability knowledge graph. Four things come out of it:

1. A full dependency inventory. Safeguard resolves the complete graph from your manifests and lockfiles, including deeply nested transitive dependencies. The deep dependency scanning docs describe resolution up to 100 levels deep.
2. Known-vulnerability matching. Every resolved package and version is matched against CVE and GHSA advisories and enriched with EPSS and CISA KEV signals.
3. Reachability-aware triage. Findings are cross-referenced with function-level reachability, so a CVE in a function your code never calls is ranked below one that sits on a live call path.
4. License governance. License obligations and incompatibilities are flagged across the graph. License compliance is GA.

The supported ecosystems, per the SCA docs, are npm, pnpm and Yarn, PyPI, Maven and Gradle, Go modules, Cargo, NuGet, Composer and Ruby Bundler, plus components discovered inside container image layers. The docs add that manifests and lockfiles are both honoured, so resolution matches what actually installs.

Each SCA finding carries the vulnerable component and version, the CVE or GHSA identifiers, severity with EPSS and KEV context, the full transitive path from your project root to the vulnerable package, the reachability verdict where available, and the safe upgrade target.

SAST: the code you wrote

Static application security testing reads your source code without running it. Safeguard's application security testing docs describe the SAST engine as tracing untrusted input from a source (a request parameter, a command line argument, a file read) to a dangerous sink (a SQL query, a command execution, a file path) across functions and files.

The dataflow trace is the useful part. It lists the ordered hops from source to sink, so a developer can see why a line was flagged and not only where. That is the difference between a finding someone fixes and a finding someone suppresses.

The docs are also candid about depth. SAST and DAST are GA: the platform wiring, the unified findings model and the DAST safety controls are in place, and detection depth expands over time. Plan your evaluation around that.

DAST: the application while it runs

Dynamic application security testing never sees your source. It sends requests to a running application and reads what comes back. Safeguard's docs describe it as testing for runtime issues such as missing security headers, injection classes and misconfigurations by sending safe, non-destructive requests and observing responses.

Because DAST touches live systems, Safeguard puts hard limits on it. The docs say these controls are enforced in code, not as UI conveniences:

• Verified targets only. A target is unverified until you prove ownership with a DNS TXT record, an uploaded file, a meta tag or a verified email domain. Active checks cannot run against an unverified target.
• Strict scope. Every outbound request is checked against an allow-listed host and path scope. Out-of-scope requests are blocked and logged.
• Rate limits and budgets. Per-target limits on requests per second, requests per node and maximum duration are mandatory and configurable.
• Non-destructive by default. Detection uses benign markers and bounded, time-based or out-of-band inference, never data-destroying or denial-of-service payloads.
• Safety modes. passive, safe_active and authenticated_safe_active for normal use. A heavier lab mode is off by default, never auto-selected, and needs elevated authorisation plus a target flagged as owned and isolated.
• A full audit trail. Every DAST request and finding change is recorded with the actor and a timestamp.

DAST also returns a different shape of data from SAST and SCA. Safeguard's offering files list DAST output tabs that include Assets, Domains and Subdomains, Pages, APIs, Ports and Services, JS Analysis, Forms, Parameters, Certificates, DNS, Sitemaps, Wayback URLs, Vulnerabilities and Findings. That is reconnaissance of the attack surface as well as a vulnerability list, and it is why the platform keeps separate SAST and DAST column sets in its tables.

For a deeper look at what DAST will and will not touch, read Safeguard DAST scope and verified targets. For APIs specifically, read DAST for APIs from an OpenAPI spec in Safeguard.

Which scanner finds what

The clearest way to choose is by the class of problem. The table below maps common problem types to the scanner that can see them, using only what Safeguard's docs and offering files describe.

Three patterns stand out.

First, SCA is the only one of the three that understands the dependency graph. A SAST engine reading your code sees import requests and moves on. It does not know that the version pinned in your lockfile has a published advisory. That is SCA's job.

Second, SAST is the only one that can point at the line. DAST can tell you that a parameter on a login form behaves like an injection point. It cannot tell you which function built the query. SAST can, for the languages it covers today.

Third, DAST is the only one that sees the deployed system. Headers, TLS, exposed paths and configuration live in the environment, not in the repository. OWASP's page on vulnerability scanning tools describes this category as finding issues such as injection, path traversal and insecure server configuration from the outside, and OWASP's page on source code analysis tools says static tools are frequently unable to find configuration issues because those are not represented in the code.

Why the standards ask for all three

None of this is new thinking. The main secure development frameworks already separate the three activities, even when they do not use vendor terms.

NIST SP 800-218, the Secure Software Development Framework (SSDF) 1.1, splits the work into distinct tasks:

• PW.4.4 asks you to verify that acquired commercial, open-source and other third-party components comply with your requirements throughout their life cycles. Its first example is to regularly check for publicly known vulnerabilities in those components. That is SCA.
• PW.7.2 asks you to perform code review and/or code analysis based on your secure coding standards, and to record and triage what you find in the team's workflow or issue tracker. Automated code analysis is SAST.
• PW.8.2 asks you to scope, design and perform testing of executable code and document the results, again recording and triaging every issue. Testing the running application is where DAST sits.
• RV.1.1 asks you to gather information on potential vulnerabilities in your software and in the third-party components it uses, from acquirers, users and public sources, and investigate credible reports. That is the continuous half of SCA: new advisories against components you already shipped.

Note what PW.7.2 and PW.8.2 have in common: both require that findings are recorded and triaged in the development team's workflow. A scanner that produces a PDF nobody reads does not meet the intent.

The OWASP Top 10:2025 shows the same split. A03:2025 is Software Supply Chain Failures, the territory of SCA. A05:2025 is Injection, which SAST traces in code and DAST probes at runtime. A02:2025 is Security Misconfiguration, which mostly lives in deployed environments where DAST looks.

The CWE Top 25 for 2025 from MITRE ranks the most dangerous software weaknesses. CWE identifiers describe weakness types in code, which is why SAST findings carry CWE IDs while SCA findings carry CVE IDs. A CVE is a specific instance in a specific product; a CWE is the kind of mistake.

OWASP ASVS 5.0 gives a set of verification requirements you can test against, and the OWASP Web Security Testing Guide describes how to test web applications. Neither tells you which tool to buy. Both assume you test the running application as well as review the code.

The OWASP DevSecOps Guideline lists the steps of a basic secure pipeline, and SCA, SAST and DAST appear as separate steps in that list. The OWASP page on source code analysis tools notes that SAST scales well and can run repeatedly, for example on nightly builds, and that finding issues early in development costs less than finding them later.

EPSS and CISA KEV shape how SCA findings get ranked. FIRST describes EPSS as a model that estimates the probability that a published CVE will be exploited in the wild in the next 30 days, published daily for every CVE. CISA's Known Exploited Vulnerabilities catalog lists CVEs with evidence of active exploitation; current federal remediation timelines for it are set by BOD 26-04, which superseded the older BOD 22-01.

Where each scanner runs in the life cycle

Each scanner has a natural place in the life cycle, set by the evidence it needs.

The last row deserves attention. Your code does not change after release, but the vulnerability knowledge about it does. Safeguard's continuous scanning docs describe repositories being rescanned on every push with an hourly pull to catch missed webhooks, and container images on push and every four hours for running images. New advisories are matched against stored components, so a CVE published tomorrow against a library you shipped last month becomes a finding without anyone triggering a scan.

SAST and DAST do not work that way. They run when you trigger them through an integration, a pipeline step or the CLI. A SAST result for an unchanged commit stays the same until the engine's rules change. A DAST result reflects the target at the moment of the test.

How Safeguard handles all three, step by step

The flow below follows Safeguard's docs. Where the docs show a command, it is reproduced as the docs show it. Where they do not, the outcome is described instead.

Step 1: connect what you want to scan

All three engines start from the Integrations page, the same way you add a repository or registry.

1. For SCA, connect a source code integration (GitHub, GitLab, Bitbucket or another Git host), a container registry, or upload an SBOM. The offering files list these three as SCA inputs. See Connect GitHub to Safeguard and Connect GitLab to Safeguard for the source control side.
2. For SAST, add a Safeguard SAST integration and select a repository or point at a source directory.
3. For DAST, add a Safeguard DAST integration, register a target, verify ownership, then set the in-scope hosts and paths and the safety mode.

If you are deciding between connecting a repository to the cloud service and keeping code on your own machine, read Repo connection, CLI or local runner first. That choice matters most for SAST, because SAST reads your source.

Step 2: confirm the engines are switched on

Safeguard's unified findings docs say every engine is independently admin-toggleable through feature flags, and that the flags are enforced on the server. A disabled engine is off, not hidden: it stops running and stops returning data. The SCA docs say the same of SCA, which runs as part of a project scan and is administrator-toggleable.

If a team reports that SAST findings never appear, check this before anything else.

Step 3: run SCA from the CLI or let it run continuously

The Safeguard CLI (GA) runs SCA locally or in CI. The CLI usage docs describe safeguard scan as building an SBOM for a target, matching it against vulnerability databases and writing the results as JSON files under --output, which defaults to ./output. It takes exactly one target:

# A local directory (your own or proprietary code)
safeguard scan --dir .

The same command scans a container image with --image. For image-specific detail, read Scan container images in Safeguard.

Exit codes are deliberate, and they trip people up. The docs say safeguard scan exits 0 when the scan ran, whatever it found; 1 when the command itself failed, such as a bad flag or an unreadable target; and 2 when results were written but the vulnerability scan did not actually run, so a script never mistakes that for a clean pass. There is no severity threshold flag. Gating on findings is done by policy gates in the platform (Step 7).

The CLI also offers fast, deep and progressive scan modes (GA).

Once a repository is connected, you do not need the CLI for ongoing SCA. Continuous scanning rescans on push and re-scores stored components as new advisories arrive.

Step 4: run SAST on a source directory

The application security testing docs show the SAST command like this:

# Static analysis of a source directory
safeguard appsec sast --dir ./src --tenant-id <tenant> --product-id <product>

No build is needed. Run it in your pipeline after checkout, or on a local runner when source must not leave your network. The local runner and the SAST engine it runs are both GA.

Phase 1 covers JavaScript and TypeScript, Python and Java. If your service is in another language, SAST will not report on it today. The language posts cover what each one looks like:

• SAST for JavaScript and TypeScript in Safeguard
• SAST for Python in Safeguard
• SAST for Java in Safeguard

Step 5: verify a target and run DAST

DAST has one more step than the others, and it is not optional. Before a DAST scan can touch a target, you verify ownership:

Until verification succeeds the target stays unverified, and only passive, non-intrusive checks are permitted, if any.

Then run the scan. The docs show it like this:

# Dynamic analysis of a verified, in-scope target
safeguard appsec dast \
  --target-id <target> \
  --base-url https://app.example.com \
  --scope-host app.example.com \
  --tenant-id <tenant>

The docs state that the DAST command refuses to run against an unverified or out-of-scope target, and that the safety kernel enforces this regardless of flags. You cannot talk your way past it with a command line option.

For APIs, the Safeguard API Security integration tests from a live URL, an OpenAPI or Swagger file, a pasted curl command or a Postman collection. The docs say local and private addresses (localhost, private IP ranges, .local and .internal names) cannot be reached from Safeguard's scanner; scan those with a runner inside your network.

Step 6: read the results in one place

Here is where the three scanners meet, and where the screens differ in a way worth knowing.

1. SCA results live in the Vulnerabilities tab. The unified findings docs explain that SCA already has its own dedicated Vulnerabilities tab, so it is intentionally left out of the Findings tab's Scanner dropdown to avoid showing the same data twice.
2. SAST and DAST results live in the Findings tab. That tab has a Scanner dropdown at the top. All scanners is the default. Choosing SAST or DAST scopes the table, the summary stats and the underlying queries to that engine.
3. Each AppSec finding shows severity, rule, CWE and location, and for SAST the dataflow trace. The docs note there is no CLI command for listing these findings yet, so read them in the app.
4. SCA findings show the component, version, advisory IDs, EPSS and KEV context, the transitive path, the reachability verdict where available and the safe upgrade target.

The project view groups output into tabs. The offering files list Vulnerabilities, Findings, Dependencies, Suppliers and Licenses, Compliance and Reports and Documents among the tabs for repository scans, and the reconnaissance tabs listed earlier for DAST.

Step 7: correlate, prioritise and gate

Because the engines share one model, findings share correlation keys. Safeguard's docs describe a DAST-confirmed runtime issue being linked to the SAST source code sink that produced it, so the two are prioritised together. A confirmed, reachable, exploitable finding rises to the top. Since SAST and DAST detection depth is still expanding, treat correlation as something to test in your own evaluation rather than something to assume.

For SCA, prioritisation comes from reachability (GA), EPSS and KEV. Safeguard's reachability docs list static and dynamic reachability as GA for Java, Kotlin and Scala, Python, JavaScript and TypeScript, Go, Rust, C and C++, and C# and .NET. Static reachability is also available for Ruby and PHP, and both modes are available for Swift and Objective-C. The docs are also plain about where reachability is weakest: code that executes dynamically through reflection, eval or unsafe dispatch. For the full method, read Prioritise vulnerabilities with reachability, EPSS and KEV in Safeguard.

Then decide what blocks a release. Policies, gates and guardrails (GA) let you write rules that generate findings and enforce them at checkpoints with block, warn, notify or require-approval actions. Since safeguard scan never fails on findings by itself, this is where a pipeline actually stops. See Plain English security policies to release gates in Safeguard.

Step 8: fix

Fixes differ by scanner.

• SCA findings usually have a safe upgrade target. Autonomous remediation (GA) can open a tested, policy-gated pull request that moves the dependency to that version, on one repository or in bulk. It ships switched off, with every category set to Manual, so nothing changes until your team chooses. Read Autonomous remediation in Safeguard.
• SAST findings come with the dataflow trace, which tells the developer where to break the path: validate at the source, parameterise at the sink, or remove the hop in between.
• DAST findings often point at configuration: a header, a TLS setting, an exposed path. The fix may sit in infrastructure code or a proxy rather than in the application.

Overlaps: where two scanners report the same thing

Overlap is not waste if you handle it. Here is where it happens.

SCA and DAST on a vulnerable component. If a library with a known flaw is exposed on a route, SCA reports the CVE from the lockfile and DAST may observe the behaviour at runtime. SCA tells you the version and the upgrade; DAST tells you it is exposed. Both are useful, and the fix is the same upgrade.

SAST and DAST on injection. SAST sees a tainted path into a query. DAST sees a parameter that behaves like an injection point. This is the overlap Safeguard's correlation keys are built for: when both fire on the same flaw, they are linked and ranked together instead of appearing as two unrelated tickets.

SCA and container scanning. Both read the contents of an image. In Safeguard, container image layers are an SCA input, so the overlap collapses into one engine. Base image findings and application dependency findings appear in the same vulnerability view.

SAST and SCA in the same repository. They read the same checkout and report different things. They rarely duplicate. If a finding appears to be in both, it is usually a SAST finding where the sink is a library call, and an SCA finding for a CVE in that library. They are related, not identical.

Gaps: what none of the three will catch

A scanner programme with all three still leaves gaps. Being honest about them is the point of running a programme rather than buying a tool.

• Business logic flaws. A discount that stacks when it should not, or a workflow step that can be skipped, is valid code that does what it was written to do. None of the three understands your intent.
• Authorisation design. Whether user A should see user B's invoice is a design question. Automated scanning can catch some cases, but it does not replace a design review and targeted manual testing. OWASP's page on source code analysis tools lists authentication problems and access control issues among the vulnerability types that are difficult to automate searches for.
• Code in uncovered languages. SAST covers three language families today. A Go or Rust service gets SCA and reachability but not SAST.
• Hosts you did not verify or did not tick. DAST tests nothing outside its scope. The docs are explicit that a host that was not tested has no findings because it was not looked at, not because it is clean.
• Vulnerabilities nobody has published. SCA matches against known advisories. A flaw that has no advisory yet is invisible to matching.
• Software you do not build. Vendor appliances, hosted services and managed runtimes still depend on the vendor for a fix.

Decision table: which scanner should you run first

If you are starting from nothing, sequence matters more than coverage. This table is the short version.

And the same question asked from the requirement side:

What Safeguard does not do

These limits come from Safeguard's own docs and offering files. They are worth knowing before you plan a rollout.

1. SAST covers three language families today. Phase 1 is JavaScript and TypeScript, Python and Java. Other languages get SCA and reachability, not SAST.
2. SAST and DAST detection depth is still expanding. Do not make either the sole release gate until you have measured it on your own code.
3. DAST will not test what you have not verified or scoped. Unverified targets get passive checks at most. Out-of-scope requests are blocked. Third-party hosts in a Postman collection are unticked by default, and one API scan tests at most 10 hosts.
4. Safeguard's scanner cannot reach private addresses. Localhost, private IP ranges and internal names need a runner inside your network.
5. There is no CLI command for listing AppSec findings yet. Read SAST and DAST findings in the app.
6. safeguard scan has no severity threshold flag. It does not fail a build on findings. Blocking is done by policy gates in the platform.
7. Postman scripts are not run. If a pre-request script sets a login token, that value does not exist during a scan; put it in the environment instead.
8. Reachability is not uniform. Coverage notes differ by language in the reachability docs, and dynamic code paths through reflection or eval are hard for any static method.
9. No scanner here replaces design review or manual testing for business logic and authorisation flaws.

Common mistakes

Treating a green safeguard scan exit code as "no vulnerabilities". Exit code 0 means the scan ran. Exit code 2 means results were written but the vulnerability scan did not actually run. Neither says anything about severity. Use policy gates for pass or fail.

Looking for SCA results in the Findings scanner dropdown. SCA is deliberately not there. It has its own Vulnerabilities tab.

Running DAST before verification and assuming the empty result means safe. An unverified target gets no active checks. Empty means not tested.

Pointing DAST at production with an aggressive mode. Use passive or safe_active on production. The heavier lab mode exists for owned, isolated lab targets and needs elevated authorisation for that reason.

Expecting SAST to report on dependency CVEs. SAST reads your code. A vulnerable library version is an SCA finding.

Blocking releases on a newly enabled engine on day one. Run SAST and DAST in report-only mode first, measure the false positive rate on your own code, then add gates.

Forgetting that SCA keeps working after release. Teams scan at build time and stop. Continuous scanning re-scores shipped components as advisories land, which is where many critical findings first appear.

Turning on autonomous remediation for everything at once. It ships off with every category Manual for a reason. Start with one repository and one category, review the pull requests, then widen.

Leaving an engine switched off. Engines are admin-toggleable and the flag is enforced on the server. If findings never appear, check the flag.

FAQ

What is the difference between SCA, SAST and DAST?

SCA finds known vulnerabilities and license issues in third-party components you import. SAST analyses your own source code without running it, tracing untrusted input to dangerous sinks. DAST tests a running application from the outside by sending requests and reading responses. In Safeguard, SCA, SAST and DAST are all GA.

Do I need SAST if I already run SCA?

Yes, if you write meaningful amounts of your own code. SCA cannot see flaws in code you wrote, only in packages you import. SAST in Safeguard covers JavaScript and TypeScript, Python and Java today.

Do I need DAST if I have SAST?

They see different evidence. SAST cannot see headers, TLS settings, exposed paths or other configuration that only exists in a deployed environment. DAST cannot point at the line of code. Running both lets Safeguard correlate a runtime finding with its source code sink.

Which scanner should I run first?

For most teams, SCA. It is GA, it needs only a manifest, lockfile, SBOM or image, and it covers the largest share of most applications. Add SAST next if your code is in a covered language, then DAST against a verified staging target.

Does Safeguard SAST need my code to build?

No. The docs say SAST takes a connected repository or a local directory and no build is required.

Can Safeguard DAST scan a site I do not own?

No. A target must be verified through DNS TXT, a hosted file, a meta tag or an email domain before active checks run, and the DAST command refuses to run against an unverified or out-of-scope target regardless of flags.

Can I run SAST without sending source code to the cloud?

Yes. Safeguard's docs say SAST can run on a local runner so source never leaves your perimeter. The local runner and SAST are both GA.

Where do SCA, SAST and DAST findings show up in the Safeguard app?

SCA findings appear in the project's Vulnerabilities tab. SAST and DAST findings appear in the Findings tab, filtered with the Scanner dropdown. All of them share one findings model.

Is SCA included in Safeguard's free tier?

Yes. The Portal free entry tier includes free signup, one existing repository plus one open source repository from GitHub, GitLab or Bitbucket, and one project per month, with SCA only. SAST and DAST are not part of it.

How often should I run each scanner?

SCA on every change and continuously after release, because new advisories arrive against unchanged code. SAST on every pull request for covered languages. DAST on each deployment to a verified test environment and on a regular schedule for production, using a safe mode.

Get started

To try this on your own code, download the apps and CLI from safeguard.sh/download and follow the setup in the Safeguard docs. Start with SCA on one connected repository, ask your Safeguard admin to switch on the SAST and DAST engines for your tenant, and verify one staging target before your first DAST run. For a labelled list of everything else Safeguard does, see What Safeguard does today.

Of the three scanners, SCA is the one whose findings most often have a known fix: a safe version of a dependency or base image. The block below covers how Safeguard helps you close the gap between that fix existing and it running in production, and what to do when no fix exists yet.

Fix it without waiting for upstream

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

1. Autonomous remediation: pull requests, not tickets

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

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

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

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

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. 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 shows the Safeguard CLI (GA) working on an SCA finding. It is a real CLI session: install, safeguard opens the interactive terminal, you ask it to fix the lodash CVE in the repository, it reads the finding and the advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, and prints a summary without pushing anything. It then shows /permissions, /model and /scan. The same terminal is where a developer would scan a working copy before opening a pull request.

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

The second demo sets up the local runner (GA) on your own machine, approves it with its device code, then scans from the terminal. This is the route to take when source code has to stay in your perimeter: Safeguard's docs name the local runner as the way to run SAST so source never leaves it.

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

The third demo connects Claude to Safeguard with OAuth and lets you choose which tools Claude can use. Install Safeguard from the Claude or ChatGPT connector directory rather than setting up a custom server; once connected, you can ask about your projects, vulnerabilities and findings in plain language, within the tools you allowed. Safeguard in your IDE and in Claude and ChatGPT connector directories walks through the directory install.

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

Quick check

Sources

• Safeguard docs: Application Security Testing (SAST and DAST)
• Safeguard docs: Software Composition Analysis
• Safeguard docs: Unified Findings and Feature Flags
• Safeguard docs: Vulnerability Prioritization (Reachability Analysis)
• Safeguard docs: CLI usage
• Safeguard docs: Continuous Scanning
• Safeguard docs: Deep Dependency Scanning
• Safeguard docs: Findings
• NIST SP 800-218, Secure Software Development Framework 1.1 (CSRC)
• NIST SP 800-218 full text (PDF)
• OWASP Top 10:2025
• MITRE CWE Top 25 Most Dangerous Software Weaknesses
• OWASP Application Security Verification Standard
• OWASP Web Security Testing Guide
• OWASP DevSecOps Guideline
• OWASP: Source Code Analysis Tools
• OWASP: Vulnerability Scanning Tools
• FIRST: Exploit Prediction Scoring System (EPSS)
• CISA Known Exploited Vulnerabilities Catalog

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