Im Entwickler-Boudoir I – CVA in der Cloud

SAP Code Vulnerability Analyzer in CloudATC

Barthel weiss, wo er den Most holt

In einer Zeit, in der Cyber-Sicherheitsvorfälle immer häufiger auftreten, unterstreichen aktuelle Berichte die Bedeutung von robusten Sicherheitsmechanismen.

Zwei Beispiele aus vielen.

Ein Vizeadmiral der Deutschen Bundeswehr warnte kürzlich vor der Zunahme von Cyber-Angriffen, wie in einem Artikel von Thomas Daum berichtet wurde. Zudem zeigte ein Bericht von InfoGuard, dass besonders Schweizer Industriefirmen Ziel von Cyber-Attacken sind.

Diese Entwicklungen machen Sicherheit, neben Fehlerfreiheit und Usability zu einer entscheidenden strategischen Komponente bei der Software-Entwicklung.

SAP hat hierzu das secure SDL (secure Software Development Lifecycle) etabliert. Doch da SAP Anwendungen schon seit R/2 Zeiten die Möglichkeit für Kunden-Erweiterungen oder -Eigenentwicklungen anbieten, öffnet sich eine grosse Sicherheitslücke in den hoffentlich sicheren SAP Anwendungen.

Ehrlich: Welcher SAP Kunde kann seine Hand ins Feuer legen, dass seine Eigenentwicklungen sicher sind, dass kein Entwickler oder Entwicklerin eine Lücke hinterlassen oder sogar ein Hintertürchen im Code vergessen hat.

So etwas habe ich wirklich erlebt: „ “, und dies in einer produktiven Anwendung! War nicht mal böse gemeint, sondern nur ein bequemer Pantoffel. Die ganze strukturierte Transportiererei war dem Herrn schlicht zu umständlich. Meistens ist nicht böser Wille, sondern Bequemlichkeit der Grund für viele Sicherheitslücken.

Aber auch das Umfeld der Projekte trägt zu unsicherem Code bei. Projekte haben strenge Budget- und Zeit-Fesseln: Für den Projektleiter zählt, die versprochenen Funktionen in der geplanten Projektdauer umzusetzen. Da bleibt für das Thema Security wohl nicht mehr viel Zeit übrig. Traurig, aber wahr: Sicherer Code ist unsichtbar und fördert daher die Karriere nicht.

Tatsächlich erscheint in diesem Report von sapinsider.org über die Gefahren für die Cyber-Sicherheit von SAP-Systemen Custome Code Vulnerability im oberen Mittelfeld.

Viele Lösungsanbieter haben diesen Anwendungsfall für sich entdeckt und bieten ihre Dienste oder Produkte zur Validierung von Custom Code an. So auch die SAP selber mit der SAP Code Vulnerability Analyzer (CVA). Dieser ist die Check-Variante SLIN_SEC im Code Inspector, kann also leicht mit dem ABAP Test Cockpit (ATC) in den Entwicklungsworkflow eingebunden werden. SAP nutzt ihn selber, um über 500 Millionen Lines of Code zu überprüfen.

Toll, sage ich mir. Lass es uns ausprobieren ‒ Doch warum sind die Checks inaktiv?

Ich entdecke, dass diese Check-Variante eine lizenzpflichtige Komponente ist: SAP Materialnummer 7019502. Ich schaue kurz in die SAP Preisliste, und muss mich setzen. Ein Schock! Fünf Users sollen 249.225,00 CHF kosten! Fünf! Und hinzu kommen die jährlichen Wartungskosten!

Jedem, dem ich das erzählt habe, ist sichtbar das Kinn heruntergefallen. Keine Chance auch nur daran zu denken, dafür im Unternehmen Budget loszueisen ‒ wenn man keine Bank ist!

Sonnig mit Wolken

Wie elektrisiert war ich dann, als ich während eines Vortrags von Olga Dolinskaja hörte, dass der CVA innerhalb der Custom Code Migration App auf dem BTP ABAP Environment (liebevoll auch Steampunk genannt) frei von Lizenzkosten ist. Es entstehen nur die Kosten für eben diese ABAP Instanz auf der BTP (Business Technology Platform), die nicht unerheblich sind, aber viel geringer als die Materialnummer 7019502.

Man kann sogar eine ABAP Instanz mit free_tier Service Plan hierzu verwenden, auch wenn dieser leider die Einschränkung von nur 10 ATC Läufen hat. Aber immerhin…

Ganz klar eine Karotte, um uns in die Cloud zu locken, aber was für eine gutschmeckende!

Ich stürze mich gleich auf unseren Sandbox-Tenant. Angeblich ist ja das Setup leichter als on Premise (siehe Bild). Doch weit gefehlt, wenn man bei Adam und Eva anfangen muss: Cloud Connector installieren, BTP ABAP Environment installieren, alles miteinander verbinden.

Ich ertrinke in Guides und Dokumentationen. Entweder es ist zu viel da, oder es klaffen Lücken. Da bräuchte man einen Berater. Ops, bin ich ja selber. Nun gut, es heisst also, die Zähne zusammenzubeissen und sich durchzukämpfen.

Mein erster Versuch, einen dedizierten Subaccount einzurichten, scheiterte, denn unglücklicherweise hatte ich cf-eu10 als „Region“ gewählt, um später festzustellen, dass es nicht reichte, die Cloud Foundry einzuschalten, nein, man muss den Cloud Foundry Service (Free Tier) beziehen. Und an dem Tag meines Versuchs wurde dieser (noch?) nicht für cf-eu10 angeboten. Also hiess es, alles wieder löschen, denn ich fand keine Möglichkeit, die Region eines Subaccounts nachträglich zu wechseln.

