Find vulnerabilities in your source code (SAST) and running applications (DAST) with Safeguard's first-party, tenant-isolated application security testing.

Application Security Testing (SAST & DAST)

Safeguard is extending its platform with first-party application security testing — static analysis of your source code (SAST) and dynamic testing of your running applications (DAST) — alongside the SCA, secrets, container, and IaC scanning you already use. Findings from every engine share one unified model, so a runtime issue can be correlated to the exact source-code sink that caused it.

Note: SAST and DAST are rolling out. The platform wiring, the unified findings model, and the DAST safety controls are in place today; detection depth expands over time. This page documents the capability and how to configure it.

How it fits the platform

Application security testing runs through the same path as your other scans:

Integrations page → SCM → Pipeline → CLI (scan engine) → findings → OpenSearch → app (via GPT)

You add a Safeguard SAST or Safeguard DAST integration the same way you add a repository or registry. Scans run on the pipeline or on a local/on-prem runner, and findings land in your tenant-scoped index — queryable in the app and through the API.

SAST — static analysis

SAST analyzes source code without running it, tracing untrusted input from a source (a request parameter, CLI arg, file read) to a dangerous sink (a SQL query, command exec, file path) across functions and files.

Aspect	Detail
Inputs	A connected repository or a local directory (no build required)
Languages (phase 1)	JavaScript/TypeScript, Python, Java (more to follow)
What you get	A finding with the source→sink dataflow trace, CWE/OWASP mapping, severity, and a code location
Where it runs	Pipeline, or a local runner so source never leaves your perimeter

Each SAST finding carries a dataflow trace — the ordered hops from source to sink — so a developer can see exactly why it was flagged, not just where.

DAST — dynamic analysis

DAST tests a running application for runtime issues (missing security headers, injection classes, misconfigurations) by sending safe, non-destructive requests and observing responses.

DAST is a defensive, authorized-testing capability. It is not a general offensive tool, and the following controls are enforced in code, not as UI conveniences:

Verified targets only. A target is unverified until you prove ownership (DNS TXT record, uploaded file, meta tag, or verified email domain). Active checks cannot run against an unverified target.
Strict scope. Every outbound request is checked against an allow-listed host/path scope. Out-of-scope requests are blocked and logged.
Rate limits & budgets. Conservative per-target limits (requests/second, requests/node, max 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_aggressive mode is off by default, never auto-selected, and requires elevated authorization plus a target flagged owned-and-isolated.
Full audit trail. Every DAST request and finding change is recorded with actor, tenant, and timestamp.

Target verification & safety

Before a DAST scan can touch a target you must verify ownership. Choose a method:

Method	How
DNS TXT	Add a provided TXT record to the target's domain
File upload	Host a provided token file at a well-known path
Meta tag	Add a provided `<meta>` tag to the site
Email domain	Verify via an address on the target's domain

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

Unified findings & correlation

SAST, DAST, and SCA findings share one model with correlation keys. When a DAST-confirmed runtime issue maps to the SAST source-code sink that produced it, the two are linked and prioritized together — a confirmed, reachable, exploitable finding rises to the top. Every finding is tenant/org-scoped (X-Tenant-Id, X-Org-Id, X-Descendant-Org-Ids) end to end.

Configuration

Add an AppSec integration from the Integrations page:

Safeguard SAST — select a repository or point at a source directory.
Safeguard DAST — register a target, verify ownership, set the in-scope hosts/paths and safety mode.

Scans then trigger through the standard integration → pipeline → CLI flow, and results appear in your findings views.

CLI

Run scans locally or in CI with the Safeguard CLI:

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

# 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 DAST command refuses to run against an unverified or out-of-scope target — the safety kernel enforces this regardless of flags.

Reports

Findings appear in the app's AppSec views with severity, rule, CWE, location, and (for SAST) the dataflow trace. You can query them like any other entity:

safeguard findings list --engine sast --severity high
safeguard findings list --engine dast --status open

Reachability Analysis — prioritizing findings by whether they're actually reachable.
Continuous Scanning — how assets are rescanned over time.
Guardrails & Enforcement — using findings as policy gates in CI/CD.
CLI — running scans from the command line and local runners.
Air-Gapped Deployment — keeping source and runtime data on-prem.

Application Security Testing (SAST & DAST)

On this page