Last week we introduced first-party SAST and DAST. Today we're sharing the bigger shape that fits into: Safeguard is expanding from a posture-and-findings platform into a first-party detection and prevention platform. Detection engines that we own end to end, prevention that acts inline, and a single findings model that ties all of it together.
Everything below is shipped and running on our own platform first. It is defensive by design, non-destructive by default, and every engine is admin-toggleable and enforced server-side.
The idea: one findings model, many engines
The problem with the modern security stack is not a shortage of tools — it is that the tools do not talk to each other. A SAST high, a cloud misconfiguration, a leaked secret, and a runtime alert each live in their own console with their own severity dialect, and a human is left to reconcile them by hand.
Safeguard's answer is to make every engine emit the same unified finding — the same severity scale, the same status lifecycle, the same tenant and organization scoping. One review queue, one policy language, one API surface. As we add engines, they join that model rather than starting a new silo.
First-party AppSec
Real static and dynamic analysis, owned end to end.
- SAST uses tree-sitter-based taint and dataflow analysis across JavaScript/TypeScript, Python, and Java, tracing untrusted input from source to dangerous sink and emitting the full dataflow trace.
- DAST drives a headless-Chromium crawler through the OWASP suite with out-of-band application security testing (OAST) and proof-based verification, including authenticated scanning. It is defensive-only: active checks run only against ownership-verified, in-scope targets, under mandatory rate limits and a full audit trail.
Red Team — defensive adversary emulation
This is adversary emulation for defenders, not an offensive toolkit. Safeguard runs breach-and-attack simulation (BAS) and purple-team exercises using benign detection canaries — safe markers that test whether your controls fire, with no weaponized payloads. It builds an attack-path graph and folds it into unified risk, does safe reconnaissance, and validates AI/LLM guardrails.
Every active step is gated: it runs only under signed rules of engagement, explicit approvals, a live kill-switch, and an immutable audit record. Nothing runs that you have not signed off on, and anything running can be stopped instantly.
AI-SPM — AI security posture management
AI systems ship model artifacts, and those artifacts can carry code. Safeguard scans model files — pickle, PyTorch, safetensors, and GGUF — for malware and unsafe deserialization before they reach your inference plane, so a poisoned checkpoint is caught as a finding like any other.
DSPM — data security posture management
Safeguard classifies sensitive data — PII, PHI, PCI, and secrets — across the surfaces it can see, under a strict redaction mandate: the platform records that sensitive data exists and where, without copying the sensitive values themselves into findings.
Runtime / CWPP
ATT&CK-mapped runtime threat detection correlated with cloud posture (CNAPP), so a runtime signal is connected to the misconfiguration or vulnerable component behind it. An eBPF collector for deeper Linux runtime visibility is rolling out now — described as rolling out, not generally available.
Package Firewall
Prevention that acts at install time. The package firewall inline-blocks typosquats, dependency-confusion attempts, and known-malicious packages before they resolve into a lockfile — stopping the bad dependency at the door rather than flagging it after it's already in your tree.
AutoTriage
More engines mean more raw findings, so noise control is part of the platform, not an afterthought. AutoTriage performs cross-scanner deduplication and noise reduction so the same underlying issue seen by three engines becomes one prioritized finding. Its one hard rule: it never suppresses malware or secrets — those always surface.
Unified findings and admin feature flags
All of the above lands in one findings model. And every engine is an admin feature flag: you decide which engines are on for your tenant, and that decision is enforced server-side, not just hidden in the UI. Turn on what you need, leave the rest off, and know the boundary is real.
Where this is headed
We built this as a foundation, not a finish line. The platform vision is a single defensive fabric where detection, prevention, and prioritization share one model — and there is more on the roadmap beyond what shipped this session. We'll announce those as they ship, the same way we announced these: only when they're real. For now, everything described above is live and available to enable.