Dass die unterschiedlichen Dienste nicht gleichmässig auf allen Regionen verfügbar sind, ist ein immer wieder aufflammendes Ärgernis.

Mein zweiter Versuch mit Region cf-eu20 gelang schliesslich.

Danach ging es in der frischen ABAP Instanz weiter, es musste die Verbindung zum ABAP System angelegt werden ‒ hier sehnt man sich nach der Einfachheit einer SM59! Aber ich habe es schließlich geschafft, jetzt weiss ich, wie es geht.

Auf meinen ersten Lauf war ich gespannt. Die CVA verbirgt sich hinter einem Custom Code Analyse Projekt der Custom Code Migration App.

Die App entdeckt korrekterweise unseren Kunden-Namensraum /BLUWRKS/.

Unser Sandbox System hat nicht viel Custom Code, daher gibt es nur dreizehn Befunde:

Das Ergebnis besteht aus einer langen Trefferliste mit praktisch keiner Workflow-Möglichkeiten. Aber immerhin…

Der Prio 1 Treffer, übrigens, wurde vom CRM WebUI Erweiterungswerkzeug, dem AXT, generiert und gehört daher in die Ausnahmeliste, wenn sie mal verfügbar sein wird:

Bei vielen Objekten kann man mit einem Klick sich die fragliche Stelle anzeigen lassen:

Zunächst wird der Treffer im adt Service auf dem Entwicklungssystem geöffnet.

Es wird aber ein Button angeboten, um die Stelle im Eclipse-Editor zu öffnen:

Mit grossem Tam-Tam hat SAP angekündigt, dass es jetzt eine ATC Configurator App gibt, aber mit der kann man nur ein paar Attribute und die Priorität der Checks ändern. Ich kann nur hoffen, dass die App weiter angereichert wird, denn stand heute (Q3 2023) ist sie kaum brauchbar.

Was tun?

Alles ist eingerichtet, der CVA im cloud ATC funktioniert. Doch das Ergebnis ist etwas sperrig, da es keine Workflow-Möglichkeiten bietet, um die Arbeit an der Ergebnisliste zu verteilen.

Man muss also das Prozedere gut durchdenken und organisieren, besonders wenn man von dem ABAP free tier Service Plan Gebrauch macht, da man hier nur 10 ATC Läufe frei hat. Denn jedes Entwicklungssystem benötigt einen eigenen Lauf.

Vorschlag

Der erste Aufruf des CVAs sollte als kleines internes Projekt aufgesetzt werden, mit klaren Rollen und Zuständigkeiten. Die Entwicklungsleitung sollte hier die Führung übernehmen, und jedes Line-of-Business Entwicklungsteam sollte einen oder eine Senior-Entwicklerin dafür einplanen. Man kann dieses IT-Projekt zum Beispiel mit Hilfe eines Cloud ALM Projektes steuern. Zum Beispiel kann man dedizierte Rollen anlegen:

Ebenso kann man passende Workstreams erstellen:

Die Sytem Groups und Deployment Plans, mit denen man innerhalb des Projektes die ABAP Systeme auch transport-mässig innerhalb von Releases steuern kann, deute ich hier nur an. Ebenso die Deliverables eines Projektes. Es soll ja noch Stoff für einen weiteren Blog übrigbleiben.

Die Prio 1 Fälle würde ich im gesamten Team durchzuarbeiten, um gemeinsam ein Bewusstsein für die Fälle zu erlangen und gemeinsam getragene Entscheidungen zu treffen.

Im Falle von Prio 2 und 3 Treffern würde ich die Ergebnisliste als Excel Datei herunterladen und nach Zuständigkeiten in weitere Dateien separieren und verteilen. Man kann „Package“ und „Processor“ als Kriterium für die Verteilung heranziehen. Auch hier kann man innerhalb des Cloud ALM Projektes die Verteilung der Excel-Arbeitspakete per Project Tasks durchführen:

Die einzelnen Entwicklerinnen werden über Sub-Tasks gesteuert und können einzeln den Status setzen. Auch gibt es eine direkte Verbindung zum Test-Management und natürlich mit dem finalen Deployment in das Produktivsystem.

Wer den Komfort des direkten Absprungs in den lokalen ATC-Service mag, kann seine Treffer in der Cloud App per Filterung finden und von dort aus in den Editor (Eclipse mit den ABAP Developer Tools, ADT) öffnen.

Usage Daten sind nützlich, aber solange nicht aufgerufenes, jedoch unsicheres Coding im Produktivsystem vorhanden ist, muss es korrigiert werden ‒ oder gelöscht.

Das „Scoping“ der Custom Code Migration App ist überflüssig, denn es wird nur bei einer tatsächlichen Migration mit Hilfe des Software Update Managers (SUM) verwertet.

Die Erkenntnisse aus den Checks sollten in die unternehmenseigenen Programmier-Richtlinien einfliessen.

Ein neuer Kontroll-Lauf nach sagen wir einem Jahr sollte eine viel viel kleinere Trefferliste erzeugen.

Eine Anmerkung zum Schluss. Seit undenklichen SAP Gui Zeiten spricht das Custom Code Management von „Projekten“. Und seit undenklichen Zeiten haben diese CCM-Projekte keine Verbindung mit den „echten“ Projekten, die mit Staff und Budget innerhalb einer vorgegebenen Zeit ein Ergebnis zu liefern trachten. Beide haben (leider) keine Verknüpfung miteinander.

Viel Spass!