It feels as though vibe coding has sparked a wild-west adoption phase for generative AI in enterprise development. The temptation is obvious: massive productivity leaps achieved just by feeding natural language prompts into LLMs to deploy software at record speeds.
Organizations are sprinting to integrate these practices, terrified that lagging behind means losing their competitive edge. Yet, in this rapid acceleration, what truly gets left behind are comprehensive guardrails and the baseline security of your custom code.
In the end, this unchecked speed will only leave your highly protected “Clean Core” dirty and exposed. To keep your SAP® core truly clean while safely leveraging the speed of AI, you need robust, purpose-built SAP Application Security Testing (AST).
Key Takeaways:
- The Velocity vs. Vulnerability Trap: AI coding tools increase speed but multiply risk. Up to 62% of AI-generated code contains security vulnerabilities, and AI introduces up to 2.74 times more security issues than human-created code.
- Context Gaps: AI lacks true SAP business process and regulatory awareness. This leads to missing Authority Checks, the replication of legacy flaws, and AI hallucinations that invent non-existent modules.
- Liability Under the SAP Shared Responsibility Model: SAP secures the infrastructure, but the customer remains strictly responsible for custom code and data. Vulnerabilities introduced by an AI tool remain the liability of the customer organization.
- Shift Left for Clean Core: Pushing unverified, AI-generated custom code to SAP BTP introduces new vulnerabilities. Securing this landscape requires automated, SAP-native Application Security Testing (AST) to block threats directly in the development environment.
Data Shows AI-Generated Code Increases Security Vulnerabilities
Recent studies indicate AI-generated code introduces significant vulnerabilities into enterprise systems. According to Veracode, between 41% and 62% of AI-generated code contains security vulnerabilities. CodeRabbit reported that AI code creates 1.7 times more overall issues on average, and up to 2.74 times more security issues.
During a recent webinar with Deloitte on the hidden risks of AI-generated SAP custom code, audience polling revealed that 61.6% of respondents frequently or occasionally use AI for code generation, with another 30.8% starting to experiment. However, over 56% expressed low or no confidence that this code was generated securely, while another 37.5% answered with a hesitant “Yes, I hope so.” This trend mirrors The Legit 2025 State of Application Risk Report, which notes that 71% of organizations use AI models in source code, with 46% executing this in a risky manner. The threat window is unforgiving: Onapsis research shows new, unprotected Enterprise Resource Planning (ERP) applications provisioned in the cloud are discovered and compromised by attackers in less than 3 hours.
AI-Generated Code Lacks SAP Business Context and Introduces Severe Risks
Large Language Models (LLMs) are trained on the public internet, not on proprietary SAP landscapes, custom namespace logic, or RISE-specific configurations. Because AI lacks true business context, relying on it blindly introduces severe risks:
- Missing Authority Checks: AI models may output correct ABAP syntax but fail to implement underlying business authorization protocols.
- Replicating Legacy Flaws: Models trained on outdated code readily suggest violations of Clean Core principles, such as direct database access.
- AI Hallucinations: AI generates ghost dependencies and non-existent parameters, which threaten production stability with unexpected runtime errors.
- Regulatory Blind Spots: AI operates without awareness of internal audit controls, creating security debt that sidesteps SOX or GDPR requirements.
Huge volumes of code are generated rapidly, making manual validation impossible and highly insecure.
Customers Own the Liability for Custom Code Under the SAP Shared Responsibility Model
Webinar polling revealed misconceptions regarding the SAP shared responsibility model. Only 26.7% of attendees understood the core concepts, while a majority required a refresher, and 13.3% mistakenly assumed SAP handles all security.
The SAP Shared Responsibility Model establishes binary boundaries for security and compliance in the cloud. 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.
- Responsibility IN the Cloud (Customer): The customer is strictly responsible for data governance, encryption, role design, and all custom code (ABAP, UI5) and BTP extensions.
In a RISE with SAP environment, AI introduces a complex third layer. If an AI tool authors a vulnerability in custom code, the customer owns the liability. AI-generated code falls 100% under customer responsibility. Relying on manual human review gates is insufficient; continuous, automated security testing is a mandatory requirement.
A Shift-Left AST Approach is Required to Secure the Clean Core
Achieving a “Clean Core” requires moving custom code and AI-generated extensions to SAP BTP. However, a Clean Core strategy without embedded security merely pushes vulnerabilities to a new, less-monitored surface on SAP BTP.
To securely leverage AI, organizations must adopt a “Shift-Left” strategy, moving security validation to the very beginning of the development cycle. According to our audience poll, there is work to do: only 7.7% rate their Shift-Left maturity as “Highly mature,” while 38.5% are “Making progress” and another 38.5% are “Just starting.”
Generic web scanners are insufficient. Organizations need rigorous, SAP-native application security testing, like Onapsis Control, which provides:
- Developer-Embedded Integration: Security feedback surfaces directly in the IDE (VS Code or ADT), acting as an interactive spell-checker for developers.
- Deep SAP Understanding: Comprehensive coverage spanning on-premise S/4HANA, RISE environments, ABAP, BTP services, and authorization objects.
- Transport Blocking: Automated gates prevent broken or vulnerable code from reaching production.
👉 Watch the Webinar On-Demand Here
Frequently Asked Questions (FAQ)
If AI coding tools understand ABAP syntax perfectly, why do they still create significant security vulnerabilities in SAP?
While AI models excel at understanding programming syntax, they lack an understanding of specific business processes. AI copilots are probabilistic models, meaning the results are frequently inconsistent, prone to hallucinations, and flawed. Ignoring security on AI-generated code leads to the omission of critical security controls, such as missing Authority Checks, exposing sensitive data to unauthorized users.
With manual code reviews becoming nearly impossible due to the speed of AI, how can development teams realistically manage this flooding of vulnerabilities?
The bottleneck has shifted from writing code to validating it. Teams must adopt a “Shift-Left” approach utilizing automated, SAP-native security testing tools like Onapsis Control that embed interactive scanning directly into the developer’s IDE, stopping vulnerabilities before they progress.
Under SAP’s Shared Responsibility Model in a RISE environment, if an AI tool authors a vulnerability in custom code, who ultimately owns the liability?
The customer owns the liability. Custom code, regardless of the author, sits entirely in the customer’s domain under the SAP Shared Responsibility Model.
Why is a “Clean Core” strategy considered only a “half-measure” if an organization does not also embed a Shift-Left security posture?
Cleaning the ERP while pushing insecure custom code and AI-generated extensions to SAP BTP without early security checks merely creates a new, less-monitored attack surface. Shifting left is essential for making BTP extensions and the Clean Core strategy truly secure.
When implementing automated security testing to validate AI-generated code, why is “SAP-Native Coverage” so essential?
Generic web vulnerability tools create dangerous blind spots. A robust solution must deeply understand specific SAP architecture, including ABAP, BTP services, authorization objects, and custom namespace logic, to effectively identify and mitigate SAP-specific risks.
About the Author
