Concept card

Threat-First SAP Analytics Architecture (the T in GSTACK)

As of 2026-10-06

Edited by Cédric Mary, sole editor and publication director — 27 years in the SAP ecosystem. How these pages are produced, and where automation is used.

What is Threat-First SAP Analytics Architecture (the T in GSTACK)?

The threat tree walks every SAP analytics flow through four steps — asset classification, trust boundaries from ECC to external share, STRIDE-light per boundary, and blast-radius scoring — producing a one-page document per flow.

The 4-step threat tree on SAP analytics flows

Apply to every critical data flow on the engagement. Output is a 1-page-per-flow document.

Step 1 — Asset inventory

What data does this flow carry? Classification levels:

Public — counts, KPIs at country level, anonymized buyer-persona
Internal — country-grouped revenue, partner relationships, named-customer logos
Confidential — per-customer transactional, individual employee, payroll, MNPI
Restricted — PII identifying natural persons, health data, payment card data

The higher the classification, the smaller the acceptable blast radius.

Step 2 — Trust boundaries

Walk the flow from origin to consumption. At each transition, draw a boundary:

ECC source → Datasphere replication (boundary: SAP RFC trust)
Datasphere → BDC Iceberg lakehouse (boundary: lakehouse object-store ACLs)
BDC → SAC live model (boundary: SAC role + space)
SAC story → embedded export to Office (boundary: SAC export policy)
SAC story → shared to external auditor (boundary: SAC public link)

At each boundary, name what the attacker would have to compromise to cross it.

Why it matters

Data classification (public, internal, confidential, restricted) sets the acceptable blast radius before any control is designed — the higher the classification, the smaller that radius must be.
Each trust-boundary transition (ECC to Datasphere, Datasphere to BDC Iceberg, BDC to SAC live model, SAC to external auditor) names exactly what an attacker would need to compromise to cross it.
STRIDE-light applied per boundary surfaces SAP-specific attack vectors — S-User reuse, RLS bypass via SAC drill-through, a Joule agent inheriting service-account scope.

Key points

Apply per data flow, not per project — each flow gets a 1-page threat tree.
4 steps: asset inventory · trust boundaries · STRIDE-light per boundary · blast-radius scoring.
SAP analytics-specific boundary list: ECC→Datasphere, Datasphere→BDC, BDC→SAC, SAC→export, SAC→public link.
Output: a [GSTACK · threat-model · Pn] line per finding, fed into engagement risk register.
Pairs with ownership-map (C306) — every finding gets a named owner.
Once a Joule agent or grounding pipeline sits in the flow, add an LLM-inference boundary — its Spoofing leaf is prompt injection, its Information-disclosure leaf is grounding retrieval bypassing row-level security.
Score blast radius on a third factor when a leaf feeds an actionable agent: is the downstream action reversible — a self-propagating disclosure via an agent's own write action outranks a static leak.
Fix grounding-bypass leaks at the data-product layer (Datasphere DAC), not inside Joule Studio — a Joule-only fix leaves every other consumer of the same data product still exposed.

Terms used on this page

Trust boundary: A point in the architecture where attacker-controlled input meets privileged code or data.
STRIDE: Microsoft threat-classification framework: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege.
Data classification: Tagging of data with a sensitivity level (public/internal/confidential/restricted) used to scope acceptable blast radius.
Asset inventory: The first step of any threat model — what are we protecting? Skip this and the rest is theatre.
LLM-inference boundary: The trust-boundary type introduced once a flow includes an LLM call — the point where governed data crosses into a prompt, with its own Spoofing (prompt injection) and Information-disclosure (grounding leakage) failure modes.
Grounding retrieval: The document- or database-grounding step in SAP's orchestration service that fetches context before an LLM call; historically runs under a service identity, which can silently bypass the requesting user's own row-level security unless explicitly configured otherwise.
Reversibility factor: A third scoring dimension added to blast-radius rank once a threat-tree leaf feeds an actionable agent: whether the downstream action the agent can take is reversible, since an irreversible action compounds a disclosure into a self-propagating incident.

Sources

Full card available to members. What the full card adds: the full decision framework · the SAP vs Snowflake / Databricks / Fabric comparison · the common pitfalls and their fix · the cheat sheet · the architecture schemas · the code blocks · the facts worth quoting.

Open in the app →