SAP Community - SAP BTP Security

Beta Version of Application Vulnerability Report for SAP BTP Now Available

2025-12-04T14:18:40.970000+01:00

Earlier this month, we released the application vulnerability report (beta) for SAP Business Technology Platform (SAP BTP). You can use this new service to detect and remediate open-source application vulnerabilities in your SAP BTP deployed applications.

What is this new service all about?

Frequent security issues in open-source components endanger business data in customer deployed applications. Customers are responsible for performing vigilant patch and vulnerability management. By leveraging the new application vulnerability report for SAP BTP, open-source vulnerabilities in your Cloud Foundry applications can be detected and remediated. It's crucial to fix such vulnerabilities quickly, as attackers are usually aware of them and might try to break into vulnerable systems.

What does the new application vulnerability report service offer you?

The application vulnerability report supports you in the detection of vulnerabilities in custom applications during runtime. It enables you to act on criticality and other provided vulnerability details, like mitigation recommendations.

If we take a closer look at the process, the service scans the applications using a proprietary scanning layer that utilizes open-source scanners as well as custom SAP BTP-specific and 0-day exploit targeted scanners. This unique combination offers a very broad and up-to-date coverage of vulnerabilities in your applications. By using an API, you can also integrate the report data into your incident and security workflow.

Let’s have a quick look at the architecture overview:

Application Vulnerability Report for SAP BTP – Architecture Overview

Get started now!

You can find lots of useful information in this practical hands-on blog post:

Introducing Application Vulnerability Report for Cloud Foundry Applications – Try It Now!

The complete documentation is available on SAP Help Portal.

Please note that this is a beta service available on SAP BTP for subaccounts in trial and enterprise accounts. It is currently available in the “cf-eu10” landscape. Once the beta phase is completed, we plan to roll out the service to other regions.

If you are interested in what’s more to come, check out the road map in SAP Road Map Explorer.

Try it out, and we look forward to your feedback!

Also make sure to join our community to learn more about the security services and features in SAP Business Technology Platform here:

https://community.sap.com/topics/btp-security

Automating User Offboarding in SAP BTP Across Multiple Subaccounts with PowerShell & BTP CLI

2026-01-01T05:43:28.335000+01:00

Managing user offboarding in a complex SAP BTP (Business Technology Platform) landscape with multiple subaccounts can quickly become a time-consuming and error-prone process. Manually tracking and deleting users across all subaccounts and trusted identity providers (IDPs) increases the risk of missing accounts, leading to potential security gaps.

To address this challenge, I have developed a PowerShell script that automates the process of deleting users from all IDPs across all your BTP subaccounts, ensuring a secure and consistent offboarding process.

In this blog, I will walk you through the prerequisites, setup, and usage of the script, as well as the benefits it brings to your BTP user management.

Why Automate User Deletions?

SAP BTP tenants frequently use multiple subaccounts for different environments (dev/test/prod), business units, or regions. Each subaccount might rely on several identity providers (IDPs), making manual user cleanup a tedious and risky task. Automation ensures that:

No user is accidentally missed during the offboarding process.
Audit logs are maintained for all deletions, enhancing traceability.
The process is standardized and efficient, reducing manual interventions and errors.

Prerequisites

Before you begin, make sure you have the following:

