KI im SAP-Custom-Code: Sicherheitsrisiken erkennen und gezielt absichern

Künstliche Intelligenz steigert die Produktivität von Entwicklungsteams erheblich. Boilerplate-Code entsteht in Sekunden, komplexe Logik lässt sich aus natürlicher Sprache ableiten, Syntaxverbesserungen werden automatisch vorgeschlagen, und Optimierungen, die erfahrenen Entwicklern in einem langen Sprint entgehen könnten, werden zuverlässig identifiziert. Geschäftsfunktionen, die früher wochenlange Arbeit erforderten, gelangen heute binnen weniger Tage vom Konzept in die Bereitstellung.

Doch diese Geschwindigkeit hat ihren Preis – vor allem in SAP-Landschaften, wo benutzerdefinierter ABAP- und Nicht-ABAP-Code das Rückgrat betriebswirtschaftlicher Kernprozesse bildet. Wer KI-Assistenten ohne begleitende Sicherheitsstrategie einsetzt, nimmt zusammen mit dem funktionalen Code auch technische Schulden und Sicherheitslücken in Kauf.

Warum KI-generierter Code nicht automatisch sicher ist

KI-Modelle werden auf öffentlich verfügbaren Quellcodes trainiert – darunter viele ältere Codebasen mit bekannten Schwachstellen und veralteten Programmierpraktiken. Da diese Modelle auf Mustererkennung basieren und kein echtes Verständnis von Sicherheitszusammenhängen besitzen, reproduzieren sie diese Muster in neuen Kontexten. Funktionalität steht dabei im Vordergrund: Code, der Funktionstests besteht, muss deshalb noch lange kein Sicherheitsaudit bestehen.

Hinzu kommt, dass KI-Modelle keine Kenntnis der spezifischen Unternehmensarchitektur, der organisatorischen Rollenstruktur oder der Datensensibilität eines Betriebs haben. Fehler entstehen dadurch nicht durch Absicht, sondern durch strukturelle Kontextblindheit.

Typische Schwachstellen, die durch KI-generierten Code entstehen können

• SQL-Injection durch Musterwiedergabe: Trainiert auf historischen ABAP-Beispielen, schlagen KI-Assistenten häufig direkte String-Verkettung für Datenbankabfragen vor – ein klassisches Einfallstor für Angriffe, das auf diese Weise in moderne S/4HANA-Umgebungen zurückkehrt. Angreifer können solche Lücken ihrerseits mit automatisierten Tools aufspüren und ausnutzen.
• Fehlende Autorisierungsprüfungen: SAP-Sicherheit ist eng mit Geschäftslogik und Berechtigungsobjekten verknüpft. Da KI die organisatorische Struktur und Datensensibilität eines Unternehmens nicht kennt, werden AUTHORITY-CHECK-Anweisungen häufig weggelassen. Das Ergebnis: Ein technisch einwandfreier Bericht, der Nutzern unbeabsichtigt Einblick in Gehalts- oder Finanzdaten gewährt, für die keine Berechtigung besteht.
• Nicht verifizierte Abhängigkeiten: KI empfiehlt mitunter veraltete, anfällige oder gar nicht existente Bibliotheken und Funktionsbausteine. Das erzeugt eine schwer nachverfolgbare „Schatten-Lieferkette“ im eigenen Code, die manuell kaum zu kontrollieren ist.
• Oberflächliche Code-Reviews: Die schiere Menge an KI-generiertem Code kann menschliche Prüfer überfordern. Wenn Code fehlerfrei läuft und sauber aussieht, besteht die natürliche Tendenz, die Prüfung zügig abzuschließen. Subtile Schwachstellen wie fehlende Eingabevalidierung oder unsichere API-Verarbeitung gelangen so unbemerkt in die Produktion.
• Compliance-Lücken in regulierten Branchen: In Bereichen wie Biowissenschaften oder Fertigung muss Code Anforderungen wie GxP, NIS2, DSGVO oder CCPA erfüllen. KI-Modellen fehlt häufig das aktuelle Wissen über regulatorische Feinheiten, was sowohl die korrekte Umsetzung als auch die Dokumentation und Nachvollziehbarkeit des Codes erschwert. Zusätzlich können KI-Empfehlungen zu Drittanbieter-Tools dazu führen, dass intern nicht freigegebene Komponenten in geschäftskritische Umgebungen eingebracht werden.

