Today we're sharing what we're building next on the Safeguard platform: first-party application security testing — static analysis of your source code (SAST) and dynamic testing of your running applications (DAST) — sitting alongside the SCA, secrets, container, and IaC scanning you already run.
This is rolling out in stages. The platform wiring, the unified findings model, and the DAST safety controls are in place now; detection depth expands from here. Here's the shape of it and why we built it this way.
One findings model, not five silos
Most teams stitch AppSec together from separate tools that never talk to each other: one SAST product, one DAST product, an SCA scanner, a secrets tool. Each speaks its own dialect, and nobody can tell whether the "high" in one is the "high" in another.
Safeguard SAST and DAST emit the same unified finding as every other engine — the same severity scale, the same status lifecycle, the same tenant/org scoping. That means one review queue, one policy language, and one API surface for all of application security.
The correlation that matters
Because findings share a model, they also share correlation keys. When a DAST-confirmed runtime issue maps back to the exact SAST source-code sink that caused it, the two are linked and prioritized together.
A finding that is reachable in code and confirmed at runtime is a very different thing from a static match nobody can trigger — and it rises to the top of the queue automatically. That cross-engine correlation is the whole point of building AppSec into one platform instead of bolting tools together.
SAST: source to sink, with the trace
SAST analyzes code without running it, following untrusted input from a source (a request parameter, a CLI argument, a file read) to a dangerous sink (a SQL query, a command exec, a file path) across functions and files. Phase-one languages are JavaScript/TypeScript, Python, and Java, with more to follow.
Every SAST finding carries the dataflow trace — the ordered hops from source to sink — so a developer sees why it was flagged, not just where. And it can run on a local runner, so your source code never leaves your perimeter.
DAST: defensive-only by design
DAST tests a running application with safe, non-destructive requests. We want to be precise about what this is and is not: Safeguard DAST is a defensive, authorized-testing capability, not a general offensive tool. Several rules 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.
- Conservative rate limits and safety budgets per target, mandatory and configurable.
- Non-destructive by default — benign markers and bounded, time-based or out-of-band inference. No data-destroying or denial-of-service payloads.
- A full audit trail for every request and finding change, with actor, tenant, and timestamp.
A heavier lab mode exists for teams testing their own isolated environments, but it's off by default, never auto-selected, and gated behind elevated authorization.
It plugs into the flow you already use
There's no new console to learn. You add a Safeguard SAST or Safeguard DAST integration the same way you add a repository or a registry, and scans run through the same integration → pipeline → runner path as everything else. Findings land in your tenant-scoped views and API, and can gate CI/CD through the same policy engine you use today. It runs on-prem and in air-gapped environments like the rest of the platform.
Where this is headed
We're building the engine depth in the open on our own platform first. Follow the Application Security Testing documentation for capability updates as detection expands, and reach out if you'd like to help shape it.