SAP BTP CLI Installed
Download the SAP BTP CLI from [SAP Help Portal](https://help.sap.com/docs/btp/sap-business-technology-platform/download-and-start-using-btp-cli-client). Unzip it into a directory of your choice, e.g., `C:\BTP`.
Subaccount Administrator Role
You need to have sufficient permissions to manage users and IDP configurations in the target BTP subaccounts. Make sure your user has the **Subaccount Administrator** role in BTP.
PowerShell (Windows OS)
The script is written for PowerShell and assumes you are running on a Windows machine.
User Email List
   Prepare a text file named `useremails.txt` containing one email address per line for users you wish to offboard. Lines starting with `#` and empty lines are ignored by the script. Example:
   abcd.ytr@sap.com
   lmno.pqr@sap.com
   xyza.bcde@sap.com

Folder Structure

Place the following files in the C:\BTP directory. Alternatively, you can choose any location, as long as all the files listed below are stored together in the same folder.

`btp.exe` (SAP BTP CLI executable)
`delete-user-from-all-idps-txt-input.ps1` (PowerShell script - see below)
`useremails.txt` (Text file with user emails to be deleted)

Script Walkthrough

1. Logging Into BTP CLI

First, you need to authenticate using the BTP CLI. Open a CMD window and enter:

cd C:\BTP
btp login

***When prompted, enter the CLI server URL as: https://cli.btp.cloud.sap

2. Executing the Deletion Script

After logging in, Open Powershell Window and again change the folder to C:\BTP and run the PowerShell script with the following command:

.\delete-user-from-all-idps-txt-input.ps1 -UserEmailFile "useremails.txt"

On successful deletion

**What does the script do?**
- Reads the list of user emails from your `useremails.txt` file.
- Fetches all subaccounts your user has access to.—creates a file
- For each subaccount:
- Retrieves all trusted IDPs—creates a file
- Attempts to delete each user email from every IDP (including `sap.default`, the default identity provider).
- Logs the result (success or error) for every attempt.—creates a file
- Generates a timestamped log file for traceability.

3. Script Features

Bulk User Deletion: Delete multiple users from all IDPs across all subaccounts in one go.
Automatic Audit Logging: Each run creates a log file in the `C:\BTP` folder (e.g., `user_deletion_log_20251229_153201.txt`) recording every deletion attempt, including timestamp, subaccount, IDP, user, and outcome.
Intelligent Parsing: The script skips commented and empty lines in your email input file and robustly parses the BTP CLI output.
Error Handling: If a user is not found or cannot be deleted, it's clearly logged with an error message.

Conclusion

Automating user deletions with a PowerShell script and BTP CLI simplifies the offboarding process, reduces mistakes, and improves auditability in large BTP environments. Simply update your `useremails.txt` for each offboarding round, and in a matter of minutes, you can ensure all relevant user accounts are purged from every subaccount and IDP.

**Happy automating!**

PowerShell Script Code as below :

param (
[Parameter(Mandatory = $true)]
[string]$UserEmailFile
)

# --- CONFIGURE LOG FILE PATH HERE ---
$now = Get-Date -Format 'yyyyMMdd_HHmmss'
$LogFile = "user_deletion_log_$now.txt"

# Prepare log file with header
$logHeader = "User Deletion Log - Started at $(Get-Date -Format 'yyyy-MM-dd HH:mm:ss')"
Set-Content -Path $LogFile -Value $logHeader

function Write-Log {
param (
[string]$Message
)
Write-Host $Message
Add-Content -Path $LogFile -Value $Message
}

# Get the current user running the script
$scriptUser = $env:USERNAME
if (-not $scriptUser) { $scriptUser = $env:USER }

# Check if file exists
if (!(Test-Path $UserEmailFile)) {
Write-Log "ERROR: File '$UserEmailFile' not found."
exit 1
}

# Read user emails (ignore empty/comment lines)
$UserEmails = Get-Content $UserEmailFile | Where-Object { $_.Trim() -ne "" -and -not ($_ -like "#*") }

if ($UserEmails.Count -eq 0) {
Write-Log "No user emails found in the file."
exit 1
}

Write-Log "Read $($UserEmails.Count) user emails from $UserEmailFile..."

# Step 1: Fetch all subaccounts
Write-Log "Fetching subaccounts..."
.\btp list accounts/subaccount > subaccounts.txt

# Skip the header lines (assume first 2 lines are header and column desc)
$lines = Get-Content subaccounts.txt | Select-Object -Skip 2

foreach ($line in $lines) {
# Skip header/footer/blank lines
if ($line.Trim() -eq "" -or $line -match '^subaccount id:' -or $line -match '^subaccounts in') { continue }

# Split line by 2+ spaces (columns are separated by several spaces)
$fields = $line -split '\s{2,}'
if ($fields.Length -lt 2) { continue }

$subGuid = $fields[0].Trim()
$displayName = $fields[1].Trim()

Write-Log "`nFetching IDP trusts for subaccount: $displayName ($subGuid)..."
.\btp list security/trust --subaccount $subGuid > idp_trusts.txt

$trustLines = Get-Content idp_trusts.txt | Select-Object -Skip 1
$originKeys = @()
foreach ($trust in $trustLines) {
$trust = $trust.Trim()
if ($trust -match '(?<OriginKey>([a-zA-Z0-9\.\-]+|sap\.default))\s+(Active|Inactive)$') {
$originKey = $matches['OriginKey']
if ($originKey -and ($originKeys -notcontains $originKey)) {
$originKeys += $originKey
}
}
}

if ($originKeys.Count -eq 0) {
Write-Log "No origin keys found for subaccount $displayName ($subGuid)."
continue
}

foreach ($origin in $originKeys) {
foreach ($userEmail in $UserEmails) {
Write-Log "Deleting user $userEmail from origin $origin in subaccount $displayName ($subGuid)..."
.\btp delete security/user $userEmail --of-idp $origin --subaccount $subGuid
$timestamp = Get-Date -Format 'yyyy-MM-dd HH:mm:ss'
if ($LASTEXITCODE -eq 0) {
Write-Log "SUCCESS: User $userEmail deleted from subaccount $displayName, origin $origin by $scriptUser at $timestamp."
} else {
Write-Log "ERROR: User $userEmail not found, failed to delete User $userEmail from $displayName, origin $origin by $scriptUser at $timestamp."

}
}
}
}

Write-Log "`nDONE! User deletions attempted for all specified emails in $UserEmailFile, for all origins and all subaccounts."

How to Export All Users (with Origins) from All SAP BTP Subaccounts via CLI Automation

2026-01-02T08:17:57.154000+01:00

Introduction

If you manage a large SAP BTP Global Account, you may find it challenging to export a full user inventory—especially when your environment is segmented into multiple subaccounts and utilizes various identity provider origins (multiple trusts). The SAP BTP Cockpit does not offer a single "Export All Users" button at the global account level.

This blog demonstrates how to efficiently extract all users and their identity origins across all BTP subaccounts using the SAP BTP Command Line Interface (btp CLI) and PowerShell scripting.

Prerequisites

btp CLI: Ensure you have downloaded and installed `btp.exe` (the SAP BTP CLI). [Download Link]
Login Required: Log in to your SAP BTP Global Account using the CLI: btp login
Open a CMD window and enter:

Permissions: Your user should have sufficient permissions (Global Account Admin, Directory Admin, Subaccount Admin) to view users in the target scopes.
Windows PowerShell: The script example uses PowerShell, but similar logic can be implemented in Bash or Python.
Working Directory: Place your files in `C:\BTP` (or another folder of your choice).

Folder Structure

New Expert-Guided Implementation: Joule Prerequisites and Activation

2026-01-16T00:06:43.973000+01:00

Establish the Foundation for Your AI Journey

SAP Joule is transforming how organizations interact with SAP applications by bringing intelligence directly into everyday workflows. For customers to activate Joule and unlock its AI-powered capabilities, they must first prepare their SAP Cloud Identity Services (CIS), SAP Business Technology Platform (BTP), and integration foundations to fully realize the value of Joule from day one.

To support customers with this essential preparation, we are pleased to introduce a new Expert-Guided Implementation (EGI):

Joule Prerequisites & Activation - a hands-on, expert-led program designed to help you configure all required technical components for a smooth Joule activation.

This new offering helps customers understand Joule’s architecture, explore deployment options, configure platform prerequisites, and establish the identity and access foundation required for a secure activation. By the end of the EGI, participants will be positioned to complete all the prerequisites required to activate Joule, ensuring a seamless start to their AI adoption journey.

Workshop Schedule

To ensure global participation, this session will be offered across multiple time zones.

For the latest schedule and registration details, please visit EGI: Activating Joule: The Pre-requisites.

Why This EGI Matters

Before Joule can be activated, customers must ensure the right technical prerequisites are in place—across SAP BTP, Cloud Identity Services, Build Work Zone, and Line-of-Business systems. This EGI provides:

A clear, step-by-step path to completing these prerequisites

Expert-led guidance for setting up SAP Cloud Identity Services including Identity Authentication Service (IAS)/Identity Provisioning Service (IPS), and entitlements

Live configuration guidance in your SAP BTP environment and SAP Build Workzone (BWZ)

Hands-on support through real examples and troubleshooting

With AI rapidly becoming central to SAP’s product strategy, organizations need the right technical foundation to adopt Joule with confidence, security, and scalability.

What You’ll Learn: Program Overview

This 2-day EGI blends instruction, demonstrations, and guided hands-on exercises.

Day 1 – Foundation & Architecture

Understand Joule’s system architecture and deployment scenarios

Learn how SAP Cloud Identity Services (IAS/IPS), SAP BTP, SAP Build Work Zone, and LOB solutions work together

Navigate BTP global accounts, subaccounts, entitlements, and subscriptions

Validate system readiness and begin configuring your Joule environment

Experience a live demonstration of Joule integrated with SAP SuccessFactors

Day 2 – Identity, Provisioning & Work Zone Integration

Deep-dive into SAP Cloud Identity Services - Identity Authentication (IAS) and Identity Provisioning (IPS) for Joule

Integrate CIS with your corporate Identity Provider

Configure SAP Build Workzone (BWZ) as the unified interface for Joule

Establish trust relationships between systems

Expose LOB content to BWZ and validate provisioning flows

What You Will Achieve

This new EGI equips your organization with everything needed to prepare for Joule activation, ensuring compliance, security, and a streamlined technical foundation from day one.

If your organization is planning to adopt SAP Joule or preparing for AI-driven innovation within SAP applications, this EGI is the ideal starting point to fast-track your readiness and reduce implementation risk.

By the end of the EGI, you will have:

A configured SAP BTP environment with a designated Joule subaccount

Completed IAS/IPS setup for secure authentication and provisioning

Integrated BWZ as the experience layer for Joule

Verified all activation prerequisites using a comprehensive readiness checklist

Gained expert-backed confidence to run the Joule Booster and proceed with activation

How to Register

Register here to secure your spot* today to learn from SAP experts and gain the skills to bring Business AI to life across your enterprise.

* You may need to register your S-user on learning.sap.com to access the EGI registration page.

Unlocking Joule and SAP Business AI from Strategy to Activation: Expert-Guided Implementation

Secure SAP–AI Integration Using Advantco OpenPGP Services

2026-01-22T18:25:33.866000+01:00

Secure SAP–AI Integration Using Advantco OpenPGP Services

1. Purpose and Scope

This article defines a secure, deployment-agnostic reference architecture for integrating SAP backend systems with external AI agents using OpenPGP-based cryptographic services provided by Advantco. The architecture separates cryptographic processing from data transport, ensuring that encryption, decryption, signing, and verification are performed by a dedicated cryptographic service layer, while message routing and orchestration remain the responsibility of the calling application or integration layer.

The architecture is intended for hybrid enterprise environments in which SAP backend systems may be deployed on-premise, in private cloud, on hyperscalers, or under RISE with SAP. AI agents may run on external platforms or managed AI services. Advantco OpenPGP services are exposed as APIs (REST and/or SOAP) and may be deployed on SAP Business Technology Platform or an equivalent enterprise runtime. This document describes a logical reference architecture and does not prescribe a specific deployment topology.

The scope of this document is limited to secure data exchange and trust establishment between SAP systems and AI agents. AI model behavior, prompt engineering, SAP business logic, and transport-level protocol selection are out of scope except where they affect security guarantees.

2. Architectural Rationale

Integrating SAP systems with external AI capabilities introduces a trust boundary between SAP-controlled environments and systems that operate outside SAP governance. This architecture addresses that boundary by enforcing message-level security that is independent of transport mechanisms and network topology.

Rather than embedding cryptographic logic into SAP applications or integration flows, the architecture externalizes OpenPGP operations into a dedicated cryptographic service layer. This allows encryption, decryption, signing, and verification to be centrally governed, audited, and evolved without requiring changes to SAP business applications. Transport and routing of messages remain the responsibility of SAP applications or integration components, preventing the cryptographic services from becoming an implicit integration broker.

3. Architectural Overview

The architecture consists of four logical concerns: SAP backend systems, an optional integration or orchestration layer, Advantco OpenPGP cryptographic services, and an external AI agent ecosystem.

SAP backend systems produce and consume business data but do not perform cryptographic operations directly. They rely on an integration or orchestration layer such as SAP Integration Suite, a SAP BTP application, or other middleware to coordinate message exchange with external systems where required.

Advantco OpenPGP services provide cryptographic transformation via APIs only. They do not perform message routing, transport, or forwarding.

External AI agents receive only signed and encrypted payloads and return responses in signed and encrypted form. Unencrypted payloads exist only within SAP-controlled trust boundaries.

Advantco OpenPGP provides cryptographic APIs only and returns results to the caller. Message transport and routing are handled by SAP or integration components and are not performed by Advantco.

4. Architecture Structure

From a business perspective, the architecture enables SAP processes to consume AI-generated insights without relinquishing control over data confidentiality or trust decisions. AI systems may influence SAP outcomes, but only after cryptographic validation and SAP-side authorization.

From an application perspective, the architecture separates responsibilities clearly. SAP backend systems focus on business logic. The integration or orchestration layer handles routing, retries, and protocol adaptation. Advantco OpenPGP services handle cryptographic transformation. AI agents handle AI processing only.

From an integration perspective, communication is message-based and transport-agnostic. Payload-level security is applied using OpenPGP before data crosses trust boundaries, ensuring that transport security is an additional layer rather than the primary protection mechanism.

From a data perspective, unencrypted payload exists only within SAP-controlled environments. Outside those boundaries, data is always exchanged in signed and encrypted form, accompanied by cryptographic metadata required for verification and audit.

5. Component Responsibilities

SAP backend systems remain the authoritative producers and consumers of business data. They initiate outbound requests and consume inbound results but delegate cryptographic processing to external services. SAP systems do not store or manage cryptographic private keys.

The integration or orchestration layer (where present) is responsible for transport, routing, protocol handling, retries, correlation, and error handling. It invokes Advantco OpenPGP APIs as required and forwards encrypted payloads to external AI agents, and returns verified payloads to SAP systems. It does not perform cryptographic operations beyond invoking the cryptographic service APIs.

Advantco OpenPGP services provide cryptographic operations as APIs. For outbound processing, they accept payloads and perform optional compression, message digest generation, digital signing, and OpenPGP hybrid encryption. For inbound processing, they accept encrypted payloads, verify digital signatures, decrypt content under governed key controls, and return verified payloads to the caller. These services are stateless with respect to message routing and do not forward data to external systems.

External AI agents operate outside the SAP trust boundary and are treated as untrusted by default. They can only process data that they have successfully decrypted and verified using trusted SAP public keys. AI agents sign and encrypt all outbound responses using their own private keys and do not receive access to SAP private keys or verified SAP payloads.

Key management is handled by a centralized Key Management Service that governs cryptographic key lifecycles, enforces usage policies, and records audit events. Agent identities are established by registering and allow-listing agent public keys, typically identified by fingerprints or key identifiers. Private keys remain protected and are never exposed outside the cryptographic service boundary.

6. Message Exchange

The Advantco OpenPGP APIs may be invoked directly by SAP applications or by an intermediate integration or orchestration layer. In all cases, Advantco performs cryptographic transformation only and does not forward messages.

In the outbound flow, SAP backend systems submit payloads for signing and encryption via the Advantco OpenPGP service. The service returns a signed and encrypted payload to the caller, which is responsible for forwarding the encrypted message to the external AI agent.

In the inbound flow, the external AI agent produces a signed and encrypted response. The encrypted response is submitted to the Advantco OpenPGP service for verification and decryption. The service returns a verified payload to the caller, which delivers the result to the SAP backend system.

The sequence diagram above illustrates the strict request–response nature of the Advantco OpenPGP APIs and the separation of cryptographic processing from message transport and routing.

7. Trust and Security Model

Trust in this architecture is based on cryptographic identity rather than network location. Public-key identities establish which parties may exchange data, while centralized key governance determines how keys may be used. By default, no shared secrets are required between SAP systems and AI agents.

Confidentiality is enforced through OpenPGP hybrid encryption. Integrity and authenticity are enforced through digital signatures. Auditability is provided through centralized logging of cryptographic operations. Replay protection is enforced by the receiving side using message identifiers, timestamps, and validity windows.

Cryptographic validity does not imply business authorization. AI-generated responses or instructions must still be validated against schemas, allow-listed actions, and SAP-side authorization rules before affecting SAP business processes.

8. Deployment Considerations

The architecture supports a wide range of deployment models, including scenarios in which SAP systems and integration components run on SAP BTP while cryptographic services are cloud-hosted and AI agents operate on external platforms. Security and correctness depend on logical separation of responsibilities rather than physical co-location.

As a concrete implementation option, Advantco OpenPGP services are available for deployment on SAP Business Technology Platform (SAP BTP). In this model, the cryptographic services run as managed applications or services on SAP BTP and expose OpenPGP functionality through REST and/or SOAP APIs. SAP backend systems and SAP integration components can invoke these APIs directly using standard SAP-supported connectivity mechanisms. Deployment on SAP BTP does not change the logical architecture described in this document; Advantco OpenPGP continues to operate strictly as a cryptographic service and does not perform message routing or transport.

9. Conclusion

This reference architecture defines a clear separation between cryptographic services, message transport, and business logic for secure SAP–AI integration. By exposing OpenPGP operations as governed APIs and keeping data transport outside the cryptographic service boundary, the architecture enables strong security guarantees while remaining flexible, deployment-neutral, and suitable for enterprise use.

10. Sources

https://www.sap.com/products/technology-platform.html
https://www.rfc-editor.org/rfc/rfc4880
https://owasp.org/www-project-api-security/
https://www.advantco.com/sap-integration-adapters/sap-pgp-integration

Configure Role Owner Stage Auto Approval in SAP IAG

2026-01-23T06:15:25.857000+01:00

Introduction

This blog explains how to configure Role Owner Stage Auto Approval in IAG. focusing on setting up the required data objects, business rules, and workflow configuration to automate approvals.

Step 1: Create Data Object

Create a data object called RoleOwnerAttributes. This object holds the input values used to determine whether the Role Owner stage should be automatically approved.

Add the following attributes to the data object:

roleName (String)
roleCriticality (String)
roleApprover (String)
roleBusinessProcess (String)
roleSubprocess (String)
roleRiskCount (Number)

Step 2: Create another Data Object

Create another data object called AutoApproveRoleOwnerStage. This object stores the output of the rule.

Add the following attributes to the data object:

roleName (String)
roleOwnerAutoStage (Boolean)

Step 3: Create Local Rule
Create a local rule called RoleOwnerStageAutoRule

decision table settings:

Use the fields from RoleOwnerAttributes (Step 1) as the conditions.
Use AutoApproveRoleOwnerStage (Step 2) as the result.

Result Attributes:

Role Owner Auto Stage → Access: Editable
Role Name → Access: Hidden
Set the hardcoded value as the roleName from RoleOwnerAttributes.

In this scenario, the condition is defined based on the Role Name.

Step 4: Create Rule Set

Create a rule set called RoleOwnerRuleSet and add the local rule RoleOwnerStageAutoRule (from Step 3) to it.

Step 5: Create Rule Service

Create a rule service called AutoApproveRoleOwnerStage.

Input → RoleOwnerAttributes (from Step 1)
Result → AutoApproveRoleOwnerStage (from Step 2)

Step 6: Assign Rule Service

Assign the rule service AutoApproveRoleOwnerStage (from Step 5) to the rule set RoleOwnerRuleSet (from Step 4).

Step 7: Activate and Deploy

Activate all the created objects and deploy the business rule service. If any changes are made, the service must be deployed again.

Existing Workflow Setup

In the current existing workflow, the access request is configured to follow the Role Owner approval path as the stage 1 during the approval process.

Testing Scenario

The following test scenario was performed to validate the configuration:

An access request was raised for the role PR_approver_0_1M.
The audit log shows that the request was automatically approved by the system.
The Access request status shows that it moved to the Risk Owner stage, confirming that the Role Owner stage was automatically approved successfully.

Conclusion

Role Owner stage auto approval reduces manual effort and speeds up the approval process for eligible access requests. Using rule-based conditions, organizations can automatically approve condition based requests while keeping manual approvals for critical cases.

Runtime Threat Detection for SAP BTP Kyma with Azure Arc + Microsoft Defender for Containers

2026-02-02T15:52:32.766000+01:00

Securing an external Kubernetes cluster with Microsoft Defender for Containers (via Azure Arc)

When I say "secure Kubernetes", I'm not just thinking about admission policies and CIS checklists. I'm thinking about what happens when something is already running and turns malicious — a web shell lands in a pod, a container starts burning CPU for crypto mining, or someone drops network scanning tools into an otherwise boring workload.

If you're running SAP BTP Kyma runtime, this matters. Kyma has strong platform hardening (Gardener-managed control plane, DISA STIG alignment), and API server audit logs exist — but those logs go to SAP's Platform Logging Service, not directly to you. That's fine for platform-level auditing, but it's not the same as seeing threats inside your workloads at runtime.

That's the gap I'm filling: runtime threat detection — the ability to detect and alert on malicious activity (crypto mining, web shells, credential theft) while workloads are running.

Real-world threats

These aren't hypotheticals — crypto mining and container compromise campaigns are actively targeting Kubernetes clusters:

DERO Cryptojacking (2023–2024): Attackers scanned for misconfigured Kubernetes API servers, then deployed DaemonSets named "proxy-api" to blend in with legitimate cluster components. The mining process itself was named "pause" — masquerading as the standard Kubernetes pause container. CrowdStrike found malicious images with over 10,000 pulls on Docker Hub. How runtime detection helps: Defender's eBPF monitoring catches unusual process spawning from "pause" containers and flags sustained high CPU from processes that shouldn't be compute-intensive. (Source: CrowdStrike — DERO Cryptojacking Discovery)

Kinsing Campaign (2023–ongoing): This campaign exploits vulnerabilities in PostgreSQL, WebLogic, Liferay, and WordPress to gain initial access to containers, then pivots to deploy crypto miners across the cluster. The campaign has affected 75+ cloud-native applications. How runtime detection helps: Defender detects process genealogy anomalies — for example, a WebLogic process spawning shell commands that enumerate Kubernetes resources or deploy new containers.

The pattern: attackers get in through a misconfiguration or vulnerability, then run workloads inside the cluster. Admission policies and CIS benchmarks don't catch threats that start after deployment — that's the gap runtime detection fills.

The solution: Azure Arc + Defender for Containers

For non-AKS clusters, the approach is: Azure Arc (makes the cluster an Azure resource) + Defender for Containers (deploys the runtime sensor as an Arc extension).

What gets installed:

Arc agents (azure-arc namespace): maintain outbound connection to Azure
Defender sensor (DaemonSet on each node): collects runtime telemetry via eBPF — process creation, network activity, system calls

What the sensor detects: crypto mining patterns, web shell activity, network scanning tools, binary drift. (Docs: Workload runtime detection)

Arc also provides an extension platform — Defender isn't the only add-on you can deploy this way. And Microsoft provides a verification checklist so you can prove it's working.

Networking note: Both Arc and Defender require outbound connectivity. If egress is blocked, onboarding fails silently. Check the Arc network requirements and ensure *.cloud.defender.microsoft.com:443 is allowed.

How

I’ll show a portal-first path (fastest to understand), then a programmatic path (fastest to automate).

Step 0 — Pre-flight checklist

Here’s what I personally confirm before I touch the portal:

1) Network egress (outbound)