Der blinde Fleck: Benutzerdefinierter SAP-Code

Während SAP seinen Standardkern eigenverantwortlich absichert, liegt die Verantwortung für Z-Programme und Z-Transaktionen vollständig beim jeweiligen Unternehmen. Genau dieser benutzerdefinierte Code wird kontinuierlich erstellt und angepasst – häufig außerhalb einer strukturierten Sicherheitsprüfung. Er stellt damit den größten Sicherheitsblindfleck in der SAP-Landschaft dar.

Erschwerend kommt hinzu: Wenn die Analyse-Tools eines Angreifers eine Schwachstelle im benutzerdefinierten Code identifizieren können, bevor das interne Sicherheitsteam überhaupt von ihrer Existenz weiß, sind sensible Unternehmensdaten einem erheblichen Risiko ausgesetzt.

Shift Left: Sicherheit früh in den Entwicklungsprozess integrieren

Der Ansatz, Sicherheitsprüfungen erst nach der Bereitstellung durchzuführen, greift angesichts des heutigen Entwicklungstempos nicht mehr. Reaktive Sicherheitsmaßnahmen sind schlicht zu langsam. Stattdessen empfiehlt sich eine „Shift Left“-Strategie: Automatisierte Anwendungssicherheitstests (AST) werden direkt in die frühen Phasen des Entwicklungslebenszyklus eingebettet – bevor Code die Produktionsumgebung erreicht. Das verhindert nicht nur Sicherheitsvorfälle, sondern auch kostspielige Nacharbeiten, die entstehen, wenn Fehler erst spät im Testzyklus oder nach einem Vorfall entdeckt werden.

Automatisierte AST-Lösungen für SAP: Was sie leisten müssen

Generische Testwerkzeuge stoßen in SAP-Umgebungen schnell an ihre Grenzen. Eine spezialisierte AST-Lösung muss die spezifischen Strukturen und Sicherheitsmechanismen von SAP verstehen, um wirkungsvoll zu sein. Lösungen wie Onapsis Control sind auf genau diesen Kontext ausgelegt:

• SAP-spezifische Codeanalyse: Tiefes Verständnis von ABAP, seinen Abhängigkeiten und dem Sicherheitskontext von SAP NetWeaver, S/4HANA und SAP BTP – ergänzt durch Unterstützung von Java, Node.js und SAPUI5 für hybride Erweiterungsszenarien
• Integration in bestehende Entwicklungsworkflows: Direkte Anbindung an IDEs, Git-Repositorys und CI/CD-Pipelines, sodass sowohl menschlich als auch KI-erstellter Code bereits vor dem Einpacken auf Schwachstellen geprüft wird
• Automatisierte Transportblockaden: Wird anfälliger Code erkannt, kann er im SAP Transport Management System (TMS) automatisch gestoppt werden – bevor er Produktivsysteme erreicht
• Zero-Trust-Prüfung: Systematische Kontrolle auf fehlende Berechtigungsprüfungen, unsichere Datenverarbeitung und fest kodierte Zugangsdaten nach einem „Verify Everything“-Prinzip
• Compliance-Dokumentation: Automatische Zuordnung von benutzerdefiniertem Code zu regulatorischen Rahmenbedingungen inklusive vollständigem Audit-Pfad – aus einer nicht nachvollziehbaren „Black Box“ wird ein transparentes, prüfbares Asset
• Entwicklerfreundliches Feedback: Klare, umsetzbare Hinweise zur Behebung von Schwachstellen direkt im Entwicklungsprozess, ohne den Arbeitsfluss zu unterbrechen – Sicherheit als Enabler statt als Engpass

Fazit

KI-gestützte Entwicklung und Sicherheit schließen sich nicht aus – sie erfordern jedoch eine bewusste und strukturierte Strategie. Wer die Geschwindigkeit von KI-Tools nutzen möchte, ohne dabei Sicherheit und Compliance zu vernachlässigen, braucht automatisierte Prüfmechanismen, die tief in den Entwicklungsprozess eingebettet sind und den spezifischen Kontext von SAP-Umgebungen verstehen. In Kombination mit aktuellen Bedrohungsinformationen entsteht so eine proaktive „Clean Core“-Strategie, die Systeme agil und regelkonform hält. Nur so lässt sich benutzerdefinierter SAP-Code langfristig als Stärke und nicht als Schwachstelle betreiben.

Im Zusammenhang damit lesen Sie auch:

---