Unified Findings & Feature Flags

Safeguard's security engines don't each carry their own siloed inbox. Every engine reports into one unified findings model, that model is browsed from one consolidated Findings tab per project, and every engine is independently controllable through feature flags.

One model, discriminated by finding_type

All engine findings share a single model discriminated by a finding_type field, so you can view, filter, and correlate across engines in one place:

finding_type vs. the dropdown's URL value. The Scanner dropdown's display name and its underlying finding_type usually match, but the short id used in the ?scanner=<value> deep link (see Scanner Coverage deep links) doesn't always equal the finding_type itself. Three scanners diverge: AI Security is ?scanner=ai-security but finding_type: aisec; CTEM/EASM is ?scanner=easm but finding_type: easm_exposure; Package Firewall is ?scanner=package-firewall but finding_type: pkgfw. If you're constructing a ?scanner= link by hand (rather than clicking a Scanner Coverage card), use the dropdown/URL value from this list, not the finding_type — a mismatched value falls back to All scanners silently (see the callout under Scanner Coverage deep links).

Because findings share the model, they share correlation keys. A DAST-confirmed runtime issue can be linked to the SAST source-code sink that produced it and to the CNAPP correlation showing it's running, reachable, and exposed — so a confirmed, reachable, exploitable finding is prioritized together, across engines. See AutoTriage for how cross-engine duplicates collapse into one canonical finding, and Vulnerability Prioritization (Reachability Analysis) for how the reachability signal referenced above is computed.

Every finding is tenant/org-scoped end to end (X-Tenant-Id, X-Org-Id, X-Descendant-Org-Ids).

The Findings tab and the scanner filter

Findings for a project live in a single Findings tab (Info … Findings … Reports). Rather than a separate tab per scanner, the Findings tab has a compact Scanner dropdown at the top:

• All scanners (the default) shows the same unfiltered view the Findings tab has always shown — every finding_type, together, with no scoping applied.
• Selecting an individual scanner (SAST, DAST, DSPM, Runtime, and so on) scopes the table, the summary stats, and the underlying queries to that engine's finding_type. You're looking at the same Findings tab, just narrowed to one engine.
• Only scanners you have access to appear in the dropdown — today that's driven by the elevated-permission gate on ITDR/DLP (see ITDR and DLP: elevated access); every other option is visible to anyone who can open the tab. The separate Application Security panel further down the same tab is where per-engine feature flags currently apply.

Findings tied to roadmap engines

