In most SAP systems we audit, custom code accumulated over years and shared one property: you could point to its author. There was a person who wrote it and a person who reviewed it before the package moved on.
That certainty has just expired. AI assistants have settled into SAP development tooling, and with them systems started receiving code that, in the classical sense, nobody wrote. Someone requested it, someone approved it, someone released the transport. A machine wrote it.
This article is about what to do with that code. Without arguing that you should stop using AI, which would be both unrealistic and harmful. Instead, with a concrete control architecture: where the gates belong, which of them must block rather than warn, and who signs off on the result.
What exactly changed
The change has three layers. Each would be manageable on its own; the difficulty comes from their overlap.
The tooling layer. SAP released SAP-ABAP-1, a foundation model trained on millions of lines of ABAP: standard objects, customer extensions, BAdI implementations and ABAP Cloud patterns. SAP Community materials put the figure above 250 million lines. It powers code explanation and generation in Joule for Developers, present in the ABAP development tools in Eclipse and in SAP Business Application Studio. In 2026 an ABAP extension for Visual Studio Code was added. On top of that sit general-purpose assistants that developers use whether or not anyone approved them.
The human layer. Once writing a report no longer requires knowing the syntax or the data structures, the authors of custom code start coming from outside the development team: functional consultants, analysts, juniors, business users. Their process knowledge is often deeper than the ABAP team’s. Their security knowledge is nil, and that is a description of the situation, not an accusation.
The architecture layer. Clean Core pushes extensions out of the core and onto SAP BTP. The direction is right, but the side effect is hard: code that used to sit behind a firewall becomes an application exposed in the cloud. The conclusion that ran through a joint Deloitte and Onapsis webinar on AI-written SAP code is unambiguous here: Clean Core without moving security controls to the start of the process is a half measure.
The scale is already measured. In an Onapsis survey from June 2026 covering 204 security leaders at organisations with more than a thousand employees, 86 percent have integrated or are integrating AI directly into ERP code, while 69 percent admit their current defences cannot reliably detect an AI-driven attack.
Seven mechanisms by which an assistant damages ABAP
This is not a list of hypotheses. The first six come straight from the Deloitte and Onapsis analysis; the seventh we add from our own audits.
1. Missing authorization checks. The model produces correct business logic and omits AUTHORITY-CHECK, because it has no access to your authorization concept. It does not know which authorization objects apply in that module, or that access to a particular table was a deliberate decision. The result: a report that works and shows data to anyone able to run it.
2. Injection in queries. A query assembled dynamically from user input is a pattern that appears hundreds of thousands of times in public code. The model reproduces it together with the missing input validation. This covers Open SQL, ADBC and native calls.
3. Vulnerabilities in the interface layer. Asking an assistant to add a header to a render function yields code that looks and behaves correctly but skips encoding and sanitisation. That is how XSS enters UI5 and Fiori applications. In the demonstration shown during the webinar, exactly this scenario was caught only by a scanner embedded in the editor.
4. Replicating legacy flaws. The model learned from historical code, including practices from an era when nobody worried about injection or direct table manipulation. A pattern that was normal fifteen years ago returns today as freshly generated code.
5. Hallucinations and ghost dependencies. References to objects, parameters and structures that do not exist in your system. Some surface at activation. Some pass through and only appear on a path nobody tested.
6. Uncontrolled data operations. An agent running without hard constraints can generate a mass operation against database tables. Without an enforced human approval before such an operation executes, nothing stops it.
7. Drift away from segregation of duties. This one is ours. Code generated “on the side” by someone outside the development team routinely bypasses the agreed process: it is created in the development system under someone else’s account, joins a bundled transport and passes through an approval step that was never designed for this scenario. The SoD matrix stays formally correct while practice silently drifts away from it.
The common denominator: none of these defects stops compilation, and none of them fails a functional test.
Why the existing gates miss all of this
Most organisations we work with have some form of code control. The problem is that all three classical gates were designed for a different traffic profile.
Human code review assumes there is only as much code as a person can read. In September 2025 Apiiro measured that developers using assistants ship code three to four times faster, while security findings in their repositories grew tenfold within six months. Quality moves the same way: in CodeRabbit’s December 2025 study of 470 pull requests, those co-authored with AI carried up to 2.74 times more security findings and 1.7 times more issues overall. Rising volume multiplied by a rising defect rate, against an unchanged number of reviewers, produces a result that needs no study to predict.
ATC and Code Inspector do work, but in their default variants they mainly check quality and adherence to standards rather than security. Full vulnerability analysis is a separately licensed capability, inactive in many systems. It also tends to run on demand rather than as a condition for moving forward.
Functional tests and UAT verify that a program does what it was supposed to do. They do not verify what else it does along the way. A missing authorization check is invisible to a tester who holds full authorizations.
Add time pressure. The developer’s role shifts from writing to validating, while the headcount for validating stays the same. The bottleneck does not disappear; it moves to a place where nobody measures it.
Three layers of defence
Our approach rests on one principle: a control that costs nothing to bypass is not a control. So the gates have to stand where code must pass anyway. In SAP there are exactly three such places.
Layer one: the developer’s editor
A vulnerability caught in the editor costs a minute. The same vulnerability caught in UAT costs a delayed release. Caught in production, it costs an incident.
SecurityBridge Code Vulnerability Analysis gives the developer scan results where they work: in the ABAP Development Workbench and in the ABAP tools for Eclipse, with native integration into SAP Code Inspector and the ABAP Test Cockpit. The detected classes map precisely onto what assistants produce: SQL, Open SQL and ADBC injection, missing authorization checks in RFC modules, direct table manipulation, directory traversal and backdoors.
Two capabilities matter especially for machine-generated code. Explain ABAP Code describes what a fragment actually does, which is essential for a person who did not write it but has to approve it. Describe Vulnerabilities explains the finding together with a remediation path, instead of leaving the developer with a rule number to search for.
Think of it as spell check: you keep writing, with an underline where something is wrong.
Layer two: the transport
This is where it is decided, because the transport is the one place in SAP that cannot be bypassed.
SecurityBridge Transport Center adds what the standard transport system lacks. A scan of the package contents becomes a precondition for import, so a transport carrying a vulnerability nobody has fixed does not move to the next system. An approval workflow enforces segregation of duties and documents four-eyes sign-off in a form you can show an auditor. Alongside that come downgrade and version-conflict protection, prediction of missing dependencies and import list building for complex production cut-overs. We confirm the exact feature set with the vendor before every deployment, because the portfolio moves faster than the datasheets.
The same mechanism covers a case rarely considered in an AI context: third-party code. A package from an integrator or an add-on vendor passes through the identical gate as your own.
Layer three: runtime
A static scan will not detect abuse of code that already passed inspection. Layer three is therefore continuous detection: SecurityBridge Threat Detection monitors system behaviour in real time and forwards events to your SIEM, whether that is Microsoft Sentinel, Splunk, QRadar or something else. Interface Traffic Monitor watches the interface layer, which is how custom code usually talks to the outside world.
An attempted exploitation can then trigger analysis of the code responsible for it. The loop closes: what happens in production feeds back into layer one.
Who signs
The technical layers solve detection. They do not solve accountability, and accountability is what comes back at every board meeting.
The starting point is the shared responsibility model, which not everyone has absorbed: the cloud provider is responsible for the platform, and you are responsible for your own code and extensions. In the poll cited during the webinar, 13 percent of participants believed that moving to the cloud transfers security responsibility to SAP. It does not. Nor does it transfer to the provider of the AI model.
Four things we put in place on the governance side.
A policy for assistant use in development. Which tools are permitted, against which systems, and what data may be pasted into a prompt. Without that document, every downstream control is discretionary.
Marking AI-assisted code. A simple attribute on the object or a convention in the transport description. Not to stigmatise anyone, but to give code review and later incident analysis something to work with.
An unambiguous meaning for the transport signature. Releasing a transport must mean either “I have read and understood the code” or “I confirm functional acceptance”, and everyone must know which. Today, in most organisations, nobody knows, including the person signing.
Hard gates for irreversible operations. Mass data operations, changes to critical objects, deployment outside the maintenance window: these are cases where human approval must be technically enforced, not procedurally expected.
The regulatory layer only confirms this. NIS2 requires, in Article 21(2)(e), measures covering security in the acquisition, development and maintenance of systems, including vulnerability handling. The provision says nothing about artificial intelligence, but custom code is created inside exactly that process, so the secure development obligation covers it regardless of who held the keyboard. A documented scanning and approval process is the simplest evidence that such a measure exists. For financial entities, DORA imposes comparable requirements around change management and testing.
How we work at SNOK
We are SecurityBridge’s partner in Poland and we run this topic from the SAP Basis and security side, not merely from the licensing side.
Assessment. We start with a scan of the existing custom code base and an inventory of who authored objects over recent months. The second part tends to be the most instructive for clients, because it shows how much code originates outside the development team. The output is a vulnerability list ordered by business risk, not by hit count.
Deploying the control layer. Enabling code analysis inside the development tools, wiring the scan into the transport process as a condition for import, configuring blocking thresholds and integrating events with the SIEM. Thresholds have to be calibrated on your own data. A gate that blocks everything gets switched off in week three.
Governance and skills. An AI usage policy for development, a transport approval model, and a workshop for the development team and functional consultants on what specifically to look for in code you did not write.
Ongoing operations. Periodic review of findings, handling of new vulnerabilities, audit support and, for organisations without their own SAP security team, an on-call expert model instead of a headcount.
A 30, 60 and 90 day plan
By day 30. Inventory the authors of custom objects over the last six months. Scan the existing code base and produce a report ordered by risk. Decide, in one sentence, what a transport signature means.
By day 60. Code analysis available inside the development tools. Scanning as a condition for import into the test system, in warning mode for now. An assistant usage policy adopted and communicated.
By day 90. A blocking gate for the production system, with thresholds calibrated on real data from the previous stage. Runtime events flowing into the SIEM. Documented four-eyes approval ready to show an auditor.
In closing
AI-generated code is not the problem in itself. The problem is that it arrives faster than the organisation can read it, and that it is visually indistinguishable from code somebody thought through.
The answer is not a ban, because a ban here simply moves the same phenomenon out of sight. The answer is to relocate control to places that cannot be bypassed: the editor, the transport and the runtime. Only then does a signature on a transport start to mean something again.
If you want to see what this looks like in your system, get in touch. We usually begin with a scan of the existing code base, because it is the only security conversation that puts numbers rather than opinions on the table within a week.
For the wider context of how the profession is changing: It compiles, so it works. ABAP in the age of the coding assistant, a column by Jacek Bugajski.
Sources: Onapsis, State of AI, Security and ERP, June 2026 survey of 204 security leaders · CodeRabbit, State of AI vs Human Code Generation Report, 17 December 2025 (470 pull requests; vendor study) · Apiiro, September 2025 · Veracode, GenAI Code Security Report, 2025 · SecurityBridge product documentation (Code Vulnerability Analysis, Transport Center, Threat Detection, Interface Traffic Monitor) · Deloitte and Onapsis webinar “The Hidden Risks of AI-Generated SAP Custom Code” · SAP and SAP Community materials on the SAP-ABAP-1 model and Joule for Developers · NIS2 Directive, Article 21.
Related posts: ABAP code as a non-obvious security threat · KSC, NIS2 and SecurityBridge · The AI agent on both sides of the attack