It compiles, so it works. ABAP in the age of the coding assistant

For thirty years, ABAP defended itself. Not through its syntax, which forgives almost everything. It defended itself through the barrier to entry.

To write anything meaningful inside an SAP system, you first had to understand the data dictionary, the authorization concept, authorization objects, the logic of the module you were touching, and the entire ritual of moving transports across three systems. None of that knowledge lived in documentation. It lived in the heads of people who had survived a few implementations and a few failed go-lives. It was passed on at a desk, not in a course.

That barrier is now gone. Not gradually, over a decade. In a matter of months.

What changed under the hood

SAP released a foundation model trained exclusively on ABAP. SAP-ABAP-1 learned from 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, built into the ABAP development tools in Eclipse and into SAP Business Application Studio. In 2026 an ABAP extension for Visual Studio Code joined the set, bringing SAP development into the editor where most of the non-SAP world already works.

Notice the direction of that change. This is not only a story about ABAP developers getting a faster tool. To write something in SAP that compiles and passes the functional test, you no longer have to be an ABAP developer.

That report will now be written by a functional consultant who has configured MM for fifteen years and never written a line of code. An analyst from the data team will write one. So will a junior three weeks into the project. So will the business owner who understands the process better than anyone in IT. I have no objection to any of that. I think it is good news, because the best extensions were always built close to the process, not close to the compiler.

The problem sits elsewhere. The barrier to entry disappeared faster than the gates that inspect what comes through it.

Compilation was never a security test

Code that comes out of an assistant has one property that disarms scrutiny better than any other: it works. It compiles on the first attempt, it passes the functional test, it does exactly what you asked. The business sign-off goes beautifully.

Except that the SAP compiler never checked the things that are actually dangerous in this platform.

It never checked whether an AUTHORITY-CHECK stands in front of that payroll read. It never checked whether a query assembled dynamically from user input can be taken apart by injection. It never checked whether the RFC module you just exposed verifies the caller’s authorizations. It never checked whether writes go through application logic or straight into the table, bypassing everything somebody once designed. And it certainly never checked whether the field you render is encoded before it reaches the browser.

The model did not skip those things out of malice. It simply does not know them. It has never seen your authorization concept. It has no idea what your segregation-of-duties matrix looks like. It does not know that in this particular company exactly eight people can read the payroll table, and that this was a board decision rather than an accident. It sees a pattern drawn from millions of lines of somebody else’s code, and it reproduces that pattern with complete confidence.

Along with the pattern, it reproduces the flaws. The model learned from historical code, including practices from an era when nobody thought about injection. It also invents objects that do not exist and parameters that never did. And the resulting code looks exactly like good code. That is the part that worries me most: the difference is invisible from the outside.

Numbers worth keeping in mind

In December 2025 CodeRabbit reviewed 470 pull requests from open-source projects: 320 co-authored with AI and 150 written by humans alone. The former carried up to 2.74 times more security findings and 1.7 times more issues overall, meaning logic, performance and maintainability. It is a vendor study on open-source code, so treat it as an indication rather than a verdict.

Others point the same way. Veracode tested more than a hundred models across eighty coding tasks: 45 percent produced code with a vulnerability, and in Java 72 percent did. Apiiro measured something more telling inside enterprise repositories: developers using assistants ship code three to four times faster, while security findings in those repositories grew tenfold in six months.

That is the heart of it. The assistant does not write worse than a person. It writes far more, while the number of people reading that code has not gone up by one.

Onapsis, surveying more than two hundred security leaders in June, found that 86 percent of organisations have integrated or are about to integrate AI directly into ERP code, while 69 percent admit their current defences cannot reliably detect an AI-driven attack.

One more number turns this from an academic topic into an operational one. In its research on attacks against SAP systems, Onapsis measured how long an unsecured SAP application exposed in the cloud survives before it is discovered and attacked. Under three hours.

Clean Core raised the stakes

Here is the part of the puzzle that usually gets missed.

For years, custom code lived inside your own four walls. Written carelessly, perhaps, but behind a firewall, in a system reachable by a few dozen people. A vulnerability in such a report was real, but hard to get to.

Clean Core changed the geography. Extensions move out of the core onto BTP and become cloud applications. That is the right architectural direction and I recommend it to clients myself. Its side effect, though, is that the same code, written with the same care, now hangs on the internet. The same conclusion ran through a joint Deloitte and Onapsis webinar on the risks of AI-written SAP code: Clean Core without moving security controls to the start of the process is a half measure.

Now read that next to the three hours from the paragraph above.

Who signs

Which brings us to the only question in this story that genuinely interests me.

SAP has something most of IT does not: a physical, named moment of accountability. Someone releases the transport. Someone else imports it into production. Both names stay in the log and cannot be taken out of it. That mechanism was designed in an era when releasing a transport meant: I have read this, I understand it, I take it on.

Today it increasingly means: I approved a suggestion I did not read, because there was too much of it and it looked reasonable.

The signature has not changed. What changed is what stands behind it.

Meanwhile the ABAP developer’s role is shifting from writing to validating, and that shift is healthy. The trouble is that when teams handed the writing over to the machine, nobody added capacity for the reading. The bottleneck did not dissolve; it moved one step to the right, into a place where nobody happens to be looking. And under time pressure, the first thing dropped is always whatever does not hurt immediately. Security loses that contest every time, because its absence starts to hurt some months later.

Punishing anyone for this changes nothing. What changes things is the person signing actually knowing what they sign.

This can be brought under control

I write about it calmly because I know the other side of the story. A code scan wired into the transport stops a package carrying a missing authorization check or an injection before it reaches the next system. The developer sees the flaw in the editor, in the same minute it appeared, rather than three days before go-live.

At SNOK we build this on SecurityBridge. I have followed that product for practically as long as the company has existed, and it is one of the few cases where a security tool for SAP grows alongside the platform instead of trailing a year behind it. Good software, made by people who understand SAP from the inside. How to arrange it layer by layer, we describe separately.

Three things for Monday

I have no manifesto for you, but I do have three things to do straight away.

Find out who actually writes code in your SAP systems. Not in the org chart, in the system. The list of authors of custom objects over the past six months can be surprising, and it is the cheapest diagnostic I know.

Put the security scan into the transport, not into the calendar. A control that happens “once a quarter” in practice never happens. A control without which the package does not move to the next system happens every single time.

Decide what your signature on a transport means. One sentence in the policy, so that everyone releasing a transport knows whether they are confirming that they read the code or merely that the function was accepted. Today, in most organisations, nobody knows, including the person signing.

Because the assistant will not stand in front of an auditor. It will not take a call on a Sunday when it turns out that the report meant to show stock levels was also reading the entire payroll table without a single authorization check.

You will.

Download the column as a PDF

---

How to secure this in layers, where to place the gates and what it looks like in practice with SecurityBridge, we cover in a separate article: The code nobody wrote. Securing ABAP in the age of AI assistants.

Sources: CodeRabbit, State of AI vs Human Code Generation Report, 17 December 2025 (470 pull requests; vendor study) · Veracode, GenAI Code Security Report, 2025 · Apiiro, September 2025 · Onapsis, State of AI, Security and ERP, June 2026 survey of 204 security leaders · Onapsis Threat Research on attacks against SAP applications · 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.

Also worth reading: ABAP code as a non-obvious security threat · Three acts of SAP AI and the question that was not on the slides · SAP testing and the release trust problem