Arc agents require outbound access to a set of URLs (Azure Resource Manager, Entra ID token endpoints, container registries for pulling agent images, and more depending on features). (Docs: Azure Arc-enabled Kubernetes network requirements)
Defender for Containers on Arc requires outbound access to *.cloud.defender.microsoft.com:443. (Docs: Enable Defender for Containers on Arc-enabled Kubernetes (portal))

2) Tooling

Azure CLI + the connectedk8s extension (for Arc onboarding). (Docs: Quickstart: Connect an existing Kubernetes cluster to Azure Arc)
If I want to script extension deployment, I also install the k8s-extension extension. (Docs: Deploy and manage Arc-enabled Kubernetes extensions)

3) Cluster access

kubectl works and points at the cluster I’m onboarding.
If I’m missing kubeconfig on my workstation, the Kyma Dashboard has a Download kubeconfig link for the cluster.
I sanity-check that my kubeconfig/current context is the Kyma cluster before running anything destructive:

kubectl config current-context
kubectl cluster-info

I have capacity for Arc agents (the Arc quickstart calls out resource requirements and that agents are deployed on connect). (Docs: Quickstart: Connect an existing Kubernetes cluster to Azure Arc)

Step 1 — Connect the cluster to Azure Arc

I typically do this from a workstation that already has kubectl access to the cluster.

1.1 Register providers (if needed)

The Arc quickstart includes registering resource providers like Microsoft.Kubernetes, Microsoft.KubernetesConfiguration, and Microsoft.ExtendedLocation. (Docs: Quickstart: Connect an existing Kubernetes cluster to Azure Arc)

1.2 Run the connect command

From the Arc quickstart, the core command is:

az connectedk8s connect --name <cluster-name> --resource-group <resource-group>

In practice, I prefer to be explicit (especially on shared subscriptions) and set --location and --tags:

az connectedk8s connect \
    --name <cluster-name> \
    --resource-group <resource-group> \
    --location <azure-region> \
    --tags env=<env> owner=<team> system=<system>

What I’m explicitly setting there:

--location: the Azure region where the Azure Arc-enabled Kubernetes resource is created. If you omit it, it’s created in the same region as the resource group.
--tags: Azure Resource Manager tags on the Arc resource (space-separated key[=value]).

If this command hangs or fails in weird ways, I go back to egress first — the Arc network requirements doc is the authoritative “what URLs/ports must my cluster reach?” list. (Docs: Azure Arc-enabled Kubernetes network requirements)

(Docs: Quickstart: Connect an existing Kubernetes cluster to Azure Arc and Azure CLI reference — az connectedk8s connect)

1.3 Verify Arc agents in the cluster

The quickstart calls out that Arc deploys agents into the azure-arc namespace. I validate that they’re Running:

kubectl get deployments,pods -n azure-arc

(Docs: Quickstart: Connect an existing Kubernetes cluster to Azure Arc)

Here’s what that looks like in practice on my Kyma cluster:

And here’s the connected cluster resource in Azure (showing things like connectivity status, location, and tags):

At this point, if Arc isn’t healthy, I stop and fix that first. Everything else depends on it.

Step 2 — Enable the Containers plan in Microsoft Defender for Cloud

Now I go to Defender for Cloud and enable the Containers plan for the subscription where my Arc-enabled cluster lives.

The portal walkthrough is:

Microsoft Defender for Cloud → Environment settings → pick subscription → toggle Containers plan On
Select Settings next to the Containers plan → choose Enable specific components

(Docs: Enable Defender for Containers on Arc-enabled Kubernetes (portal))

At this point you’ll be asked which Containers plan components to enable.

You can enable everything, but for this post I’m intentionally focusing on the Defender sensor (runtime detections). The important callout: from a pricing perspective there’s no cost benefit to enabling one vs. many — the cost is the same — so this is purely about keeping the walkthrough scoped to runtime detection.

Here’s what that looks like in the portal (first the Containers plan settings, then the component selection where I keep only the sensor in scope):

Step 3 — Deploy Defender components to the Arc-enabled cluster

I use one of two flows.

Option A (recommended): Deploy via Defender for Cloud Recommendations

This is the “guided remediation” path:

Defender for Cloud → Recommendations
Find “Azure Arc-enabled Kubernetes clusters should have Defender extension installed”
Select the clusters → Fix

(Docs: Enable Defender for Containers on Arc-enabled Kubernetes (portal))

Option B: Deploy manually from the Arc cluster resource

If I want explicit control (or I’m debugging), I do:

Arc-enabled Kubernetes resource → Extensions → + Add
Install Microsoft Defender for Containers
Choose/configure the Log Analytics workspace during installation (this is where the extension sends collected logs/telemetry used by Defender for Cloud and Azure Monitor Logs)
- I can select an existing workspace, create a new one, or use the default: DefaultWorkspace-[subscription-id]-[region]

(Docs: Enable Defender for Containers on Arc-enabled Kubernetes (portal))

Step 4 (optional) — Programmatic deployment (repeatable automation)

If I’m onboarding clusters at scale, I don’t want a click path. The programmatic doc gives the Azure CLI commands for creating the Defender extension.

Defender sensor extension:

Note: Some examples include an auditLogPath setting for clusters where you control the API server audit log file location. In Kyma, audit logs are handled via SAP’s Platform Logging Service and you generally don’t have direct access to that file path, so I’m omitting it here.

az k8s-extension create \
    --name microsoft.azuredefender.kubernetes \    --cluster-type connectedClusters \    --cluster-name <cluster-name> \    --resource-group <resource-group> \    --extension-type microsoft.azuredefender.kubernetes \    --configuration-settings \        logAnalyticsWorkspaceResourceID="/subscriptions/<subscription-id>/resourceGroups/<rg>/providers/Microsoft.OperationalInsights/workspaces/<workspace-name>"

(Docs: Deploy Defender for Containers on Arc-enabled Kubernetes (programmatic))

If you need the generic “how do extensions work / how do I list/update/delete them” reference, the Arc extensions doc is the canonical place. (Docs: Deploy and manage Arc-enabled Kubernetes extensions)

Step 5 — Verify it’s actually working

This is where I slow down and prove success.

Microsoft’s verification checklist is:

Arc connection is healthy
Defender extension shows as installed
Sensor pods are running
Alerts appearing

