Mit dem Security Patch Day im Mai 2026 hat sich die SAP dazu entschieden den Report „RSBDCOS0“ stillzulegen. Was bei erster Betrachtung aus einer SAP Security Perspektive wie eine gute Entscheidung aussieht, bringt jedoch bei einer zweiten Betrachtung einige Zweifel mit sich.
Aber lassen Sie uns von vorne beginnen.
Was macht der Report „RSBDCOS0“?
Der Report “RSBDCOS0” erlaubt es, SAP Nutzern Betriebssystembefehle direkt über den SAP GUI auszuführen, ohne sich separat auf Betriebssystemebene anmelden zu müssen. Man könnte „RSBDCOS0“ als eine “ABAP-shell” bezeichnen. Klingt problematisch, ist es auch. Wer Betriebssystembefehle ausführen kann, hat die Macht über das gesamte SAP-System.
Ein bösartiger (interner) Angreifer, welcher die Möglichkeit hat Betriebssystembefehle direkt auszuführen, kann die Verfügbarkeit (Uptime) des gesamten SAP-Systems gefährden. Aber auch die Integrität des SAP-Systems kann gefährdet sein, wenn man beispielsweise manipulierte SAP-Kernels oder alte SAP-Kernels mit Sicherheitslücken unterschiebt.
Sobald ein SAP Nutzer OS-Kommandos ausführt, werden diese OS-Kommandos nicht mit den Berechtigungen des SAP-Users durchgeführt. Ebenso wenig findet ein konkretes Logging auf Betriebssystemebene statt, wer dieses OS-Kommando ausgeführt hat, da das OS-Kommando über den OS-Nutzer <SID>adm ausgeführt wird. Dieser Nutzer hat umfassende Rechte auf dem Betriebssystem und kann unter anderem den SAP-Kernel manipulieren oder gar komplett löschen. Dies trifft auch auf andere SAP-Executables zu.
Mit dem HDBSQL Kommando bei HANA-Datenbanken kann man ALLE SAP-Tabellen auslesen oder noch schlimmer manipulieren. Damit kann es zu einer direkten Offenlegung von Informationen kommen (Information Disclosure) und die Integrität (System-Integrity) des SAP-Systems kann nicht mehr gewährleistet werden.
Das Ergebnis: Alle drei Säulen der CIA-Triade (Vertraulichkeit, Integrität & Verfügbarkeit) sind kompromittiert.
smarterSec Hinweis:
Betriebssystembefehle in SAP sind hochkritisch zu betrachten!
Leser
“Aber dann ist die Stilllegung des Reports „RSBDCOS0“ doch wichtig und richtig…”
Jein. Das eigentliche Kernproblem ist die Ausführung von einigen kritischen OS-Kommandos. In vielen Szenarien sind OS-Kommandos aber noch täglich Brot eines SAP-Basis Mitarbeiters. Vor allem im On-Premise Betrieb oder auch bei einer gehosteten Instanz bei einem der Hyperscaler.
Leser
“Den Report „RSBDCOS0“ gibt es seit Jahrzehnten, warum wird diese jetzt erst als kritisch betrachtet?”
Eine sehr wahrscheinliche Antwort ist „RISE with SAP“, welches die Verantwortung auf Betriebssystemebene von den Kunden auf SAP verlagert. Tools wie „RSBDCOS0“ sind nicht nur riskant, sondern auch mit diesem Betriebsmodell nicht vereinbar.
Leser
“Bisher sehe ich aber noch keinen Grund, der gegen eine Stilllegung spricht.”
Es gibt neben dem Report „RSBDCOS0“ noch weitere Wege Betriebssystemkommandos auszuführen.
Hierzu gehören unter anderem:
- Absetzen von OS-Kommandos via Transaktion SM49 & SM69
- Kernel Call „Call System” via ABAP-Code
- die beiden Funktionsbausteine SXPG_COMMAND_EXECUTE und SXPG_COMMAND_EXECUTE_LONG
Der Report „RSBDCOS0“ war bisher der eigentliche “Standardweg”, welchen die SAP-Basis genommen hat, um Betriebssystemkommandos durchzuführen. Die Ausführung von „RSBDCOS0“ landet zumindest Stand heute schon im Security Audit Log (wenn auch nur sehr limitiert). Das heißt, hierrüber könnten zumindest bei kontinuierlicher Überwachung des Security Audit Logs OS-Kommandos via „RSBDCOS0“ erkannt werden.
Die Stilllegung von „RSBDCOS0“ führt nun aber dazu, dass die jeweiligen Alternativen genutzt werden.
Wir beobachten, dass viele SAP-Kunden nun eigene Lösungen schreiben. Kundenreports sind in aller Regel auch nicht sicher(er) als der Report „RSBDCOS0“.
Vermutlich sogar, weniger sicher, aufgrund des fehlenden Loggings innerhalb des Security Audit Logs.
Ein einfacher Z-Klon, also etwa ein „Z_RSBDCOS0“ wird zudem keine zukünftigen Sicherheitsupdates von SAP erhalten und ist damit ein dauerhaftes Sicherheitsrisiko.
In „RISE with SAP“ ist das auch ein direkter Compliance-Verstoß.
Das raten wir als smarterSec unseren Kunden:
Was bedeutet das konkret für Ihre SAP-Landschaft? Unsere Empfehlungen:
SCI für ABAP-Code-Scans aktivieren –
Konkret für den Kernel-Aufruf Call ‚System‘, welcher OS-Kommandos direkt aus ABAP-Code heraus absetzt. Der SAP Code Inspector (SCI) erlaubt es, eigene Prüfmuster zu definieren und damit gezielt nach solchen Konstrukten im ABAP-Repository zu suchen. Dieser Schritt ist besonders wichtig, da Call ‚System‘ im Security Audit Log keinerlei Spuren hinterlässt.
Eigenes Prüfmuster im ATC (ABAP Test Cockpit) für die SXPG-Funktionsbausteine –
Die Funktionsbausteine SXPG_COMMAND_EXECUTE und SXPG_COMMAND_EXECUTE_LONG sind funktional gleichwertig zu „RSBDCOS0“, aber weit weniger im Fokus der Administratoren. Auch hier empfehlen wir ein dediziertes Code-Scan-Pattern, um die Nutzung dieser Bausteine im Eigencode zu erfassen und zu bewerten.
Transaktionen SM49/SM69 konsequent per Berechtigungen absichern –
Die Transaktionen SM49 und SM69 für externe Betriebssystemkommandos sollten nur einem absolut minimalen, namentlich bekannten Personenkreis zugänglich sein. Keine Sammelrollen, keine Vererbung über generische Basis-Profile. Zugriff auf die Transaktionen SM49/SM69 bedeutet de facto mehr Rechte als SAP_ALL: Wer externe OS-Kommandos ausführen kann, hat nicht nur Zugriff auf das SAP-System selbst, sondern auf das gesamte Betriebssystem, die Datenbank und alle SAP-Tabellen, die nicht einmal über den normalen ABAP-Applikationslayer erreichbar sind. Das ist ein Zustand, der in keiner regulären Rolle landen darf.
Unser Fazit
Die Stilllegung des Reports „RSBDCOS0“ ist gut gemeint, aber zu kurz gedacht. SAP schließt eine Tür, lässt dabei aber mehrere Fenster weiterhin offen. Die verbleibenden Alternativen wie SM49/SM69, die SXPG-Funktionsbausteine und direkte Kernel-Aufrufe via Call ‚System‘ sind teilweise noch schwerer zu kontrollieren als der ursprüngliche Report „RSBDCOS0“, weil sie erst gar nicht im Security Audit Log auftauchen.
Eine gezielte Härtung des Reports, verbunden mit einem verpflichtenden Logging aller ausgeführten Kommandos, wäre wahrscheinlich der wirkungsvollere Schritt gewesen. Stattdessen verlagern viele SAP-Kunden die Nutzung nun auf Alternativwege. Oft mit selbst geschriebenem ABAP-Code, der noch weniger Sicherheitsmechanismen mitbringt als das Original.
Wir hoffen, dass SAP hier nachsteuert: insbesondere ein natives Code-Pattern für SXPG-Aufrufe im SAP Code Inspector / im ATC würde zumindest die Transparenz im kundeneigenen ABAP-Code deutlich verbessern.
Bis dahin liegt die Verantwortung bei den SAP-Teams der Kunden selbst. Und die meisten haben OS-Kommandos schlichtweg nicht auf dem Radar.
Sie sind unsicher, wo Sie anfangen sollen? Das ist verständlich, denn das Thema ist komplex, und die wenigsten SAP-Teams haben die personelle Kapazität oder das Know-How, es nebenbei zu lösen.
Wir können helfen.
Verwandte Themen: SAP Security Patchday 05/2026: Wir verabschieden uns von einem alten Bekannten.