Unkontrolliertes „Vibe Coding“ birgt Risiken für SAP-Clean-Core-Strategien 

Es scheint, als hätte das „Vibe-Coding“ eine Phase der ungezügelten Einführung generativer KI in der Unternehmensentwicklung ausgelöst. Die Verlockung liegt auf der Hand: enorme Produktivitätssprünge, die allein dadurch erzielt werden, dass man LLMs mit Prompts in natürlicher Sprache füttert, um Software in Rekordgeschwindigkeit bereitzustellen. 

Unternehmen bemühen sich mit Hochdruck darum, diese Praktiken zu integrieren, da sie befürchten, durch einen Rückstand ihren Wettbewerbsvorteil zu verlieren. Doch bei dieser rasanten Entwicklung bleiben vor allem umfassende Sicherheitsvorkehrungen und die „ baseline “-Sicherheit Ihres maßgeschneiderten Codes auf der Strecke. 

Letztendlich wird diese unkontrollierte Geschwindigkeit dazu führen, dass Ihr streng geschützter „Clean Core“ verschmutzt und ungeschützt bleibt. Um Ihren SAP®-Kern wirklich sauber zu halten und gleichzeitig die Geschwindigkeit der KI sicher zu nutzen, benötigen Sie robuste, speziell entwickelte SAP-Anwendungssicherheitstests (AST). 

Das Wichtigste in Kürze:

• Die Falle „Geschwindigkeit vs. Sicherheitslücken“: KI-Programmierwerkzeuge erhöhen zwar die Geschwindigkeit, vervielfachen aber gleichzeitig das Risiko. Bis zu 62 % des von KI generierten Codes enthält Sicherheitslücken, und KI verursacht bis zu 2,74-mal mehr Sicherheitsprobleme als von Menschen geschriebener Code.
• Kontextlücken: Der KI fehlt ein echtes Verständnis der SAP-Geschäftsprozesse und der regulatorischen Rahmenbedingungen. Dies führt zu fehlenden Berechtigungsprüfungen, der Wiederholung alter Fehler und Halluzinationen der KI, die nicht existierende Module erfinden.
• Haftung im Rahmen des SAP-Modells der geteilten Verantwortung: SAP sorgt für die Sicherheit der Infrastruktur, doch die Verantwortung für kundenspezifischen Code und Daten liegt weiterhin ausschließlich beim Kunden. Für durch ein KI-Tool verursachte Sicherheitslücken haftet weiterhin die Kundenorganisation.
• „Shift Left“ für einen sauberen Core: Das Übertragen von ungeprüftem, KI-generiertem benutzerdefiniertem Code in „ SAP BTP “ führt zu neuen Schwachstellen. Um diese Umgebung abzusichern, sind automatisierte, SAP-native Anwendungssicherheitstests (AST) erforderlich, um Bedrohungen direkt in der Entwicklungsumgebung abzuwehren.

Daten zeigen, dass durch KI generierter Code die Sicherheitslücken erhöht

Jüngste Studien deuten darauf hin, dass durch KI generierter Code erhebliche Sicherheitslücken in Unternehmenssystemen verursacht. Laut Veracode weisen zwischen 41 % und 62 % des durch KI generierten Codes Sicherheitslücken auf. CodeRabbit berichtete, dass KI-Code im Durchschnitt 1,7-mal mehr Probleme insgesamt und bis zu 2,74-mal mehr Sicherheitsprobleme verursacht.

Bei einem kürzlich abgehaltenen Webinar mit Deloitte zu den versteckten Risiken von KI-generiertem SAP-Sonderprogrammcode ergab eine Umfrage unter den Teilnehmern, dass 61,6 % der Befragten häufig oder gelegentlich KI zur Codegenerierung einsetzen, während weitere 30,8 % gerade erst damit experimentieren. Allerdings äußerten über 56 % wenig oder gar kein Vertrauen darin, dass dieser Code sicher generiert wurde, während weitere 37,5 % mit einem zögerlichen „Ja, ich hoffe es“ antworteten. Dieser Trend spiegelt sich im „Legit 2025 State of Application Risk Report“ wider, der feststellt, dass 71 % der Unternehmen KI-Modelle im Quellcode einsetzen, wobei 46 % dies auf risikobehaftete Weise tun. Das Zeitfenster für Angriffe ist gnadenlos: Untersuchungen von Onapsis zeigen, dass neue, ungeschützte ERP-Anwendungen (Enterprise Resource Planning), die in der „ cloud “ bereitgestellt werden, von Angreifern in weniger als drei Stunden entdeckt und kompromittiert werden.