(Docs: Verify Defender for Containers on Arc-enabled Kubernetes)

5.1 Verify Arc connectivity

az connectedk8s show \
    --name <cluster-name> \    --resource-group <resource-group> \    --query connectivityStatus

The expected output is Connected. (Docs: Verify Defender for Containers on Arc-enabled Kubernetes)

5.2 Verify Defender extension provisioning

az k8s-extension show \
    --name microsoft.azuredefender.kubernetes \    --cluster-type connectedClusters \    --cluster-name <cluster-name> \    --resource-group <resource-group> \    --query provisioningState

The expected output is Succeeded. (Docs: Verify Defender for Containers on Arc-enabled Kubernetes)

5.3 Verify sensor pods

kubectl get pods -n kube-system -l app=microsoft-defender

# If you don’t see anything in kube-system, also check the mdc namespace:
kubectl get ds -n mdc
kubectl get pods -n mdc

This is the simplest “is the sensor deployed?” check. If the DaemonSet exists and the pods are Running, you’re in good shape.

(Docs: Verify Defender for Containers on Arc-enabled Kubernetes)

5.4 Verify in the portal

This is the “did Azure actually receive the signals?” check.

After you’ve deployed the Defender extension and the sensor is running, go to Microsoft Defender for Cloud and look at Security alerts (or the Alerts view in the Defender for Cloud experience). If you just ran the simulator (next step), this is where you’ll see the resulting alerts.

It can take a bit of time (think minutes, not seconds) for the cluster and alerts to show up after onboarding. (Docs: Verify Defender for Containers on Arc-enabled Kubernetes)

5.5 (Optional) Prove runtime detection by simulating alerts

If I want hard proof that the sensor-backed detections are flowing end-to-end, I use Microsoft’s Kubernetes alerts simulation tool.

It has two prerequisites that matter in practice:

Defender for Containers is enabled and the Defender sensor is deployed.
I have admin permissions on the cluster.

Then I download and run the simulator:

curl -O https://raw.githubusercontent.com/microsoft/Defender-for-Cloud-Attack-Simulation/refs/heads/main/simulation.py
python simulation.py

After it runs, I go back to Defender for Cloud and look at the alerts that were generated:

(Docs: Kubernetes alerts — Kubernetes alerts simulation tool)

5.6 Inspect the alert details (example: binary drift)

To make this feel real (and to sanity-check what Defender is actually flagging), I open one of the generated alerts and look at the Alert details pane. For example, the “A drift binary detected executing in the container” alert includes fields like the suspicious process path, command line, parent process, and the affected Arc-enabled Kubernetes resource.

Step 6 — Troubleshooting (the short list)

6.1 If an extension is stuck, check egress first

Arc-required outbound URLs: (Docs: Azure Arc-enabled Kubernetes network requirements)
Defender-required outbound endpoint (*.cloud.defender.microsoft.com:443) (Docs: Enable Defender for Containers on Arc-enabled Kubernetes (portal))

6.2 If things drift over time

The Arc extensions doc notes that if Arc agents don’t have network connectivity for an extended period, an extension can transition to Failed, and you may need to recreate the extension. (Docs: Deploy and manage Arc-enabled Kubernetes extensions)

Closing thoughts

If you’re running Kubernetes outside AKS, it’s easy to end up with fragmented security tooling. The Arc + Defender for Containers pattern is one of the cleaner ways I’ve found to bring:

centralized visibility,
actionable runtime alerts,
and runtime security signals

into a hybrid Kubernetes estate—without replatforming.

In future posts, I’ll explore what else we can do with Kyma + Azure Arc + Azure beyond Defender for Containers (observability, more security patterns, etc.).

References (Microsoft Learn)

Custom Domain Service in SAP BTP Build Work Zone (Standard Edition)

2026-02-03T06:12:27.191000+01:00

Hello Everyone,

After analyzing and successfully implementing Custom Domain Service in SAP Build Work Zone, Standard Edition, I’m writing this blog to share my learnings. This post explains the concept of Custom Domain Service in SAP BTP and provides end-to-end steps to configure and use it with SAP Build Work Zone.

This blog will help you get started with SAP Custom Domain Service in SAP BTP Build Work Zone (Standard Edition).

Business Requirement

Our client required the use of a custom (client-specific) domain instead of the SAP standard domain.

By default, when accessing an SAP Build Work Zone site, the URL looks like this:

https://<SubAccount>.launchpad.cfapps.<DataCenter>.hana.ondemand.com/site/<site-alias>#Shell-home

(Here, we are using SAP Build Work Zone – Standard Edition.). We can use it for advanced edition too.

The requirement was to replace this with a client-friendly URL, for example:

https://abc.com  
OR  
https://abcservices.abc.com

We initially tried redirecting traffic from
https://abcservices.abc.com to the SAP BTP Work Zone URL.
However, this approach didn’t meet the requirement because:

