Maschinenraum · Reihe „SAP ABAP Code Security“, Teil 2
Im Auftakt dieser Reihe ging es darum, warum der kundeneigene ABAP-Code ein eigenständiges Sicherheitsthema ist und welche Muster wir uns ansehen werden. Dieser Beitrag handelt von der unbequemen Folgefrage: Was macht man mit einer Trefferliste, die nach dem ersten Scan ein paar hundert Zeilen lang ist?
Die ehrliche Antwort lautet: Man behandelt es als Projekt, nicht als Aufräumnachmittag. Und das Projekt hat zwei Hälften, die SAP treffend als GET_CLEAN und STAY_CLEAN bezeichnet.
Warum Einzelfixes nicht reichen
Die Versuchung ist groß, nach dem ersten Scan einfach loszufixen, die offensichtlichen Fälle mit hoher Kritikalität zuerst, der Rest „wenn mal Zeit ist“. Aber das scheitert zuverlässig, aus drei Gründen.
Erstens: Ohne Priorisierung arbeitet man die Liste in der Reihenfolge ab, in der sie der Scanner ausgespuckt hat, also nach Programmname, nicht nach Risiko. Das hartcodierte Passwort im täglich laufenden Schnittstellenprogramm hat dann dieselbe Dringlichkeit wie der Breakpoint in einem Report, den zuletzt 2014 jemand gestartet hat.
Zweitens: Ohne Baseline weiß man nie, ob man fertig ist. Eine gewachsene Landschaft produziert ständig neuen Code. Wer nur fixt, ohne den Zufluss zu kontrollieren, schöpft Wasser aus einem Boot mit Loch.
Drittens: Eine Häufung einfacher Schwächen ist gefährlicher als die Summe ihrer Teile. Ein vergessener Breakpoint ist harmlos. Ein vergessener Breakpoint plus ein Programm, das Betriebssystembefehle ausführen kann, plus ein hartcodierter technischer User mit weiten Rechten, Denn das ist die kritische Angriffskette. Einzelfixes sehen die Kette nicht.
GET_CLEAN: der einmalige Kraftakt
GET_CLEAN ist der strukturierte Prozess, den vorhandenen Bestand einmal vollständig zu bereinigen. Er läuft in Wellen, nicht in einem Schwung.
1. Inventur und Baseline. Bevor irgendetwas gefixt wird, braucht es einen reproduzierbaren Ausgangsstand. Ein vollständiger Scan über alle Eigenobjekte (Z*, Y*, reservierte Namensräume) mit einem festen Satz an Prüfmustern liefert die Baseline. Reproduzierbar heißt: Derselbe Scan, dieselben Muster, jederzeit wiederholbar. Das ist der einzig sinnvolle Weg, den späteren Fortschritt zu messen.
2. Triage. Jeder Treffer wird manuell bewertet. Hier trennt sich Falschalarm von echtem Risiko, und hier entsteht die Priorisierung. Bewährt hat sich eine Einordnung entlang von zwei Achsen: Kritikalität des Musters (eine REPOSRC-Manipulation wiegt schwerer als ein Breakpoint) und Exposition des Programms (läuft es produktiv, ist es per RFC oder Web erreichbar, mit welchen Rechten?). Das Produkt aus beidem ergibt die Reihenfolge.
3. Remediation in Wellen. Abgearbeitet wird nach Priorität, in überschaubaren Paketen, jeweils mit Test und Transport. Wichtig ist, gleichartige Muster zu bündeln: Alle hartcodierten Passwörter zusammen, alle CALL SYSTEM-Stellen zusammen. So entsteht Routine, und die Lösungsmuster lassen sich wiederverwenden.
4. Verifikation. Nach jeder Welle der erneute Scan gegen die Baseline. Die Trefferzahl muss messbar sinken; bleibt sie stehen, stimmt etwas mit dem Fix oder der Transportkette nicht. Am Ende steht ein dokumentierter Zielzustand, denn das ist die Grundlage für STAY_CLEAN.
Realistisch ist GET_CLEAN selten ein „und dann ist alles weg“. Manche Stellen lassen sich nicht ohne fachliche Klärung umbauen, manche gehören zu Programmen, die ohnehin abgelöst werden. Auch das ist ein legitimes Ergebnis, solange es eine Entscheidung ist und kein Vergessen.
STAY_CLEAN: die Daueraufgabe
GET_CLEAN bereinigt die Vergangenheit. STAY_CLEAN sorgt dafür, dass die mühsam erreichte Sauberkeit nicht beim nächsten Transport wieder verloren geht. Das ist der Teil, der gern unterschätzt wird — und der über den langfristigen Erfolg entscheidet.
Prüfung in den Entwicklungsprozess verlagern. Der wirksamste Hebel ist, kritische Muster gar nicht erst in den Transport zu lassen. Der ABAP Test Cockpit (ATC) mit einem auf die Eigencode-Risiken zugeschnittenen Prüfvariantensatz ist hier das Standardwerkzeug. Eine ATC-Prüfung im Transport-Release-Schritt (oder als Quality Gate im Change-Management) verschiebt die Kontrolle von „nachträglich aufräumen“ zu „gar nicht erst hereinlassen“.
Den Secure Programming Guide verbindlich machen. Coding-Guidelines, die das Verbot bestimmter Konstrukte ausdrücklich benennen wie z.B. keine Updates auf Repository-Tabellen, keine CALL SYSTEM-Aufrufe, keine hartcodierten Geheimnisse, kein IF sy-uname als Berechtigungsersatz, sind die Voraussetzung dafür, dass eine ATC-Beanstandung nicht als Schikane, sondern als bekannte Regel wahrgenommen wird.
Tiefe nachrüsten, wo nötig. Für die Klassen, die ein Pattern-Scan nicht zuverlässig beurteilen kann (Injection-Risiken mit echtem Datenfluss), gehört der Code Vulnerability Analyzer (CVA) in die Pipeline. Er ist die Datenflussanalyse, die der ATC-Standardumfang nicht leistet.
Entwickler befähigen, nicht nur kontrollieren. Ein Gate, das niemand versteht, wird umgangen. Kurze, konkrete Schulungen an echten Beispielen – genau dafür existiert übrigens das Repository ABAP_Evildoers:
Zu jedem Muster ein lauffähiges Negativbeispiel und die saubere Gegenvariante. Praxis wirkt immer nachhaltiger als jede Richtlinie im Intranet.
Das Projekt steuern: Rollen, Messung, Governance
Damit aus den zwei Hälften ein funktionierendes Projekt wird, braucht es ein paar organisatorische Festlegungen.
Verantwortung klären. Wer entscheidet bei einem Befund über fachliche Auswirkungen? In der Regel ist das nicht das Security-Team allein, sondern ein Zusammenspiel aus SAP-Basis, Entwicklung und Fachbereich. GET_CLEAN ohne fachliche Rückendeckung führt zu Programmen, die zwar sicher, aber kaputt sind.
Fortschritt messbar machen. Die Baseline-Trefferzahl pro Muster ist die zentrale Kennzahl. Eine einfache Risiko-Matrix wie Muster gegen Restbestand, eingefärbt nach Kritikalität, macht für die Entscheiderebene in einem Bild sichtbar, wo das Projekt steht. Das ist auch die Brücke zur Strategie-Ebene: Ein Vorstand will keine Liste von ABAP-Befunden sehen, sondern eine Trendkurve, die nach unten zeigt.
Den Zufluss überwachen. Die aussagekräftigste STAY_CLEAN-Kennzahl ist nicht der Restbestand, sondern die Zahl neuer Befunde pro Quartal. Solange die gegen null geht, funktioniert das Gate. Steigt sie, ist entweder das Gate löchrig oder die Schulung verpufft.
Reifegrad: woran man Erfolg erkennt
Ein Eigencode-Sicherungsprojekt ist nicht abgeschlossen, wenn die letzte Fundstelle gefixt ist, sondern wenn die Organisation einen stabilen Zustand erreicht hat: Der Altbestand ist bereinigt oder bewusst risikoakzeptiert, neue kritische Muster scheitern am Quality Gate, und Entwickler kennen die Regeln, bevor sie sie brechen. Erst dann ist aus GET_CLEAN ein dauerhaftes STAY_CLEAN geworden.
Bis dahin gilt die einfache Faustregel: GET_CLEAN ist ein Projekt mit Anfang und Ende, STAY_CLEAN ist ein Betriebsmodus. Wer nur das erste macht, steht in zwei Jahren wieder am Anfang.
Ab dem nächsten Beitrag geht es konkret: Muster für Muster, jeweils mit lauffähigem Beispiel im Repository. Den Anfang macht der Klassiker — der hartcodierte Benutzervergleich IF sy-uname.