Von KI generierter Code lässt den SAP-Geschäftskontext außer Acht und birgt erhebliche Risiken

Große Sprachmodelle (LLMs) werden im öffentlichen Internet trainiert, nicht in proprietären SAP-Landschaften, mit benutzerdefinierter Namespace-Logik oder RISE-spezifischen Konfigurationen. Da der KI der echte geschäftliche Kontext fehlt, birgt ein blindes Vertrauen in sie erhebliche Risiken:

• Fehlende Berechtigungsprüfungen: KI-Modelle geben zwar möglicherweise eine korrekte ABAP-Syntax aus, setzen jedoch die zugrunde liegenden geschäftlichen Berechtigungsprotokolle nicht um.
• Nachbildung von Mängeln aus der Vergangenheit: Modelle, die auf veraltetem Code trainiert wurden, weisen häufig auf Verstöße gegen die „Clean Core“-Prinzipien hin, wie beispielsweise den direkten Zugriff auf die Datenbank.
• KI-Halluzinationen: Die KI erzeugt Scheinabhängigkeiten und nicht vorhandene Parameter, die die Produktionsstabilität durch unerwartete Laufzeitfehler gefährden.
• Regulatorische blinde Flecken: KI-Systeme arbeiten ohne Berücksichtigung interner Kontrollmechanismen, wodurch eine Sicherheitslücke entsteht, die die Anforderungen von SOX oder der DSGVO umgeht.

Es entstehen in kürzester Zeit riesige Mengen an Code, was eine manuelle Überprüfung unmöglich und äußerst unsicher macht.

Im Rahmen des SAP-Modells der geteilten Verantwortung tragen die Kunden die Haftung für benutzerdefinierten Code

Eine im Rahmen des Webinars durchgeführte Umfrage deckte Missverständnisse hinsichtlich des SAP-Modells der geteilten Verantwortung auf. Nur 26,7 % der Teilnehmer verstanden die Kernkonzepte, während die Mehrheit eine Auffrischung benötigte und 13,3 % fälschlicherweise davon ausgingen, dass SAP die gesamte Sicherheit übernimmt.

Das SAP-Modell der geteilten Verantwortung legt klare Grenzen für Sicherheit und Compliance im „ cloud “ fest. SAP sorgt für die Sicherheit der „ platform “, während der Kunde für die Sicherheit des Codes und der Daten verantwortlich ist.

• Verantwortung FÜR die „ Cloud “ (SAP): SAP ist zuständig für die physische Sicherheit des Rechenzentrums, die Hardware, die Netzwerkisolierung, die Installation von Betriebssystem-Patches sowie die Standard-SAP-Software.
• Verantwortung seitens des „ Cloud “ (Kunde): Der Kunde trägt die alleinige Verantwortung für die Datenverwaltung, die Verschlüsselung, die Rollengestaltung sowie für den gesamten benutzerdefinierten Code (ABAP, UI5) und die BTP-Erweiterungen.

In einer RISE with SAP-Umgebung führt KI eine komplexe dritte Ebene ein. Wenn ein KI-Tool eine Sicherheitslücke im benutzerdefinierten Code verursacht, liegt die Haftung beim Kunden. Für KI-generierten Code trägt der Kunde die volle Verantwortung. Es reicht nicht aus, sich auf manuelle Prüfungen durch Mitarbeiter zu verlassen; kontinuierliche, automatisierte Sicherheitstests sind zwingend erforderlich.

Ein „Shift-Left“-Ansatz für den AST ist erforderlich, um den „Clean Core“ zu sichern

Um einen „Clean Core“ zu erreichen, müssen benutzerdefinierter Code und KI-generierte Erweiterungen auf SAP BTP verlagert werden. Eine Clean-Core-Strategie ohne integrierte Sicherheitsmaßnahmen verlagert Schwachstellen jedoch lediglich auf eine neue, weniger überwachte Angriffsfläche auf SAP BTP.