Network-level redirection works, but
The browser address bar changes to the SAP BTP URL,
The client URL (https://abcservices.abc.com) is no longer visible.

To solve this, we implemented SAP Custom Domain Service.

Prerequisites

Before starting the configuration, ensure the following prerequisites are met:

1. Enable Custom Domain Service

Add Custom Domain Service to your subaccount with the Standard plan.

Note: Another plan exists but is deprecated at the time of writing this blog.

SAP Help Document:
https://help.sap.com/docs/build-work-zone-standard-edition/sap-build-work-zone-standard-edition/setting-up-custom-domain

Below is the screen shot from sub account for reference:

Please note SAP will charge based on how many certificate you have uploaded in the Cusotm Domain Manager irrespective of Number of Custom Domain.

2. Finalize Reserved and Custom Domains

Finalize your reserved domain and custom domains in advance.

Do’s:

Do not rush this step.
Finalize domains separately for Non-Prod (DEV & QA) and Prod subaccounts.
Changing domains later can be complex and time-consuming.

Dont’s:

Do not signed the CSR form Trusted CA authority because it involved cost and time.
If possible dont configure the Non Prod and Prod Custom domain in single custom domain manager because it will mess the things. Try to keep the Custom Domain Service for Production seperately.
Dont configure the Custom Domain Manager for Production untill you get success in the Non Prod environment.

3. Runtime Destination Naming

Ensure the runtime destination names are finalized as per project standards, as these are referenced by applications.

Implementation Steps

Step 1: Define a Default Site

A default site is the site that opens when no site ID is specified in the URL.

Key points:

A default site is configured per custom domain.
It does not affect all domains in the subaccount.
A custom domain can be mapped to only one entry point, which is why it’s mapped to the default site and not to a specific site. Below is the screen shot of the default site:

Step 2: Identify the Reserved Domain

The reserved domain should be the parent domain, for example:

abc.com or abcservices.abc.com

The custom domain is created using the reserved domain, such as:

wz.abcservices.abc.com

Step 3: Define Custom Domains for Applications

Create custom domains for the following applications as needed:

SAP Build Work Zone
On-Premise Backend Systems (S/4HANA, CRM, BW, etc.) – Optional
Identity Authentication Service (IAS) – Optional

IAS works with the SAP standard domain by default. A custom domain for IAS is optional.

IAS Considerations

In our case, we did not configure a custom domain for IAS because:

IAS requires a separate CSR and CA-signed certificate.
This involves additional cost.
Wildcard certificates used in Custom Domain Manager do not work for IAS.

Reference Documents:

Step 4: Configure Custom Domain Manager

Add the reserved domain and custom domains in Custom Domain Manager.

Required Roles:

Assign the following roles to the user (Default or Custom IAS):

Custom Domain Administrator – Manage configurations
Custom Domain Viewer – View configurations

Once roles are assigned, you can access Custom Domain Manager from the subaccount.

Step 5: Create SaaS Routes

Create a SaaS route for each custom domain.
These routes act as redirection endpoints for:

SAP Build Work Zone
Backend systems (if applicable)

Step 6: Create TLS Configuration

Create a TLS configuration for secure communication.

SAP Help Document:
https://help.sap.com/docs/custom-domain/custom-domain-manager/manage-tls-configurations

Step 7: Generate CSR (Certificate Signing Request)

Generate a CSR from Custom Domain Manager and get it signed by a trusted Certificate Authority (CA).

CSR Generation Options

Option A: Individual Certificates
Generate one CSR per domain, for example:

s4.abcservices.abc.com
crm.abcservices.abc.com
bw.abcservices.abc.com

Option B: Wildcard Certificate
Generate a wildcard CSR:

CN: *.abcservices.abc.com  
SAN: *.abcservices.abc.com, abcservices.abc.com

Certificate Signing Guidelines

Internal network → Internal CA is acceptable and all the applicaiton will work.
Public access → Internal CA will cause browser warnings as below and navigation to the backend
Use a trusted CA like DigiCert if you want to access the custom domain publically.

Important Notes:

Verify CN and SAN before submitting CSR.
Certificates are valid only for the Custom Domain Manager instance from which the CSR was generated.
Non-Prod certificates cannot be reused in Prod.
We have generated the Wild Card Certificate for Production and Single Certificate (Included all SAN) for Non Prod System. Below is the Certificate Screen shot:

DigiCert Reference:
https://docs.digicert.com/en/certcentral/manage-certificates/reissue-an-ssl-tls-certificate.html

(Optional) IAS CSR Generation

Wildcard certificates do not work for IAS.
A separate CSR and certificate are required.

We skipped IAS custom domain due to additional cost and renewal overhead.

Step 8: Upload and Activate Certificate

Once signed, upload the certificate to Custom Domain Manager.

The certificate package includes:

Actual certificate
Intermediate certificate
Root certificate

Certificate Chain Format

Actual Certificate  
+ Intermediate Certificate  
+ Root Certificate

Tips:

Combine the full chain in a text file.
Remove extra spaces or blank lines.
Activate the certificate after upload.

Once activated:

Certificate expiry days are visible.
Renewal can be planned proactively.

Final Result

After successful activation, SAP Build Work Zone is accessible using the custom domain:

https://wz.abccompany.company.com

Errors that can occur: After all the configuration, If you stuck in the IAS authentication while accessing the work zone and getting the below error then add the custom domain in the IAS application:

Add you custom domain in the following path in the IAS if not came automatically:

Login to IAS -> Applications & Resources -> Applications -> Select the Application of Build Work Zone -> Single Sign On -> OpenID Connet Configuraiton and then in the Redirect URIs andPost Logout Redirect URIs section add the URl as https://*.abcservices.abc.ae/** (Your custom domain so that IAS will trust this domain)

Conclusion

I hope this blog helps you understand the Custom Domain Service concept and implement it successfully in SAP Build Work Zone projects.

Happy learning and implementing! 🚀

Regards,
Rohit Gera

Q4 2025 Quarterly Release Highlights: SAP BTP Security and Identity & Access Management

2026-02-10T09:00:00.021000+01:00

In the last quarter of 2025, we release a number of new features, as well as the SAP Key Management Service.

Want the full overview for SAP Cloud Identity Services? You’ll find a list of all new feature announcements for SAP Cloud Identity Services in the SAP Cloud Identity Services Release Notes on the SAP Help Portal.

SAP Cloud Identity Services: Use Data Control Language (DCL) to Define Authorization Policies

Developers define authorization policies in SAP Cloud Identity Services, using an SQL-like language - the data control language (DCL). Administrators can restrict base policies and combine authorization policies into a new authorization policy. For more details, please check the SAP Help Portal.

SAP Key Management Service

We released the SAP Key Management Service (KMS), which puts customers in control of their data across SAP cloud services and products. By managing their own encryption keys, customers decide exactly who can access their information.

With SAP KMS, data remains inaccessible to any external party, including SAP, government agencies, or legal authorities, unless the customer explicitly authorizes access. The service enables customers to securely create, manage, and control the encryption keys used to protect their data, and helps ensure that encryption and decryption can occur only with their approval.

SAP Cryptographic Library

The latest SAP Cryptographic Library release (version 8.6) supports quantum-safe cryptography and contains updated compliance certifications. It introduces a quantum-safe TLS 1.3 handshake using a hybrid key exchange that protects encrypted communications even against future quantum attacks.

In addition, SAP’s FIPS crypto kernel has achieved FIPS 140-3 certification, meeting strict security requirements for regulated industries. Together, these enhancements help customers future-proof their data protection while maintaining compliance. For more information, check our latest blog as well as release notes 3685428 - Fixes and features in CommonCryptoLib 8.6.2 and 1848999 - Central Note for CommonCryptoLib 8 (SAPCRYPTOLIB).

Application Vulnerability Report for SAP BTP

Frequent security issues in open-source components endanger business data in applications. Use the application vulnerability report to detect and remediate any vulnerabilities in your SAP BTP landscape. The application vulnerability report focuses on detecting publicly-known security vulnerabilities based on Common Vulnerabilities and Exposures (CVEs). It's crucial to solve such vulnerabilities quickly as attackers are generally aware of them and might try to break into vulnerable systems. Check our blog for details.

Stay connected

Want to stay up to date on our services? Join our SAP BTP Security and SAP Cloud Identity Services communities!

UI for the BTP Application Vulnerability Report

2026-02-10T22:42:33.106000+01:00

SAP recently introduced the Application Vulnerability Report for Cloud Foundry applications on BTP. It is a tool that scans your deployed applications for known vulnerabilities and exposes the findings through an API. If you haven't seen it yet, check out the official announcement: https://community.sap.com/t5/technology-blog-posts-by-sap/introducing-application-vulnerability-report-for-cloudfoundry-applications/ba-p/14281684

The API is great, but what was missing is an interface to browse, search, filter, sort and export those findings. So I built one. In this blog post I'll walk you through the open-source UI I created on top of the BTP Application Vulnerability Report API.

Problem

The Application Vulnerability Report API provides: vulnerability descriptions, severity levels, affected packages, CVE identifiers and the full organizational context (global account, sub-account, space, org). However, consuming a raw API to get an overview of your security posture is not practical for most teams. You need to be able to:

Quickly scan through all findings at a glance
Sort by severity, application name or date to prioritize remediation
Filter by sub-account, space, organization or any other column
Search across all findings with a free-text search
Export the full report to Excel for offline analysis or sharing with stakeholders

Solution

That's what I tried to solve by adding this UI: a full SAPUI5 frontend backed by a CAP Node.js service that proxies the BTP API, deployed via the managed approuter on BTP. The CAP layer might be a bit overkill at this point but it offers flexibility for future improvements.

The first version comes with the following features:

Sorting: Click column headers to sort findings
Filtering: Right-click cells or use column menus to filter by severity, application, sub-account, space or any field
Free-Text Search: Search across all finding properties using CVE numbers, package names or application names
Export to Excel: Generate formatted .xlsx files with all 15 fields including recommendations, dates, finding IDs and CVSS scores
Severity Indicators: Color-coded findings (Critical/High in red, Moderate in orange, Low in blue) for instant visual prioritization

Architecture Overview

The project consists of two parts:

CAP Node.js Backend: A lightweight OData V4 service that acts as a proxy to the BTP Application Vulnerability Report API. It connects to the external API via a BTP Destination with OAuth2 authentication. The CAP service defines the Findings entity as a projection on the external service model and uses api.run(req.query) to forward OData queries. At this point, the only value of having CAP is for merging some array fields into one single column:

SAPUI5 Frontend: A freestyle UI5 application with a table to show the overview and provide some additional functionalities like sorting, filtering and an export to excel. Now thinking about it, this could’ve been a Fiori Elements app as well. The app is deployed to the HTML5 Application Repository and served via the managed approuter of SAP Build Work Zone.

Getting It Up and Running

Prerequisites

Node.js >= 18
SAP CAP CLI (npm i -g @sap/cds-dk)
Cloud MTA Build Tool (npm i -g mbt)
CF CLI with the MTA plugin
A BTP subaccount with the Application Vulnerability Report service enabled

Step 1: Clone the Repository

git clone https://github.com/lemaiwo/btp-application-vulnerability-report-ui.git
cd btp-application-vulnerability-report-ui
npm install

Step 2: Create the BTP Destination

In your BTP subaccount, create a destination named "BTPVulnerabilityReport" that points to the Application Vulnerability Report API. Configure it with OAuth2ClientCredentials authentication using the credentials from your service key.

Step 3: Build and Deploy

mbt build -t gen --mtar btpvulnerabilityreport.mtar
cf deploy gen/btpvulnerabilityreport.mtar

The MTA deployment creates:

A CAP Node.js backend application
An XSUAA service instance for authentication
A Destination service instance (with HTML5 runtime enabled)
An HTML5 Application Repository entry for the UI5 app

Step 4: Access the App

The application is deployed using the managed approuter pattern. You can access it through SAP Build Work Zone by adding it as an application tile. The Fiori Launchpad integration is pre-configured with the semantic object "VulnerabilityReport" and action "display".

Local Development

For local development, run cds watch from the project root (not ui5 serve from the app folder). The cds-plugin-ui5 plugin serves the UI5 app directly from the CAP server. To test against the real BTP API locally, use the hybrid profile: cds watch --profile hybrid after binding the destination service with cds bind.

No Database Required

The application does not use a database. All data comes directly from the BTP API in real-time. This keeps the architecture simple and ensures you always see the latest findings without any synchronization concerns.

What's Next?

The current version uses the managed approuter of SAP Build Work Zone for serving the application. I'm considering adding a standalone approuter configuration as an alternative for scenarios where Work Zone is not available or needed.

Other ideas for future enhancements include dashboard charts for severity distribution, drill-down to individual finding details and scheduled notifications for new critical findings.

Contributions and feedback are welcome! The full source code is available on GitHub:

https://github.com/lemaiwo/btp-application-vulnerability-report-ui

References

Introducing Application Vulnerability Report for CloudFoundry Applications (SAP Community Blog): https://community.sap.com/t5/technology-blog-posts-by-sap/introducing-application-vulnerability-report-for-cloudfoundry-applications/ba-p/14281684
GitHub Repository: https://github.com/lemaiwo/btp-application-vulnerability-report-ui

The Hidden Threat to Your Clean Core: Variant Governance in S/4HANA

2026-02-11T21:50:33.739000+01:00

By Atul Joshi — Lead SAP Architect, Utilities & Clean Core Specialist

Introduction

Organizations invest millions in S/4HANA transformations, aiming for a Clean Core, agile upgrades, and a future‑proof digital landscape. We move custom code to BTP, rationalize interfaces, and modernize processes.

Yet one silent, often overlooked threat can undermine all of that work: uncontrolled variant changes in production batch jobs.

A single unauthorized variant change can cause incorrect billing, incomplete financial postings, or regulatory reporting issues. These failures are not technical—they are governance failures. And they can compromise Clean Core integrity even when no Z‑code exists.

Why Variant Governance Fails in Utilities and S/4HANA Landscapes

1. “Temporary Fix” Syndrome

A user changes a variant “just for today” and forgets to revert it.

2. Lack of Awareness

Users do not understand the downstream impact of altering a production variant.

3. Over‑Authorization

Security roles grant variant maintenance access where only execution is required.

The result is a silent failure that may not surface until weeks later—after financial cycles close, billing runs complete, or regulatory reports are submitted.

A Real‑World Case: The Variant That Broke a Month of Processing

A nightly batch report was scheduled using Variant X, configured to process all company codes. It ran successfully for months.

One day, a well‑meaning user modified Variant X and restricted it to a single company code, assuming it was a temporary adjustment.

No one noticed.

For the next month, the batch job processed only that one company code. No dumps, no warnings, no alerts. The issue surfaced only during reconciliation, when the business noticed missing postings across multiple entities.

By then:

Downstream reports were incorrect
Financial data was incomplete
Audit trails were inconsistent
Cleanup required days of effort

This was not a technical issue. It was a governance failure—and a perfect example of how a single variant change can undermine Clean Core stability.

Why This Threatens Clean Core

Clean Core is not only about removing custom code. It is about predictability, stability, and governance.

A single variant change can:

Break standardized processes
Trigger incorrect financial or billing results
Create audit and compliance risks
Force emergency patches
Introduce new technical debt

You can have zero Z‑code and still have a “dirty core” if your variants are uncontrolled.

My Approach to Variant Hardening

To address this risk, I use a three‑layer governance model that protects mission‑critical batch processes. This approach combines technical controls with operational discipline.

Layer 1: Protect Variant Flag — First Line of Defense

Every production variant should have the Protect Variant flag enabled (SE38 or program RSVARATT).

How it works:

Only the creator or last protector can modify the variant. Others can execute it, but fields become read‑only.

Benefit:

Prevents casual or accidental modifications.

Limitation:

It is a single point of failure—additional layers are required.

Layer 2: SAP Security Authorization — Granular Access Control

This is the enterprise‑grade safeguard.

Key object: S_PROGRAM

Key field: P_ACTION

Best practice:

Business users → SUBMIT only
Variant maintenance (VARIANT) → restricted to a small governance group

Impact:

Even if someone attempts to unprotect a variant, they cannot save changes without the correct authorization.

Layer 3: ABAP Validation — The Final Safety Net

For critical programs, embed validation logic inside the ABAP code.

Example:

abap

AT SELECTION-SCREEN.

IF sy-batch = 'X'.

IF s_company_code IS INITIAL.

MESSAGE 'Company Code is mandatory for batch execution. Job aborted.' TYPE 'A'.

ENDIF.

IF p_date_from > p_date_to.

MESSAGE 'Invalid date range. Job aborted.' TYPE 'A'.

ENDIF.

Result:

Even if a variant bypasses the first two layers, the program aborts before processing incorrect data.

The Executive Mandate: Variant Governance as a Clean Core Requirement

Variant governance must be elevated from a technical detail to a strategic governance priority.

As architects, we must:

Educate business teams
Enforce governance protocols
Treat variant control as part of Clean Core
Elevate this topic to leadership

The cost of prevention is minimal compared to the cost of correction.

By implementing this 3‑layer protocol, organizations can:

Protect data integrity
Ensure compliance
Improve operational stability
Safeguard their Clean Core investment

This is not just configuration—it is operational excellence.

Let’s Discuss

What challenges do you face in managing variants in your SAP landscape? Have you experienced a variant‑related incident?

Share your experiences below—let’s architect better governance together.

SAP BTP XSUAA Security Configuration Comparison: Attribute-Based vs. Authority-Based Approaches

2026-02-18T03:27:30.148000+01:00

In SAP Business Technology Platform (BTP) Cloud Foundry applications, configuring XSUAA (Extended Services for User Account and Authentication) via the xs-security.json file is a critical step for secure authentication and authorization.

Sample Application used for this article - "Message Reprocessing Application". This scenario try to cover 2 roles - "ReprocessViewer" and "ReprocessAdministrator".

Two main approaches exist:

Configuration A: Explicit attribute-based – manual mapping and control
Configuration B: Authority-based – automatic acceptance of IDP attributes (recommended for most cases)

Understanding the differences helps you balance security, compliance, simplicity, and development speed.

Quick Comparison Table

Feature                          | Config A (Explicit Attributes)          | Config B (Authority-Based)
---------------------------------|-----------------------------------------|--------------------------------------------
attributes section               | ✅ Present (defines email, etc.)        | ❌ Not needed
attribute-references in roles    | ✅ Yes (links attributes to roles)      | ❌ Not present
authorities array                | ❌ Not used                              | ✅ "$ACCEPT_GRANTED_AUTHORITIES"
oauth2 grant-types               | ❌ Uses defaults                         | ✅ Explicit list (authorization_code + others)
oauth2 autoapprove               | ❌ Not set (shows consent screen)       | ✅ true (smooth internal login)

Key takeaway from the table

Configuration A: Explicit Attribute-Based Approach

Structure (xs-security.json excerpt):

JSON

{
  "xsappname": "my-app-reprocess-v2",
  "tenant-mode": "dedicated",
  "description": "Message Reprocessing Application - Security Configuration",
  "scopes": [
    {
      "name": "$XSAPPNAME.ReprocessViewer",
      "description": "View messages, content, and statistics (read-only access)"
    },
    {
      "name": "$XSAPPNAME.ReprocessAdministrator",
      "description": "Full administrative access including reprocess operations and CRUD"
    }
  ],
  "attributes": [
    {
      "name": "email",
      "description": "User email address",
      "valueType": "string"
    }
  ],
  "role-templates": [
    {
      "name": "ReprocessViewer",
      "description": "Read-Only Access - View messages and statistics",
      "scope-references": ["$XSAPPNAME.ReprocessViewer"],
      "attribute-references": ["email"]
    },
    {
      "name": "ReprocessAdministrator",
      "description": "Full Administrative Access - CRUD operations and reprocess actions",
      "scope-references": [
        "$XSAPPNAME.ReprocessAdministrator",
        "$XSAPPNAME.ReprocessViewer"
      ],
      "attribute-references": ["email"]
    }
  ],
  "role-collections": [
    {
      "name": "MessageReprocessViewersRC",
      "description": "Message Reprocess Viewers - Read-only access",
      "role-template-references": ["$XSAPPNAME.ReprocessViewer"]
    },
    {
      "name": "MessageReprocessAdministratorsRC",
      "description": "Message Reprocess Administrators - Full access",
      "role-template-references": ["$XSAPPNAME.ReprocessAdministrator"]
    }
  ],
  "oauth2-configuration": {
    "credential-types": ["binding-secret", "x509"],
    "redirect-uris": ["https://*.cfapps.example.com/**", "http://localhost:*/**"],
    "token-validity": 3600,
    "refresh-token-validity": 86400
  }
}

Advantages

Explicit control over exposed attributes
Fine-grained security and compliance
Enables attribute transformation and ABAC

Disadvantages

Higher maintenance
More complex configuration
Less flexible with IDP changes

When to use: Regulated industries (healthcare, finance, government), ABAC needs, multi-tenant SaaS, strict governance.

Configuration B: Authority-Based Approach (Recommended)

Structure (xs-security.json excerpt):

JSON

{
  "xsappname": "my-app-reprocess-v2",
  "tenant-mode": "dedicated",
  "description": "Message Reprocessing Application - Security Configuration",
  "scopes": [ /* same as above */ ],
  "role-templates": [ /* same as above, without attribute-references */ ],
  "role-collections": [ /* same as above */ ],
  "authorities": ["$ACCEPT_GRANTED_AUTHORITIES"],
  "oauth2-configuration": {
    "grant-types": ["authorization_code", "client_credentials", "refresh_token"],
    "credential-types": ["binding-secret", "x509"],
    "redirect-uris": ["https://*.cfapps.example.com/**", "http://localhost:*/**"],
    "token-validity": 3600,
    "refresh-token-validity": 86400,
    "autoapprove": true
  }
}

Advantages

Simplicity and minimal config
Automatic handling of standard IDP attributes
Lower maintenance, faster development
Seamless with SAP IAS, Azure AD, Okta

Disadvantages

Less granular control (all attributes passed)
Potential over-exposure

When to use (most cases): Standard enterprise apps, RBAC, rapid development, microservices, agile environments.

Deep Dive: Key Differences

Attributes & attribute-references — Explicit in A, automatic in B via $ACCEPT_GRANTED_AUTHORITIES
Authorities — Special directive in B accepts all granted attributes/scopes from trusted IDP
OAuth grant-types & autoapprove — Explicit in B for predictability and better UX (no consent screen for internal apps)

JWT Token Examples

Configuration A (Explicit):

JSON

{
  "user_name": "john.doe",
  "email": "john.doe@example.com",
  "scope": ["my-app-reprocess-v2.ReprocessViewer"],
  "xs.user.attributes": { "email": ["john.doe@example.com"] }
}

Configuration B (Automatic):

JSON

{
  "user_name": "john.doe",
  "email": "john.doe@example.com",
  "given_name": "John",
  "family_name": "Doe",
  "scope": ["my-app-reprocess-v2.ReprocessViewer"],
  "xs.user.attributes": { "email": ["john.doe@example.com"], "department": ["Engineering"], "cost_center": ["CC-1234"] }
}

Application Code Impact (Examples)

SAP CAP (Node.js) – Configuration B:

JavaScript

this.before('READ', 'Messages', async (req) => {
  const userEmail = req.user.attr.email;
  const department = req.user.attr.department;  // extra attributes available
  // ...
});

Spring Boot (Java) – Configuration B:

Java

String email = token.getAttributeFromClaimAsString("email");
String department = token.getAttributeFromClaimAsString("department");

Migration Guide & Troubleshooting

(Refer to the detailed steps in original content for From A → B and vice versa, plus common issues like missing attributes, invalid grant types, consent screens, token size.)

Security & Performance Best Practices

Principle of least privilege
Validate JWT properly (@sap/xssec)
Specific redirect URIs (avoid wildcards in prod)
Appropriate token lifetimes
Prefer X.509 in production
Monitor token size (switch to A if >4KB)

Recommendations by Use Case

Use CaseRecommendedRationaleInternal Enterprise AppConfiguration BSimplicity & standard integrationRegulated IndustryConfiguration AExplicit governance & audit trailRapid Prototype/MVPConfiguration BMinimal configAttribute-Based AuthorizationConfiguration ARequired for ABAC

Conclusion For most SAP BTP applications in 2025, go with Configuration B (Authority-Based) — it delivers simplicity, flexibility, and aligns with modern OAuth/OIDC patterns while reducing maintenance.

Only choose Configuration A when you need strict attribute control, custom transformations, or operate in highly regulated environments.

What approach are you using in your SAP BTP projects? Have you migrated between the two? Share your experiences or questions in the comments — happy to discuss architecture or troubleshooting!

#SAPBTP #XSUAA #CloudFoundry #SAPSecurity #Authorization #IdentityManagement #SAPDeveloper

When Business Asks for a Bicycle, Don't Build a Spaceship

2026-02-21T19:02:14.003000+01:00

When Business Asks for a Bicycle, Don't Build a Spaceship

I have developed a comprehensive playbook demonstrating how modern SAP tools and AI can deliver solutions in DAYS instead of MONTHS.

The shocking math:
- Traditional approach: 6 months, $650K in delayed value
- SAP tools + AI: 1 week, $25K in delayed value

This isn't just theory—it's a practical guide that covers:
- CDS Views for data modeling
- CAP for service generation
- Fiori Elements for instant UIs
- Integration Suite for connectivity
- AI to accelerate everything

https://www.linkedin.com/posts/rajesh-putumbaka-456267101_sap-btp-ai-development-playbook-ugcPost-7431029390173696001-y7Yn?utm_source=share&utm_medium=member_desktop&rcm=ACoAABnYP8IBvlY4GDRmR8utVFLHXZ61gUvSa-0
Download the full playbook (PDF attached) and share your thoughts: Have you encountered the "perfect is the enemy of good" trap in your SAP projects?
#SAP #DigitalTransformation #AI #SAPCommunity

SAP Build Work Zone: Tile Opens(content federation) but App Fails with ‘IP Address Cannot Be Found

2026-03-02T10:49:06.511000+01:00

In my SAP Build Work Zone (Standard Edition) environment, I faced an issue where a dynamic tile loaded successfully through content federation, but clicking the tile caused the application to fail with a browser error:

ERR_NAME_NOT_RESOLVED – The IP address of the server could not be found

The failing URL always contained a very long auto‑generated hostname.

Interestingly, the dynamic tile itself worked correctly (e.g., OData count displayed), but navigating to the corresponding SAP Fiori app consistently failed. This clearly indicated that the issue was not with backend connectivity or destinations, but with the content runtime URL generated by Work Zone.

Please refer the screenshots.

SAML Based Single Sign-On Setup with SAP Identity Authentication Service

2026-03-02T22:06:37.306000+01:00

Introduction

About SAP Datasphere

SAP Datasphere is SAP’s unified data service for integrating, modeling and governing data across hybrid and cloud environments. As part of SAP’s Business Technology Platform (BTP), it supports enterprise-scale analytics, governance and collaboration.

Need for SSO

Traditional password-based authentication poses risks such as credential sprawl and inconsistent access control. Implementing SSO in Datasphere enhances:

Security: Centralized identity and access management.
User Experience: Seamless access without repetitive logins.
Compliance: Alignment with enterprise security and governance standards.
Efficiency: Reduced administrative overhead for user provisioning and password resets.

Architecture Overview

SSO in SAP Datasphere is typically implemented using SAML 2.0 (Security Assertion Markup Language) through SAP Cloud Identity Services – Identity Authentication (IAS).

Components Involved

SAP Datasphere Tenant: The target system for SSO-enabled access.
SAP Cloud Identity Services: Identity Authentication (IAS): Acts as the trusted authentication broker.
Corporate Identity Provider (IdP): Provides user authentication.
SAP BTP Subaccount: Links Datasphere to IAS through service bindings.

Authentication Flow

Prerequisites

Before enabling SSO, ensure the following prerequisites are met:

SAP Datasphere Tenant - Provisioned and accessible via SAP BTP
SAP Cloud Identity Services (IAS) - Tenant available and linked to BTP subaccount
Corporate Identity Provider - Configured to support SAML 2.0
Admin Access - Administrator roles in Datasphere, IAS and IdP
Email Domain - Verified in IAS for trusted domain mapping

You must have the system owner role for your SAP Datasphere tenant to perform this configuration.

Configuration Steps

Step 1: Access IAS Tenant

Log in to your SAP Cloud Identity Services – Identity Authentication admin console.
Under Applications & Resources → Applications, create a new application named “SAP Datasphere Test”.

Step 2: Download Metadata

Login to Datasphere tenant: System -> Administration -> Security
Authentication Method: SAML Single Sign On (SSO)
SAML Single Sign On (SSO) Configuration: Step1 - Download Service Provider Metadata

Step 3: Configure SAML Settings in IAS

SAML 2.0 Configuration: Define from Metadata -> Upload the metadata downloaded from Datasphere tenant

Subject Name Identifier

Source - Identity Directory and Value - Email

Attributes:

Maintain below values in Self-defined attributes.

For SAML attributes to be recognized it is also important that the “Groups” attribute contains the value of “sac”.

Conditional Authentication

Select “Default Identity Provider” - > Your IDP

“Check” the checkbox – Allow users stored in Identity Authentication service to login.

Download Metadata file from SAML 2.0 Configuration:

Step 4: Configure Trust in Datasphere

In SAP Datasphere → System → Administration → Security Settings → Identity Provider Configuration.
Upload Identity Provider Metadata -> Upload.

3. Choose a user Attribute to map to your identity provider -> Email. It should map to User ID, Email or a custom attribute. The attribute will be used to map users from your existing SAML user list to SAP Datasphere. The selected user attribute must match the NameID (Subject Name Identifier) used in your custom SAML assertion.

4. Confirm that the mapping is working -> Verify Account

Copy the URL and open it in a private/incognito browser window to avoid reusing an existing session and ensure you are prompted for a fresh login.

Upon successful verification, the Login Credential field will be highlighted with a green border. After confirming this, select “Convert” to complete the SAML SSO configuration.

Step 5: Test Authentication

Access SAP Datasphere via SSO-enabled URL.
Verify that users are redirected to IAS and authenticated by the corporate IdP.
Ensure user attributes and roles are correctly mapped in Datasphere.

Best Practices

Use HTTPS for all communications between systems.
Enable Multi-Factor Authentication (MFA) at the corporate IdP level.
Periodically rotate SAML certificates.
Maintain audit logs in IAS for compliance.

Conclusion

Enabling SSO in SAP Datasphere strengthens enterprise security while enhancing usability and operational efficiency. Centralizing authentication through IAS and your corporate identity provider reduces the risk of credential misuse, simplifies onboarding, and improves user productivity. As organizations continue to adopt cloud and hybrid data platforms, a well-governed identity strategy becomes essential. This SSO implementation helps establish that foundation and supports future growth and integration initiatives.

SAP Sources: https://help.sap.com/docs/SAP_DATASPHERE/9f804b8efa8043539289f42f372c4862/9b26536159354aea9024a99cbbe60b4e.html?locale=en-US

https://help.sap.com/docs/SUPPORT_CONTENT/datasphere/4477056515.html?locale=en-US

Securing Your SAP Sales & Service Cloud V2+ESM Extensions with Application Vulnerability Report-Must

2026-03-08T11:23:27.165000+01:00

As organizations extend SAP Sales & Service Cloud V2 + ESM with custom solutions built on SAP BTP (Business Technology Platform), security becomes paramount. Whether you’re developing CAP-based services, prehooks/posthooks, custom APIs, Autoflow automations, or mashup services using JavaScript, Python, or Java—every extension must undergo rigorous security validation before reaching production environment (Extensions).

This blog explores how the Application Vulnerability Report (AVR) for CloudFoundry applications ensures your SAP Sales & Service Cloud V2 + ESM extensions are production-ready and free from critical security vulnerabilities.

What is Application Vulnerability Report (AVR)?

The AVR is SAP’s built-in security scanning tool for CloudFoundry applications deployed on BTP. It automatically analyzes your applications for:

Known CVEs (Common Vulnerabilities and Exposures) in dependencies
Outdated libraries with security patches available
Configuration weaknesses in application libraries
Zero-Day Vulnerabilities
Container image vulnerabilities (for Docker-based deployments)

Key Features:

Automated scanning upon deployment on weekly scan
Detailed findings with severity ratings (Critical, High, Medium, Low)
Remediation guidance with version upgrade recommendations
Compliance alignment with industry security standards

Reference: Introducing Application Vulnerability Report for CloudFoundry Applications

Why Security Scanning Matters for SAP Sales & Service Cloud V2 + ESM Side by Side Extensions

This checklist is mandatory—without any compromise—to ensure that no security vulnerabilities exist in your extensions before they are deployed to the Production environment.

SAP Sales & Service Cloud V2 +ESM serves as the backbone for customer-facing operations.

Any extensions developed on BTP—whether for data enrichment, workflow automation, or third‑party integrations—introduce potential attack vectors if not properly secured.

Additionally, many side‑by‑side extensions that are developed by your developers, who may not always account for all required security controls to ensure the application or APIs are tightly governed. In some cases, extensions may also have been built using AI-assisted development, which can inadvertently introduce vulnerabilities in libraries or application logic, including risks such as XSS, CSRF, SSRF, RCE and others.

Common Extension Scenarios Requiring AVR:

CAP (Cloud Application Programming Model) Services: Custom business logic exposing OData/REST APIs
Extensibility = External Hook (Prehooks & Posthooks) : Event-driven extensions modifying standard processes
Custom Microservices: Standalone services for specialized business functions
Autoflow Integrations: Low-code automations connecting external systems
Mashup Services: Composite applications combining multiple data sources

The Risk: Vulnerabilities in dependencies, libraries outdated, insecure coding practices, or misconfigurations can expose sensitive customer data or disrupt critical business processes.

Conclusion

The Application Vulnerability Report is non-negotiable for securing SAP Sales & Service Cloud V2 + ESM extensions. By integrating AVR into your development lifecycle, you:

Protect customer data from exploits
Maintain compliance with security standards
Ensuring No security vulnerabilities violated in your extensions designed for SAP Sales & Service Cloud V2 + ESM
Build trust with stakeholders through proactive risk management

Call to Action for Developers and BTP Admins (Managing your BTP Landscape):

Before you move to production deployment, run AVR and clear all findings.
Your security depends on it.

SAP BTP Audit Log Access Just Got Easier - Here’s What’s New

2026-03-10T11:39:09.623000+01:00

Hello SAP Community,

🚀We’re excited to announce that the new Audit Log Viewer is officially live!

This release brings a faster, clearer, and more intuitive way to explore audit activity. Whether you’re tracking changes, investigating issues, or simply keeping an eye on system activity, the new viewer is designed to help you find what you need quickly and confidently.

🎯Key Changes

1. No More Subaccount-Level Subscription

You no longer need to create a separate Audit Log Viewer subscription for each subaccount. The viewer is now automatically available in every subaccount, with entitlement and subscription setup handled behind the scenes.

2. Global Account Viewer Now Included

Previously, there was no Audit Log Viewer for Global Accounts. With this update, a viewer is now available directly in the BTP cockpit, without creating a dedicated instance. Just open the cockpit and access it from the Global Account level.

The new changes can be referred from the link : What's new for SAP Business Technology Platform

These changes simplify operations, reduce configuration work, and make audit visibility consistent across your entire BTP landscape.

SAP Build Work Zone: Tile Opens(content federation) but App is opening blank in Mobile

2026-03-10T18:08:27.193000+01:00

I am currently integrating a custom role and tile from an on‑premise S/4HANA system into SAP Build Work Zone using the CDM-based content federation (Exposure Version 2).

Everything works fine in Build Work Zone in the browser.
However, when I scan the QR code in SAP Start mobile app, the tile appears correctly — but after tapping the tile, the app opens a blank white screen.

Has anyone experienced this issue where a tile loads correctly in Build Work Zone, but shows a blank screen when launched from SAP Start?

Old Tile Still Appearing in SAP Build Work Zone After Complete Re‑Exposure from S/4HANA

2026-03-10T18:21:19.051000+01:00

Hello Experts,

I am facing an issue with federated content from an on‑premise S/4HANA system to SAP Build Work Zone (Standard Edition).
Our authorization team has removed the old tile and assigned a new tile to the correct custom role, custom catalog, and custom group in S/4HANA.

To ensure a clean setup, I deleted the previous exposure configuration and re‑created the full setup from scratch in:

/UI2/CDM3_EXP_SCOPE (content exposure)
SAP BTP → Build Work Zone → Content Provider → Synchronize Content

Despite repeating the full process multiple times, the old tile continues to appear in Build Work Zone instead of the new one.
The authorization consultant has verified both the new role and the tile assignments several times on the S/4HANA side, and everything looks correct there — but Build Work Zone keeps federating only the old tile.

Has anyone experienced something similar?

I am trying to understand:

Why outdated tile information is still being federated
Whether additional cleanup is required on the CDM or content provider side
If there are any cache layers (S/4HANA, BTP, or Build Work Zone) that must be explicitly cleared
Whether Exposure Version 2 requires specific steps to refresh or replace previously published app IDs

Any advice, known issues, or guidance on how to force Build Work Zone to pick up the updated tile would be greatly appreciated.

Thank you!

Build BTP CAP App with Fiori Integration – Part 2: Implementing End to End App

2026-04-09T10:05:19.668000+02:00

A quick Recall - So far we have completed the Pre-Requisites and set up the BTP Environment for creating/Deploying CAP Application. BTP Trail Account has been created and within Trail sub-account necessary cloud related roles have been assigned. Post that SAP HANA Cloud instance has been created and BAS Set up has been done.

PART 1 Link - Building a CAP App with Fiori Integration – Part 1: Environment & HANA Cloud Setup

As a part of second episode in this CAP Application blog series, we are about to develop an end to end CAP Application with layers of validation of security in a detailed way. This blog helps beginner to build end to end CAP Application.

Flowchart giving overview for complete Process

Ever struggled to deploy a CAP app with HANA + XSUAA + App router?.

I did. After multiple failures, here is a complete working guide 👇

BACKEND BUILD :

1. Navigate to BAS->Dev Space and Create new project from Template.

After creating CAP Project Run these Below terminal Commands which has unique operation.

a. This below terminal command to be added which will prepare the CAP project for a real-world cloud environment i.e. SAP BTP. add hana will switch database from SQLITE to HANA Cloud & add xsuaa will enable authorization for the project. Also When we ran the command cds add xsuaa --for production then CAP automatically generates the security folder xs-security.json.

cds add hana,xsuaa --for production

b. Below terminal command will add blueprint for deployment.

cds add mta

c. Below terminal command will install libraries.

npm install

2. Select CAP Project Option and name the project and select options as below.

3. Click on Finish after selecting all the options.

4. Once Project is created it will be available in the Workspace.

5. We can view the path of the project created using below Terminal command. ( Note : Use Ctrl + ~ to open terminal ).

user: CRUDApp $ pwd

Once this Terminal command is entered the response will come as /home/user/projects/CRUDApp.

6. Now the Project is created. The Aim is to create service instance in Cloud Foundry space dev which I shown in PART 1 and through the service instance the linkage to HANA Cloud central DB Instance will be triggered with runtime HDI Container created. Through this HDI Container the Deployment data will be mapped to runtime DB.

Before getting into next point. Let me give a quick overview on different folder paths/ files in CAP Project that has been created. ( Refer to the workspace image from Point 4. )

a) db/ - This is database schema where we will create CDS Entities/tables and it's relationships. It’s is the source of data structure.

