Der Supply-Chain-Angriff auf SAP CAP: was der npm-Vorfall vom April 2026 über Change-Governance verrät

1. Was ein Supply-Chain-Angriff in der SAP-Entwicklung ist

Ein Software-Supply-Chain-Angriff zielt nicht auf das Produktivsystem, sondern auf die Werkzeuge und Abhängigkeiten, mit denen Software gebaut wird. Statt eine Schwachstelle im laufenden System auszunutzen, schleust der Angreifer Schadcode in eine Komponente ein, die Entwickler ohnehin verwenden: eine Bibliothek, ein Build-Werkzeug, ein Paket aus einer öffentlichen Registry. Der Code gelangt dann auf legalem Weg in die Entwicklungsumgebung, oft bevor irgendein Sicherheits-Gate im klassischen Change-Prozess greift.

Im SAP-Kontext ist das relevant geworden, weil moderne SAP-Entwicklung längst nicht mehr nur aus ABAP im geschlossenen System besteht. Das SAP Cloud Application Programming Model (CAP) ist ein Framework für die Entwicklung von Geschäftsanwendungen auf der SAP Business Technology Platform. CAP-Projekte nutzen Node.js und ziehen ihre Abhängigkeiten über npm, den Paketmanager des Node.js-Ökosystems. Damit hängt ein Teil der SAP-Entwicklung an derselben öffentlichen Lieferkette wie der Rest der JavaScript-Welt.

Der Vorfall Ende April 2026 hat diese Abhängigkeit sichtbar gemacht. Offizielle SAP-CAP-Pakete in der npm-Registry wurden manipuliert. Der Angriff betraf nicht das Produktivsystem, sondern die Entwickler-Workstations und die Build-Pipelines, also genau die Schicht, die im klassischen SAP-Change-Management traditionell wenig Aufmerksamkeit bekommt.

1. Warum die Unterscheidung wichtig ist. Der klassische SAP-Change-Prozess beginnt für die meisten Organisationen mit einem Transport. Der Transport wird erstellt, geprüft, freigegeben, importiert. Davor liegt aber eine Zone, die der ITIL-Change-Prozess oft nicht erfasst: die Entwicklungsumgebung, in der der Code überhaupt erst entsteht. Bei CAP- und BTP-Entwicklung umfasst diese Zone npm-Pakete, Build-Tools wie das MTA Build Tool, lokale Caches, CI/CD-Runner und Entwickler-Laptops. Ein Supply-Chain-Angriff setzt genau hier an, also vor dem ersten Transport und vor dem ersten Quality Gate.

2. Der Mini-Shai-Hulud-Vorfall vom April 2026

1. Chronologie und Befund. Ende April 2026 wurde eine koordinierte Kampagne gegen das SAP-Entwicklungs-Ökosystem öffentlich. Mehrere offizielle SAP-CAP-npm-Pakete wurden mit Schadcode versehen und in manipulierten Versionen veröffentlicht. Sicherheitsforscher ordneten den Angriff einer Variante des bekannten Shai-Hulud-Wurms zu und benannten ihn als Mini-Shai-Hulud. Das primäre Ziel der Schadsoftware war der automatisierte Diebstahl von Cloud-Zugangsdaten, Service-Tokens und privaten Schlüsseln.

Die manipulierten Paketversionen waren nur für ein kurzes Zeitfenster verfügbar, nach übereinstimmenden Analysen rund zwei bis vier Stunden am 29. April 2026. Anschließend wurden saubere Versionen veröffentlicht, die die infizierten ersetzen. Wer in diesem Fenster eine betroffene Version heruntergeladen hat, kann betroffen sein, auch wenn das Paket inzwischen wieder sauber ist.

SAP reagierte am 30. April 2026 mit dem HotNews-Sicherheitshinweis 3747787, der die betroffenen Open-Source-Pakete adressiert. Der Hinweis ist als dringende Supply-Chain-Warnung für Organisationen einzuordnen, die SAP CAP, BTP-Entwicklungs-Pipelines, das MTA Build Tool oder npm-basierte SAP-Entwicklungs-Workflows einsetzen.

2. Wie der Schadcode arbeitet. Die technische Funktionsweise ist für die Governance-Diskussion relevant, weil sie erklärt, warum der Angriff so schwer durch klassische Change-Kontrollen zu fassen ist. Die manipulierten Pakete enthielten einen zusätzlichen Lifecycle-Hook, der bei jeder Installation automatisch ausgeführt wird, also vor dem ersten Aufruf des eigentlichen Anwendungscodes. Der Loader war über die betroffenen Pakete hinweg identisch und lud zur Laufzeit weitere Komponenten nach. Das eigentliche Ziel war das Auslesen von Anmeldedaten und Tokens aus der Umgebung des Entwicklers oder des Build-Runners.

Entscheidend ist: Die Ausführung erfolgt zur Installationszeit, nicht zur Laufzeit der Anwendung. Ein Sicherheits-Check, der erst beim Transport-Release oder beim Deployment greift, kommt zu spät. Der Schaden, der Diebstahl von Credentials, ist dann längst eingetreten.