A few scanner-filter options — currently SSPM, CTEM/EASM, Endpoint, and DRP — are wired all the way through the findings data model (each has a real finding_type and a normal entry in the Scanner dropdown), but the scanning engines that would actually populate them are still on the roadmap (see each engine's linked doc page above, all explicitly marked "Roadmap — not yet available"). Concretely, that means:

• They behave like any other scanner in the dropdown and in Scanner Coverage — no special badge, no dashed border. Selecting one scopes the Findings tab to that finding_type exactly like SAST or DSPM would.
• Because no engine is emitting sspm, easm_exposure, endpoint, or drp findings yet, what you'll actually see today is the same empty-table state any scanner shows when it has no data: No <Scanner> findings found for this project. This is not a fabricated "coming soon" placeholder — it's the ordinary empty state, because there's ordinarily nothing there yet.
• The product does have a dedicated, visually distinct "coming soon" placeholder (a muted card with a Coming soon badge) reserved for scanners that aren't wired into the findings model at all. None of today's scanner options trigger it — every entry in the Scanner dropdown already has a finding_type mapped, SSPM/CTEM-EASM/Endpoint/DRP included.
• Once the underlying engine ships and starts posting findings, the same filter option starts returning real rows and a nonzero count with no further UI changes required on your end.

If you select SSPM, CTEM/EASM, Endpoint, or DRP and see an empty table instead of real findings, that's expected — it means the engine hasn't shipped yet, not that something is broken. Check the engine's own doc page (linked in the table above) for its current roadmap status before assuming a config or permissions problem.

The Application Security panel

Every Findings-tab view — whatever you have selected in the Scanner dropdown — also renders an additive Application Security panel below the findings table: a single card with one sub-tab per first-party engine, scoped to the same project/product/component as the rest of the tab. This is a second, separate scanner surface on the same page, and it's gated differently from the dropdown above it:

† In this panel, the Package Firewall sub-tab currently queries finding_type: sca, distinct from the main Scanner dropdown's Package Firewall option (which queries pkgfw, per the finding_type table above). If the two ever show different counts for what looks like the same engine, this is why — treat it as a known quirk of the current wiring rather than a data-consistency bug on your end.

‡ CTEM and Threat Intel only appear as sub-tabs in this panel — neither has its own entry in the main Scanner dropdown. The dropdown folds CTEM's signal into the combined CTEM/EASM option (easm_exposure); Threat Intel (tip) has no dropdown or Scanner Coverage equivalent at all today.

• The Scanner dropdown and Scanner Coverage cards are gated by permission only — every option except ITDR/DLP is visible to anyone who can open the Findings tab at all, regardless of feature-flag configuration.
• The Application Security panel is gated by both the feature flag and, for ITDR/DLP, the permission. A sub-tab only appears if your tenant has that engine's flag enabled (and, for ITDR/DLP, your role holds findings:view_sensitive). If no engine qualifies for the current tenant/role, the entire panel is omitted rather than shown empty.

In other words: this panel, not the Scanner dropdown, is what the Feature flags admin toggles below actually control day to day. Turning scanner:dspm off removes the DSPM sub-tab from this panel; it does not remove DSPM from the Scanner dropdown or its Scanner Coverage card, which are unaffected by feature flags in the current UI.

Scanner Coverage deep links

The project Info page shows a Scanner Coverage section: one card per scanner you have access to, each showing a live finding count (zero until an engine has posted data — including for the roadmap engines described above, which show 0 findings today rather than a "coming soon" badge). Clicking any card takes you straight into the Findings tab with that scanner preselected, via a query parameter:

.../findings?scanner=<value>

For example, the DSPM card links to .../findings?scanner=dspm, and the Package Firewall card links to .../findings?scanner=package-firewall. Landing on that URL preselects the same dropdown described above — you can change it from there just like you would if you'd opened the tab directly and picked a scanner yourself.

If a Scanner Coverage link points at a scanner you don't have access to (see ITDR and DLP: elevated access), the Findings tab falls back to All scanners rather than showing an error. This also applies if the scanner value in the URL doesn't match a known scanner.

ITDR and DLP: elevated access

ITDR (identity threat detection and response) and DLP (data loss prevention) surface identity- and data-exfiltration signals — categories of finding that need tighter access control than a typical scanner result. Both are gated behind an elevated permission rather than being on by default:

• The permission is enforced server-side: without it, the data service silently excludes the itdr and dlp finding types from every query and aggregation, regardless of what the client requests (see the query-level mechanics below).
• It's also enforced client-side: without the permission, the ITDR and DLP options don't appear in the Findings scanner dropdown, and their Scanner Coverage cards don't render on the project Info page at all — you won't see an empty result, you won't see the option in the first place.

This is deliberately stricter than the other scanners, in line with SOC 2 expectations around access to identity and data-handling signals. If you believe your team should see ITDR or DLP findings and don't, ask an admin to grant the elevated findings-visibility permission for your role — see RBAC, Teams & Organizations for how roles and permissions are managed.

Note that the access-control plumbing above (server-side default-deny plus client-side hiding) is live today, independently of whether the engines themselves have shipped. ITDR & DLP is currently marked Roadmap — not yet available: the itdr and dlp finding_types are wired into the findings model and gated exactly as described, but the detection engines that would populate them haven't shipped yet. In practice this means: a user with the elevated permission sees the ITDR/DLP options and an empty table (per Findings tied to roadmap engines); a user without it doesn't see the options at all. Neither user sees fabricated findings.

What "default-deny" looks like server-side. Every finding is stamped with a sensitivity discriminator at ingest — elevated for itdr/dlp, standard for everything else — derived server-side from finding_type and never trusted from the client. On every read of the findings entity, the data service checks whether the caller's permissions include findings:view_sensitive (any scope: own/org/tenant/all); if not, it appends an exclusion clause to the query before it runs:

{
  "bool": {
    "must_not": [
      { "terms": { "sensitivity": ["elevated"] } },
      { "terms": { "sensitivity.keyword": ["elevated"] } },
      { "terms": { "finding_type": ["itdr", "dlp"] } },
      { "terms": { "finding_type.keyword": ["itdr", "dlp"] } }
    ]
  }
}

This is additive on top of the normal tenant/org/product scoping — it can only remove documents, never widen access — and it's applied to the same query aggregations use, so itdr/dlp rows also drop out of severity counts and totals for unauthorized callers, not just the table rows. The practical effect: an unauthorized caller's response looks exactly like a tenant with zero ITDR/DLP findings — there's no distinct "permission denied" error to look for; the absence itself is the enforcement. The exclusion also covers findings ingested before the sensitivity field existed, by matching on finding_type directly, so there's no legacy-data gap.

Feature flags

Each engine is admin-toggleable via a feature flag, independently of the scanner filter access rules above. Two things matter here:

• Server-side enforcement. Flags are enforced on the server — a disabled engine is genuinely off, not merely hidden in the UI. Disabling an engine stops it from running and from returning data, not just from being displayed.
• Independent control. You can enable AppSec (SAST/DAST) without enabling Red Team, run DSPM without Runtime, and so on — each engine is its own switch, named scanner:<key> (see the full flag list in The Application Security panel above — for example scanner:dspm, scanner:pkgfw, scanner:itdr).

As covered above, these flags currently govern the Application Security panel's sub-tabs, not the main Scanner dropdown or Scanner Coverage cards — those are gated by the elevated permission alone (ITDR/DLP) and are otherwise visible regardless of feature-flag state. Keep this distinction in mind if you disable an engine's flag and still see it as a dropdown option: that's expected under the current wiring, not a flag that failed to apply.

Querying

Filter the unified view by engine type and the usual finding attributes:

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

FAQ & Troubleshooting

I picked a scanner in the dropdown and the table is empty. Is something broken? Not necessarily. If it's a roadmap engine — SSPM, CTEM/EASM, Endpoint, or DRP (see Findings tied to roadmap engines) — an empty table is expected until the engine ships; there's no separate "coming soon" screen for these, just the ordinary empty state with zero rows. If it's a shipped engine (SAST, DAST, DSPM, AI-SPM, Runtime, Package Firewall, Secrets, Container, IaC) and the table is genuinely empty, no scan has posted findings for that finding_type on this project yet — check that a scan actually ran (see the engine's own doc page for how to trigger one).