b) app/ - In this folder the front end Fiori Generator App will be mapped which has further navigations to Controllers and views. From here only we will write front end logic.

c) srv/ - This is service folder where api services will be created from backend and if required custom logic can be enabled using node js in js file.

d) .vscode - This is a hidden folder containing configurations specific to Visual Studio Code or BAS. It stores things like your launch configuration and recommended extensions for the project.

e) mta.yaml - Multi-Target Application file is the provides instruction to cloud. It tells SAP BTP how to package and deploy your app, which database to create, which security services to bind, and how much memory to use.

f) package.json - This is the Project Meta data which holds libraries to run project.

Now let's continue with further steps from Backend.

7. Create a file schema.cds as below to /db folder and create Entity bookshop. This Entity is designed to store Book details. The same will be created as table in SAP HANA Cloud.

namespace my.bookshop;

entity Books {
  key ID    : Integer;
  title     : String;
  stock     : Integer;
  author    : String;
}

8. Create a file schema.cds as below to /srv folder. In this Service folder we are adding annotation @requires: 'Admin' which indicates Role required for Authorization.

using { my.bookshop as my } from '../db/schema';

service CatalogService {
    @requires: 'Admin'  // XSUAA Role Required
    entity Books as projection on my.Books;
}

FRONT END BUILD:

1. Click Ctrl + Shift + P and select Open Fiori App Generator as shown below.

2. Since this is a basic app and henceforth Select List Report Template as below.

3. Now select Data source as Local CAP Project and select CAP Project and OData service. After this select on Next button.

4. Give Name to App and Module.

5. Then Deployment configuration should be auto-picked as cloud foundry and If required fill Destination. For this app Im not creating Destination and henceforth selection the option as None. After this select Finish option which will create Fiori App in Project Folder.

VALIDATION :

1. Create a file cat-service.js as below to /srv folder.

const cds = require('@sap/cds')

module.exports = cds.service.impl(async function() {
    const { Books } = this.entities;

    // Logic: Validation BEFORE creating a record
    this.before('CREATE', 'Books', req => {
        const { title } = req.data;
        if (!title || title.length < 3) {
            // This is like an 'E' message in ABAP
            req.error(400, 'Title is too short! Minimum 3 characters required.');
        }
    })
})

2. As per above logic, we are adding some validation before SAVE using Node JS Function. As per this validation if Title length is less than 3 then error will be thrown. Similarly we can use other functions as well to perform business operation which triggers during save, After save etc.

SECURITY:

1. When the Environment was set up in BACKEND BUILD->1.a), we ran the command cds add xsuaa --for production which in turn created the folder xs-security.json.