Um KI sicher nutzen zu können, müssen Unternehmen eine „Shift-Left“-Strategie verfolgen und die Sicherheitsüberprüfung ganz an den Anfang des Entwicklungszyklus verlagern. Laut unserer Leserumfrage gibt es hier noch einiges zu tun: Nur 7,7 % stufen ihre „Shift-Left“-Reife als „sehr ausgereift“ ein, während 38,5 % „Fortschritte machen“ und weitere 38,5 % „gerade erst anfangen“. 

Allgemeine Web-Scanner reichen nicht aus. Unternehmen benötigen strenge, SAP-native Tests zur Anwendungssicherheit, wie beispielsweise Onapsis Control, das Folgendes bietet:

• In die Entwicklerumgebung integrierte Integration: Sicherheitshinweise werden direkt in der IDE (VS Code oder ADT) angezeigt und fungieren als interaktive Rechtschreibprüfung für Entwickler.
• Fundierte SAP-Kenntnisse: Umfassende Kenntnisse, die On-Premise-S/4HANA-, RISE-Umgebungen, ABAP, BTP-Services und Berechtigungsobjekte abdecken.
• Transportblockierung: Automatisierte Kontrollmechanismen verhindern, dass fehlerhafter oder anfälliger Code in die Produktionsumgebung gelangt.

👉 Sehen Sie sich das Webinar hier als Aufzeichnung an

Häufig gestellte Fragen (FAQ)

Wenn KI-Programmierwerkzeuge die ABAP-Syntax perfekt verstehen, warum verursachen sie dann immer noch erhebliche Sicherheitslücken in SAP?

Zwar sind KI-Modelle hervorragend darin, Programmiersyntax zu verstehen, doch fehlt ihnen das Verständnis für spezifische Geschäftsprozesse. KI-Copiloten sind probabilistische Modelle, was bedeutet, dass die Ergebnisse häufig inkonsistent, anfällig für „Halluzinationen“ und fehlerhaft sind. Wird die Sicherheit bei KI-generiertem Code vernachlässigt, führt dies zum Wegfall kritischer Sicherheitskontrollen, wie beispielsweise fehlender Berechtigungsprüfungen, wodurch sensible Daten unbefugten Nutzern zugänglich gemacht werden.

Da manuelle Code-Prüfungen aufgrund der Geschwindigkeit der KI fast unmöglich geworden sind, wie können Entwicklungsteams diese Flut von Sicherheitslücken realistisch bewältigen?

Der Engpass hat sich vom Schreiben von Code hin zur Validierung des Codes verlagert. Teams müssen einen „Shift-Left“-Ansatz verfolgen und dabei automatisierte, SAP-native Sicherheitstest-Tools wie Onapsis Control einsetzen, die interaktive Scans direkt in die IDE der Entwickler integrieren und so Schwachstellen verhindern, bevor sie sich ausbreiten können.

Wer trägt gemäß dem SAP-Modell der geteilten Verantwortung in einer RISE-Umgebung letztendlich die Haftung, wenn ein KI-Tool eine Sicherheitslücke im benutzerdefinierten Code verursacht?

Die Verantwortung liegt beim Kunden. Benutzerdefinierter Code unterliegt gemäß dem SAP-Modell der geteilten Verantwortung – unabhängig vom Autor – vollständig der Zuständigkeit des Kunden.

Warum gilt eine „Clean-Core“-Strategie nur als „Halbmaßnahme“, wenn ein Unternehmen nicht gleichzeitig einen „Shift-Left“-Sicherheitsansatz umsetzt?

Das Bereinigen des ERP bei gleichzeitiger Bereitstellung unsicherer benutzerdefinierter Codes und KI-generierter Erweiterungen auf SAP BTP ohne frühzeitige Sicherheitsprüfungen schafft lediglich eine neue, weniger überwachte Angriffsfläche. „Shifting Left“ ist unerlässlich, um BTP-Erweiterungen und die „Clean Core“-Strategie wirklich sicher zu machen.

Warum ist „SAP-Native Coverage“ bei der Durchführung automatisierter Sicherheitstests zur Validierung von KI-generiertem Code so wichtig?

Allgemeine Tools zur Erkennung von Web-Sicherheitslücken führen zu gefährlichen blinden Flecken. Eine robuste Lösung muss die spezifische SAP-Architektur, einschließlich ABAP, BTP-Dienste, Berechtigungsobjekte und benutzerdefinierte Namespace-Logik, genau verstehen, um SAP-spezifische Risiken effektiv zu identifizieren und zu mindern.