3. Was auf dem Spiel steht. Der Angriff trifft hochwertige Ziele. Entwickler- und CI/CD-Anmeldedaten öffnen den Weg in Cloud-Tenants, Quellcode-Repositories und Deployment-Berechtigungen. Eine kompromittierte Pipeline kann theoretisch genutzt werden, um weiteren Schadcode in legitime Builds einzuschleusen, was die Kette verlängert. Aus Sicht der Compliance verschiebt sich damit die Risikogrenze: Nicht erst das Produktivsystem, sondern bereits der Entwicklungs-Arbeitsplatz wird zum Teil der schützenswerten Landschaft.

3. Den Change-Lebenszyklus nach vorne verlängern

Die zentrale Lehre des Vorfalls ist organisatorisch, nicht nur technisch. Die Kontrollen, die im klassischen SAP-Change-Management am Transport ansetzen, müssen um Kontrollen ergänzt werden, die in der Entwicklungs-Toolchain ansetzen. Die folgenden Ansätze sind keine Reaktion auf einen einzelnen Vorfall, sondern Bausteine einer durchgängigen Supply-Chain-Governance.

1. Abhängigkeiten festschreiben und reproduzierbar bauen. Lockfiles wie package-lock.json legen fest, welche exakte Version eines Pakets installiert wird. Builds gegen einen fixierten Stand sind reproduzierbar und verhindern, dass eine frisch veröffentlichte, manipulierte Version unbemerkt einfließt. Die Pflicht, gegen Lockfiles zu bauen, sollte für alle CI/CD-Pipelines verbindlich sein, nicht optional.

2. Private Registry oder Proxy vorschalten. Statt direkt aus der öffentlichen npm-Registry zu installieren, können Organisationen einen internen Proxy oder eine private Registry betreiben. Pakete werden dort geprüft, freigegeben und zwischengespeichert. Eine neue Version gelangt erst nach einer Karenzzeit und einer Prüfung in den freigegebenen Bestand. Genau diese Karenzzeit hätte beim kurzen Verfügbarkeitsfenster des Mini-Shai-Hulud-Angriffs den Schaden begrenzt.

3. Build-Umgebungen isolieren. CI/CD-Runner sollten in isolierten Umgebungen ohne dauerhaften Zugriff auf produktive Credentials laufen. Werden Lifecycle-Hooks bei der Installation ausgeführt, finden sie dann keine wertvollen Tokens vor. Die Trennung von Build-Umgebung und produktiven Berechtigungen ist eine grundlegende Maßnahme, die unabhängig von einem konkreten Vorfall trägt.

4. Software-Stückliste und Herkunftsnachweis. Eine Software Bill of Materials, kurz SBOM, dokumentiert, welche Komponenten in welcher Version in einen Build eingeflossen sind. Im Vorfall hilft eine SBOM bei der schnellen Antwort auf die entscheidende Frage: Haben wir eine betroffene Version je gezogen, und wenn ja, wo. Ohne diesen Nachweis bleibt die Antwort eine aufwendige manuelle Suche.

4. Wo klassische Change-Kontrollen nicht greifen

1. Die Kontrolllücke vor dem Transport. Der wichtigste Risikobefund: Der klassische SAP-Change-Prozess hat eine blinde Stelle vor dem Transport. Vier-Augen-Prinzip, CAB-Freigabe und Downgrade Protection setzen am Transport an. Sie sind wirksam für das, was sie abdecken, aber sie sehen nicht, was in der Entwicklungsumgebung geschieht, bevor ein Transport überhaupt existiert. Ein Credential-Diebstahl bei der npm-Installation hinterlässt im Transport-Protokoll keine Spur.

2. Persistenz und unvollständige Bereinigung. Das bloße Entfernen oder Zurückstufen des betroffenen Pakets reicht möglicherweise nicht aus, wenn Persistenz-Dateien zurückbleiben oder gestohlene Anmeldedaten weiterhin gültig sind. Eine ernsthafte Reaktion umfasst die Rotation aller potenziell exponierten Credentials, nicht nur die Korrektur der Paketversion. Wer nur das Paket tauscht und die Tokens behält, schließt die Tür, lässt aber den Schlüssel im Schloss.

3. Geteilte Verantwortung als Risikofaktor. CAP- und BTP-Entwicklung verteilt Verantwortung über Teams, die im klassischen SAP-Betrieb getrennt waren. SAP-Basis, Entwicklung, Cloud-Operations und Security arbeiten an verschiedenen Schichten. Ein Supply-Chain-Angriff fällt genau in die Zwischenräume dieser Zuständigkeiten. Ohne klare Verantwortlichkeit für die Entwicklungs-Toolchain bleibt die Lücke offen, weil sich niemand eindeutig zuständig fühlt. Wer die Kontrolle über die eigene Lieferkette nicht aktiv ausübt, überlässt sie demjenigen, der den Schadcode einschleust.