2. Now the aim is to deploy the app to production and create HTML5 App in BTP. So here we are adding a security layer which tells only Authorized user can access the data. While defining the service in BACKEND BUILD->8. where Admin role is annotated to books entity.

3. Lets create Approuter now and configure JSON to add necessary roles.

4. There are two options for adding Approuters.

a. Right click on mta.yaml file and select Create MTA Module From Template and then select Managed Approuter.

b. If Managed Approuter option is not showing, then below terminal command is a reliable 'Reset' button. It cleans up the MTA configuration and sets up a standalone router that works independently of external BTP subscriptions.

cds add approuter

5. Currently Im going with 4.b) with manual terminal command for adding Approuter. Once that is done then approuter will be added as below in app/ folder.

6. Add below JSON to folder xs-security.json in project which will define the role which is binded in service and yaml.

{
  "xsappname": "my-bookshop",
  "scopes": [
    {
      "name": "$XSAPPNAME.Admin",
      "description": "Admin"
    }
  ],
  "role-templates": [
    {
      "name": "AdminRole",
      "scope-references": [ "$XSAPPNAME.Admin" ]
    }
  ],
  "attributes": [],
  "authorities-inheritance": false
}

DEPLOYMENT:

1. So till now we have built this CAP Application in "Vertical Stack" (Database → Logic → Security → Routing → UI).

2. Now before final deployment lets test the things done till now is correct. Use below terminal command. If everything is fine then You see your database schema, custom logic, approuter config, and Fiori manifest listed.

ls -R | grep -E "schema.cds|cat-service.js|xs-app.json|manifest.json"

3. Now compile all the files to check if any error occurs. Use below terminal commands.

cds compile db/
cds compile srv/
cds compile srv/ --to xsuaa

Note: All these commands should not throw error to proceed with next steps.

4. After Sanity checks, run below command to login to terminal. Note: It will ask for Api Endpoint for first time during login. It can be found from BTP Cockpit -> Overview -> Cloud Foundry Environment -> API End Point.

cf login

5. Now run Deployment command in terminal. This is done to test the app locally. Once testing is completed the app needs to be deployed to Production.

cds deploy --to hana --profile hybrid

6. If cds deploy is not working properly then define step by step process of creating service instance, HDI Containers etc. through terminal commands below. Note: cds deploy will create everything by default so dont use these in combination. use these terminal commands only if cds deploy is not working.

cf create-service hana hdi-shared my-cap-app
cds bind --to my-cap-app
cds env get requires.db --profile hybrid
cds deploy --to hana --profile hybrid

7. Run below commands to deploy the app to production.

mbt build

8. When finished, a new folder named mta_archives/ will appear as below containing Project file.

9. Now do a login again with below command. Give appropriate API Key and user details.

cf login

10. Run below command to Complete final HTML5 App deployment.

cf deploy mta_archives/CRUDApp_1.0.0.mtar

Note: Sometimes Deployment will fail. To avoid these common pitfalls, "Only include essential resources (HANA, XSUAA, Destination, and HTML5) in your mta.yaml and ensure your xsappname in xs-security.json is consistent throughout the project to prevent service plan unavailability and identity mismatch errors on Trial accounts." If something fails, make these changes and delete the service and redeploy. After redeployment dont forgot to add role collections again to make sure Approuters will not cause auth errors.

TESTING

1. Run below Terminal command to test the app locally.

cds watch --profile hybrid

2. After this the app will open in next screen to test it from web level. Note: Make sure your HANA DB Instance is running in HANA Cloud Central which will create entry in DB Level.

3. Now while testing this app we can see the user login screen which will ask for mail and password for login. This is happening due to XSUAA and Approuter. While trying to make entry to the app it will show error forbidden as below.

4. Now run this command below to create service Instance first. Even after cds deploy this is required because cds deploy only talks to the Database (HANA). It does not talk to the Security Service (XSUAA). In SAP BTP, the database (CRUDApp-db) and the security (XSUAA) are two completely separate buildings. This terminal logic is required to enable link.

cf create-service xsuaa application CRUDApp-auth -c xs-security.json

5. Post this navigate to BTP Cockpit -> SubAccount -> Security -> Role Collections and click on Create Button as below.

6. Create Role collection Bookshop_Admin_Group with its Description as below.

7. Now Navigate to the Role collection Bookshop_Admin_Group and click on Edit. Open value help of Role and select the App name from Application Identifier dropdown. After selecting Role Admin which enables Authorization, click save. Follow below images sequentially.

8. After saving, the role will be available in Role collection as below.

9. Now refresh the app and try running, It will work !. Note: Sometimes Auth error will still occur if you test locally. In that case assign your URL to user Alice or deploy and test the app.

10. Also once deployed to HTML5 Apps or Dev space, the app can be directly tested from there as well.

FINAL APP EXECUTION🔥:

1. Now, lets open the app as below.

2. Lets create some incorrect entries as below.

3. Validation Error occurs as per Node js logic for incorrect inputs.

4. While creating valid records, Data gets created as below without any auth error/Forbidden as the custom role collection created and mapped to Admin Role. Note: Unique UUID will be generated for each record as per CAP Entity definition made. The UUID can be viewed in Cloud DB.

5. Now navigate to SAP HANA Cloud and click on ... dots. select option "OPEN IN SAP HANA Database Explorer".

4. Once SAP HANA Database Explorer opens then login to cloud foundry Environment from there.

5. Now select the "+" icon and select HDI Containers options and then select app container specific to app name.

7. From CRUDAPP-db HDI Container, Navigate to Tables and select open data.

8. The Data created from Fiori App is available in Cloud Table as below along with UUID auto-generated.

CONCLUSION:

Hence the overall flow looks as below.

Fiori UI
↓
App router
↓
CAP Service
↓
HANA DB (HDI Container)

With this blog series we learned how to set up environment, enable cloud instance, create end to end CAP Full stack application which has capability to communicate with SAP HANA Cloud instance and create entries over there, enable App routers to CAP App and Enable validation while creating entries.

I hope this blog will be helpful for enthusiasts who are learning CAP !. In future I will create add-on series with steps to deploy this app to SAP Build work zone.

SAP Community - SAP BTP Security

Beta Version of Application Vulnerability Report for SAP BTP Now Available

What is this new service all about?

What does the new application vulnerability report service offer you?

Get started now!

Automating User Offboarding in SAP BTP Across Multiple Subaccounts with PowerShell & BTP CLI

How to Export All Users (with Origins) from All SAP BTP Subaccounts via CLI Automation

New Expert-Guided Implementation: Joule Prerequisites and Activation

Establish the Foundation for Your AI Journey

Workshop Schedule

Why This EGI Matters

What You’ll Learn: Program Overview

What You Will Achieve

How to Register

Related Articles

Secure SAP–AI Integration Using Advantco OpenPGP Services

Configure Role Owner Stage Auto Approval in SAP IAG

Runtime Threat Detection for SAP BTP Kyma with Azure Arc + Microsoft Defender for Containers

Securing an external Kubernetes cluster with Microsoft Defender for Containers (via Azure Arc)

Real-world threats

The solution: Azure Arc + Defender for Containers

How

Step 0 — Pre-flight checklist

Step 1 — Connect the cluster to Azure Arc

1.1 Register providers (if needed)

1.2 Run the connect command

1.3 Verify Arc agents in the cluster

Step 2 — Enable the Containers plan in Microsoft Defender for Cloud

Step 3 — Deploy Defender components to the Arc-enabled cluster

Option A (recommended): Deploy via Defender for Cloud Recommendations

Option B: Deploy manually from the Arc cluster resource

Step 4 (optional) — Programmatic deployment (repeatable automation)

Step 5 — Verify it’s actually working

5.1 Verify Arc connectivity

5.2 Verify Defender extension provisioning

5.3 Verify sensor pods

5.4 Verify in the portal

5.5 (Optional) Prove runtime detection by simulating alerts

5.6 Inspect the alert details (example: binary drift)

Step 6 — Troubleshooting (the short list)

6.1 If an extension is stuck, check egress first

6.2 If things drift over time

Closing thoughts

References (Microsoft Learn)

Custom Domain Service in SAP BTP Build Work Zone (Standard Edition)

Business Requirement

Prerequisites

1. Enable Custom Domain Service

2. Finalize Reserved and Custom Domains

3. Runtime Destination Naming

Implementation Steps

Step 1: Define a Default Site

Step 2: Identify the Reserved Domain

Step 3: Define Custom Domains for Applications

IAS Considerations

Step 4: Configure Custom Domain Manager

Required Roles:

Step 5: Create SaaS Routes

Step 6: Create TLS Configuration

Step 7: Generate CSR (Certificate Signing Request)

CSR Generation Options

Certificate Signing Guidelines

(Optional) IAS CSR Generation

Step 8: Upload and Activate Certificate

Certificate Chain Format

Final Result

Conclusion

Q4 2025 Quarterly Release Highlights: SAP BTP Security and Identity & Access Management

SAP Cloud Identity Services: Use Data Control Language (DCL) to Define Authorization Policies

SAP Key Management Service

SAP Cryptographic Library

Application Vulnerability Report for SAP BTP

Stay connected

UI for the BTP Application Vulnerability Report

Problem

Solution

Architecture Overview

Getting It Up and Running

Prerequisites

Step 1: Clone the Repository

Before you move to production deployment, run AVR and clear all findings.
Your security depends on it.