Why don't I see ITDR or DLP in the Scanner dropdown at all? Your role doesn't hold the elevated findings-visibility permission described in ITDR and DLP: elevated access. Ask an admin to grant it if you need to review those findings.

Why isn't Red Team or SCA in the Findings scanner dropdown? SCA already has its own dedicated Vulnerabilities tab, so it's left out of the Findings scanner filter to avoid showing the same data twice. Red Team results are also a first-party finding_type, but there's no dropdown option or Scanner Coverage card for it — browse Red Team findings from its sub-tab in the Application Security panel instead.

A Scanner Coverage card sent me to "All scanners" instead of the scanner I clicked. Today that only happens for one of two reasons: the scanner value in the URL doesn't match a known scanner id, or — for ITDR/DLP — your role lacks the elevated permission. The Findings tab falls back to the unfiltered view rather than erroring. (Feature-flag state doesn't affect this fallback in the current UI — see The Application Security panel for what flags actually gate.)

Can I disable one engine without affecting the others? Yes, for the Application Security panel: feature flags are per engine, so toggling scanner:dspm off, for instance, has no effect on any other engine's sub-tab. It doesn't remove that engine from the main Scanner dropdown or its Scanner Coverage card, though — see the note above if you were expecting it to disappear from there too.

Why do I see two different ways to pick a scanner on the same Findings tab? The dropdown at the top and the Application Security panel below the table are two separate, additively-rendered surfaces that happen to live on the same tab. The dropdown scopes the whole tab (table + stats) to one finding_type and is gated by permission only; the panel adds its own per-engine sub-tabs beneath the table and is gated by feature flag (plus permission for ITDR/DLP). See The Application Security panel for the full comparison.

Related

• Application Security Testing (SAST & DAST)
• Red Team
• AI-SPM · DSPM · Runtime Protection
• Secrets Scanning · Software Composition Analysis (SCA)
• Package Firewall · AutoTriage · Vulnerability Prioritization (Reachability Analysis)
• SSPM · CTEM & EASM · Endpoint Security · Digital Risk Protection & Threat Intel · ITDR & DLP — all currently Roadmap; see Findings tied to roadmap engines.
• RBAC, Teams & Organizations — roles and the elevated permission ITDR/DLP require.
• Guardrails & Enforcement — using findings as policy gates.