The SAP Shared Responsibility Model: Who is Responsible for Custom Application Code Security in SAP BTP?

As companies modernize their ERP landscapes through RISE with SAP and move to the cloud, a dangerous assumption takes root: that SAP will automatically handle all security for them. Development teams migrate custom code and extensions to SAP Business Technology Platform (BTP), leverage low-code tools and AI copilots, and assume the platform’s built-in defenses will handle the rest. However, establishing robust enterprise SAP BTP security requires active governance because moving to a secure cloud platform does not automatically make custom applications secure. To keep your enterprise protected, you must understand exactly where SAP’s job ends and yours begins. 

Key Takeaways:

• The Cloud Security Illusion: Moving custom code to SAP BTP does not automatically secure it. The SAP BTP Shared Responsibility Model dictates that while SAP secures the underlying infrastructure, you remain 100% responsible for the security of your custom applications, code, and data.
  
• Configuring vs. Securing: Relying on modern tools like SAP Build or AI copilots requires active security management, not just toggling platform settings. Because these environments enable rapid application creation, you need purpose-built Application Security Testing (AST) to continuously scan, detect, and remediate vulnerabilities in custom application code before deployment.
  
• The Third Layer of Risk: Generative AI increases development speed, but introduces a complex new variable. The foundation of  SAP BTP AI application security lies in treating AI-generated logic just like human-written code—meaning both the generated logic itself and the SAP data permissions it interacts with must be rigorously validated.
  
• Securing the Clean Core: Moving custom code to SAP BTP as part of a Clean Core strategy is only safe if you “Shift-Left” and move security along with it.  Automated, SAP-native Application Security Testing (AST) is essential to catch vulnerabilities before they are deployed to your cloud environment.

The Data Behind the Cloud Complacency

Recent industry trends show that while organizations are rapidly adopting cloud extensions, their security practices are lagging dangerously behind. The threat window is completely unforgiving: Onapsis research shows that new, unprotected Enterprise Resource Planning (ERP) applications provisioned in the cloud are discovered and compromised by attackers in less than 3 hours.

During our recent webinar, The Hidden Risks of AI-Generated SAP Custom Code, we polled our audience and discovered a massive blind spot regarding cloud security ownership. When we asked attendees about their familiarity with the SAP Shared Responsibility Model, the results were revealing. While 26.7% understood the core concepts, a majority (53.3%) admitted they needed a refresher, and 13.3% mistakenly assumed that SAP handles all the security now.

The misconception that SAP automatically “takes care of the security” creates the exact vulnerability attackers rely on. In that same webinar, 61.6% of attendees said they are frequently or occasionally using AI for code generation. But when asked if they felt they were doing it securely, confidence plummeted: over 56% either said “Probably not” or “Don’t know,” and 37.5% answered with an optimistic “Yes, I hope so.”

Configuring a Control Isn’t Securing It: SAP Build Code and Joule

The gap between the promise of secure cloud platforms and the reality of SAP environments often surfaces when teams use rapid development tools. SAP BTP offers incredible accelerators like SAP Build Code for professional development and SAP Joule for AI-driven assistance.

However, because these tools are so user-friendly, developers often confuse configuration with security.

• SAP Build Code: Generating or writing custom backend services has become incredibly fast. However, if the code pulling data from your SAP system lacks proper Authority Checks or authorization annotations, you are instantly exposing backend ERP data to unauthorized users. Connecting the service isn’t the same as securing it. 
• SAP Joule: As developers use Joule Studio to create custom skills, actions, and API integrations into enterprise systems, they must actively manage SAP Joule Studio security configurations. If a developer configures a Joule skill to fetch employee details or financial records via a REST API, the AI will execute that query blindly. The AI does not inherently understand your internal data privacy protocols, Identity Authentication Services (IAS) trust configurations, or SAP authorization logic.

Configuring an AI prompt, a system destination, or a workflow is just plumbing. Securing that connection requires intentional, SAP-aware validation.

The Liability Trap: Understanding the SAP BTP Shared Responsibility Model

The assumption that the cloud provider does it all creates a dangerous liability trap for development teams. The SAP BTP Shared Responsibility Model establishes clear, binary boundaries for security and compliance in the cloud. Simply put: SAP secures the platform, but the customer secures the code and data.

• Responsibility FOR the Cloud (SAP): SAP handles physical data center security, hardware, network isolation, OS patching, and standard SAP software infrastructure.
• Responsibility IN the Cloud (Customer): The customer is strictly responsible for data governance, encryption, role design, and identity management. Crucially, this responsibility also includes all custom code (ABAP, UI5, Node.js), low-code SAP Build apps, and BTP extensions. 