4. Geschwindigkeit gegen Sorgfalt. Der Druck, schnell zu liefern, steht in direktem Konflikt mit der Sorgfalt, die eine geprüfte Lieferkette erfordert. Pipelines, die jede neue Paketversion sofort einziehen, sind schnell, aber exponiert. Eine Karenzzeit kostet Geschwindigkeit, reduziert aber das Zeitfenster, in dem ein manipuliertes Paket Schaden anrichten kann. Die Abwägung ist eine bewusste Governance-Entscheidung, keine technische Nebensache.

5. Ein Kontrollrahmen für die Entwicklungs-Lieferkette

Die folgenden Praktiken fassen die Lösungsansätze zu einem Rahmen zusammen, der auf bestehende SAP-Change-Governance aufsetzt, statt sie zu ersetzen.

1. Die Toolchain in den Geltungsbereich aufnehmen. Der Change-Management-Geltungsbereich endet nicht am Transport. Entwicklungs-Workstations, Paket-Registries, Build-Werkzeuge und CI/CD-Pipelines gehören dokumentiert und kontrolliert.

2. Abhängigkeiten verbindlich fixieren. Lockfiles sind Pflicht, nicht Empfehlung. Builds laufen reproduzierbar gegen einen freigegebenen Stand.

3. Eine Karenz- und Freigabestufe einziehen. Neue Paketversionen durchlaufen eine private Registry mit Prüfung und Wartezeit, bevor sie in Produktivbuilds gelangen.

4. Credentials minimieren und rotieren. Build-Umgebungen erhalten nur die minimal nötigen, kurzlebigen Berechtigungen. Bei Verdacht werden alle exponierten Credentials rotiert.

5. Herkunft nachweisbar machen. Eine SBOM je Release erlaubt die schnelle Beantwortung der Frage, ob und wo eine betroffene Komponente eingesetzt wurde. Das verbindet die Supply-Chain-Kontrolle mit dem durchgängigen Audit Trail, den Compliance-Regime wie SOX, NIS2 und der EU AI Act ohnehin verlangen.

6. Einen Reaktionspfad definieren. Für den Fall eines Supply-Chain-Vorfalls existiert ein dokumentierter Prozess: betroffene Pakete identifizieren, Versionen korrigieren, Credentials rotieren, Persistenz prüfen, Vorfall protokollieren.

6. Tool Landscape

Die folgende Tabelle ordnet ein, welche Werkzeugklasse welchen Teil des Lebenszyklus abdeckt. Sie zeigt, dass kein einzelnes Werkzeug die gesamte Kette abdeckt, und dass die Lieferketten-Kontrolle und die Transport-Governance unterschiedliche Schichten sind, die sich ergänzen müssen.

¹ Solutive AG ist Initiator des Change Orchestration Institute. Die Bewertung in der Tabelle ist eine Selbstauskunft des Anbieters und nicht Teil einer redaktionell unabhängigen Validierung. Die Spalten zur npm- und Abhängigkeits-Prüfung sowie zur Build-Umgebungs-Isolation liegen bewusst außerhalb des Funktionsumfangs der Change- und Transport-Governance und werden durch dedizierte Supply-Chain-Werkzeuge abgedeckt.

Die Tabelle macht die Kernaussage des Artikels sichtbar: Die Transport-Governance-Werkzeuge, einschließlich ChaRM und einer Orchestration-Schicht, sind stark in der Kontrolle des Transports und im durchgängigen Audit Trail. Sie sind aber konstruktionsbedingt nicht dafür gedacht, npm-Pakete auf Schadcode zu prüfen. Diese Aufgabe gehört dedizierten Supply-Chain-Werkzeugen und npm-nativen Mitteln. Eine belastbare Governance kombiniert beide Schichten.

7. Operative Konsequenzen für SAP-Organisationen

Aus dem Vorfall ergeben sich konkrete operative Schritte, die unabhängig von der eingesetzten Plattform gelten.

Die erste Konsequenz betrifft die Bestandsaufnahme. Organisationen sollten klären, ob im fraglichen Zeitfenster eine betroffene CAP-Paketversion gezogen wurde, und das über alle Entwickler-Workstations und Build-Runner hinweg, nicht nur auf einem zentralen Server. Ohne SBOM oder zentrale Registry ist diese Frage aufwendig zu beantworten, was selbst schon ein Befund ist.

Die zweite Konsequenz betrifft die Credential-Hygiene. Tokens und Schlüssel, die in potenziell exponierten Umgebungen lagen, gehören rotiert. Das schließt Service-Tokens für BTP-Tenants, Repository-Zugänge und Deployment-Berechtigungen ein.

Die dritte Konsequenz betrifft die Prozessintegration. Der SAP-Hinweis 3747787 sollte nicht als isolierte Security-Aufgabe behandelt werden, sondern als Anlass, die Entwicklungs-Toolchain dauerhaft in den Change- und Release-Prozess aufzunehmen. Ein einmaliges Aufräumen schließt die Lücke nur kurzfristig.

Die vierte Konsequenz betrifft die Verantwortlichkeit. Es braucht eine benannte Zuständigkeit für die Sicherheit der Entwicklungs-Lieferkette, die die Zwischenräume zwischen Basis, Entwicklung, Cloud-Operations und Security schließt.