While the traditional model is a binary split between SAP and the customer, modern development introduces a complex third layer: generative AI. So, in a cloud environment, if an AI copilot authors a vulnerability in your custom BTP extension, or if a poorly configured Joule skill leaks sensitive data, who owns the liability?

The customer does. Even though an AI vendor or low-code tool generated the flaw, that custom application sits entirely within your domain. Because you own the liability, relying on manual, best-effort human review gates is no longer sufficient when dealing with the sheer volume and speed of modern BTP development.

Putting Up Guardrails for BTP and AI

Developers are now reviewing more code at a faster pace and frequently prioritizing functionality over security. As a result, organizations must establish strict internal guardrails.  To regain control and safely harness AI, teams should integrate a comprehensive governance framework tailored for cloud development:

• Accountable: Enforce strict policies for intellectual property protection, ensuring custom BTP apps and AI models comply with internal audits and regulatory frameworks.
  
• Robust and Reliable: Defend against AI hallucinations by validating that auto-generated code actually points to existing, authorized SAP modules, rather than inventing “ghost” dependencies.
  
• Private: Safeguard sensitive PII by ensuring all data passing through SAP Build Code or Joule skills strictly adheres to your established SAP authorization concepts and role-based access controls.
  
• Safe and Secure: Protect against new attack vectors like prompt injection. Make automated security testing a mandatory step in the deployment pipeline, rather than a periodic afterthought.

Keeping the Core Clean with a “Shift-Left” AST Approach

A massive strategic objective for SAP customers today is achieving a “Clean Core” by moving custom logic off the main ERP and building extensions on SAP BTP. However, a Clean Core strategy without embedded security leaves a critical gap; you may clean your ERP, but you merely push the vulnerabilities to a new, less-monitored surface on BTP. 

To achieve genuine SAP BTP AI application security, you must adopt a “Shift-Left” strategy, moving security validation to the very beginning of the development cycle. Generic web scanners won’t cut it. Organizations need rigorous, SAP-Native Application Security Testing (AST), like Onapsis Control, which secures your custom code throughout the early stages of development, scanning code at rest, in development, and in motion. It  provides:

• Developer-Embedded Integration: Security feedback surfaces directly in the IDE (like VS Code, SAP Business Application Studio, or ADT), acting as an interactive spell-checker for your developers before vulnerable code is ever committed.
  
• Deep SAP Understanding: Comprehensive coverage that spans on-premise S/4HANA, RISE environments, BTP services, and complex authorization objects.
  
• Transport Blocking: Automated gates that prevent broken or vulnerable code from ever reaching production environments.

Ready to secure your cloud and AI coding practices? Get in touch!

Frequently Asked Questions (FAQ)

Who is responsible for custom application security in SAP BTP?

Under the SAP BTP shared responsibility model, the customer is 100% responsible for the security of any custom applications, extensions, and code deployed on SAP BTP. While SAP secures the underlying cloud platform, infrastructure, and standard software, securing your custom code, data, roles, and authorization checks remains entirely within your domain.

Does using SAP’s native tools like SAP Build automatically make my applications secure?

No. While SAP Build provides a secure foundational framework, the logic you design, the APIs you expose, and the data you connect to must be actively secured by your team. Configuring a low-code tool is not the same as securing its architecture and access points.

How do we manage risks when integrating AI copilots like SAP Joule?

Managing SAP Joule Studio security configurations is a strict customer responsibility. You must ensure that any custom skills, REST APIs, or data access granted to the AI adhere to your organization’s internal authorization concepts and data privacy guardrails to prevent unauthorized data exposure.

Why is a “Clean Core” strategy fundamentally incomplete if an organization does not also embed a Shift-Left security posture?

If you clean the core ERP but push insecure custom code and AI-generated extensions to SAP BTP without early security checks, you merely shift the vulnerabilities to a new, potentially less-monitored location. Achieving true SAP BTP AI application security requires shifting left by embedding automated checks early in the development lifecycle to ensure your BTP extensions are as secure as your core. 

When implementing automated security testing for BTP apps, why is “SAP-Native Coverage” so essential?

Generic web vulnerability scanners create dangerous blind spots because they lack a deep understanding of SAP’s unique architecture. A robust SAP-native AST solution directly analyzes ABAP, BTP services, SAP Build workflows, and custom namespace logic to effectively identify and mitigate SAP-specific vulnerabilities.