TL;DR
Am 29. April 2026 wurden vier zentrale npm-Pakete des SAP-Entwickler-Ökosystems kompromittiert — darunter mbt, @cap-js/sqlite, @cap-js/postgres und @cap-js/db-service. Der Angriff stahl Credentials aus CI/CD-Pipelines, Cloud-Secrets aus AWS, Azure und GCP und verbreitete sich selbstständig weiter — auch über AI-Coding-Tools wie Claude Code und VS Code. Wer in der SAP BTP „vibe-coded“, also schnell mit AI-Assistenten und Open-Source-Paketen entwickelt, ohne die Sicherheitsarchitektur zu hinterfragen, setzt sein Unternehmen einem realen Risiko aus. Simplifier bietet hier einen fundamental anderen Ansatz.
Was ist passiert? Der Shai-Hulud-Angriff auf SAP-Pakete
Was klingt wie Science-Fiction, ist bittere Realität: Am 29. April 2026 hat StepSecurity einen Supply-Chain-Angriff auf das SAP-Entwickler-Ökosystem aufgedeckt, der es in sich hat.
Vier kompromittierte Pakete, die zum täglichen Werkzeugkasten jedes SAP CAP-Entwicklers gehören:
mbt@1.2.48— das SAP Cloud MTA Build Tool@cap-js/sqlite@2.2.2— die SQLite-Anbindung für SAP CAP@cap-js/postgres@2.2.2— die PostgreSQL-Anbindung für SAP CAP@cap-js/db-service@2.10.1— der zentrale Datenbank-Service für SAP CAP
Ein einfaches npm install reichte aus, um eine verheerende Kette in Gang zu setzen:
- Ein
preinstall-Hook lud unbemerkt die Bun-JavaScript-Runtime herunter - Eine 11,6 MB große, verschleierte Payload wurde ausgeführt
- npm-Tokens, AWS/Azure/GCP-Credentials, SSH-Keys, Kubernetes-Configs und sogar Krypto-Wallets wurden gestohlen
- Die Malware verbreitete sich selbstständig auf alle npm-Pakete weiter, auf die der gestohlene Token Zugriff hatte
Das Perfide: Die Malware schrieb sich in .vscode/tasks.json und .claude/settings.json ein — wer das infizierte Repository danach in VS Code öffnete oder eine Claude Code Session startete, wurde erneut infiziert. Der Commit trug die harmlose Nachricht "chore: update dependencies" und war signiert mit claude@users.noreply.github.com.
Der erste Supply-Chain-Angriff, der AI-Coding-Agents als Infektionsvektor nutzt.
Was ist „Vibe Coding“ — und warum boomt es in der SAP-Welt?
Der Begriff „Vibe Coding“ beschreibt einen Entwicklungsstil, bei dem Entwickler sich stark auf AI-Assistenten (Copilot, Claude Code, Cursor) verlassen, schnell Pakete installieren, Code generieren lassen und mit minimalem Review deployen. Das Motto: „Es funktioniert, also ship it.“
In der SAP BTP sieht das so aus:
npm installals erster Schritt — CAP-Projekte starten mit einem halben Dutzend npm-Dependencies- AI generiert Boilerplate — Claude oder Copilot schreiben Service-Handler, OData-Endpoints und DB-Schemas
- CI/CD-Pipelines laufen automatisch — GitHub Actions, GitLab CI oder Azure DevOps bauen und deployen
- Schnelle Iteration — wer am schnellsten liefert, gewinnt
Das Problem: In diesem Flow prüft niemand, was npm install tatsächlich ausführt. Niemand validiert preinstall-Hooks. Niemand überwacht, welche Netzwerkverbindungen während des Builds aufgebaut werden.
Die fünf Sicherheitslücken des Vibe-Coding-Modells
1. Unkontrollierte Abhängigkeitsketten
Ein typisches SAP CAP-Projekt hat nach npm install zwischen 200 und 800 transitive Dependencies. Jede einzelne davon kann einen preinstall-Hook enthalten, der beliebigen Code ausführt — vor der eigentlichen Installation, vor jedem Audit-Tool, vor jedem Review.
Der Shai-Hulud-Angriff hat genau das ausgenutzt: Ein einziger kompromittierter Maintainer-Account reichte, um die Malware in die Kern-Pakete von SAP CAP zu injizieren.
2. CI/CD als Hochwertziel
Die Malware erkennt 32 verschiedene CI/CD-Plattformen — von GitHub Actions über Jenkins bis Vercel. In CI-Umgebungen liest sie den Arbeitsspeicher des GitHub Actions Runners aus, um alle Secrets zu extrahieren — auch solche, die nie als Environment-Variable exponiert waren.
Wer Vibe-Coding betreibt und seine SAP-BTP-Deployments über Standard-CI/CD-Pipelines laufen lässt, gibt der Malware direkten Zugriff auf:
- SAP BTP Service Keys
- Cloud Foundry API-Tokens
- HANA Cloud Credentials
- Destination Service Secrets
3. AI-Assistenten als Angriffsvektor
Der Shai-Hulud-Angriff ist der erste dokumentierte Fall, in dem AI-Coding-Tools als Persistenz- und Verbreitungsvektor missbraucht werden. Die Malware schreibt sich in Konfigurationsdateien ein, die AI-Tools beim Start automatisch ausführen.
Das bedeutet: Wer mit Claude Code an einem infizierten Repository arbeitet, führt die Malware bei jeder neuen Session automatisch aus — ohne es zu merken. Der AI-Assistent selbst wird zum Komplizen.
4. Keine Runtime-Isolation
In der klassischen SAP-BTP-Entwicklung mit CAP und Node.js läuft der gesamte Code — inklusive aller npm-Dependencies — im selben Prozesskontext. Es gibt keine Sandbox, keine Isolation, keine Einschränkung der Netzwerkzugriffe zur Build-Zeit.
Wenn ein preinstall-Hook Credentials stehlen will, kann er das tun. Wenn er Netzwerkverbindungen zu api.github.com aufbaut, fällt das nicht auf — denn diese Domain ist in jeder Enterprise-Firewall erlaubt.
5. Verschlüsselte Exfiltration macht Forensik unmöglich
Der Angriff verschlüsselt gestohlene Daten mit AES-256-GCM, wobei der AES-Key mit RSA-4096 verpackt wird. Selbst wenn ein Unternehmen die Dead-Drop-Repositories auf GitHub findet, sieht es nur Ciphertext. Ohne den privaten Schlüssel des Angreifers ist eine Analyse der gestohlenen Daten unmöglich.
Wie Simplifier das Problem an der Wurzel löst
Simplifier verfolgt einen fundamental anderen Ansatz als das klassische „Code + npm + Deploy“-Modell der SAP BTP. Und genau dieser Unterschied macht den entscheidenden Sicherheitsvorteil aus.
Keine npm-Dependencies, kein Supply-Chain-Risiko
Der Shai-Hulud-Angriff funktioniert, weil Entwickler blindlings npm install ausführen und darauf vertrauen, dass 800 transitive Dependencies sicher sind.
In Simplifier gibt es diesen Angriffsvektor nicht.
Simplifier ist eine Low-Code-Plattform, auf der Geschäftslogik über Business Objects, Connectors und visuelle Workflows abgebildet wird — nicht über npm-Pakete. Die Abhängigkeit von externen, unkontrollierten Open-Source-Registries entfällt vollständig. Es gibt keine preinstall-Hooks, keine unkontrollierten Build-Skripte, keine transitiven Dependency-Ketten.
Managed Runtime statt Open Runtime
In der SAP BTP mit CAP läuft euer Code in einer Node.js-Runtime, die alles darf: Netzwerkzugriffe, Dateisystemzugriffe, Prozess-Spawning. Genau das nutzt die Malware aus.
Simplifier hingegen bietet eine kontrollierte Ausführungsumgebung:
- Business Object Functions laufen in einer verwalteten JavaScript-Sandbox
- Connectors definieren explizite, konfigurierte Verbindungen zu externen Systemen — keine beliebigen HTTP-Calls zur Laufzeit
- Kein Zugriff auf das Dateisystem oder Prozesse — die Angriffsfläche, die der Shai-Hulud-Wurm ausnutzt, existiert schlicht nicht
Deklarative Integrationen statt Code-basierte Wildwest-Verbindungen
Wenn ein SAP-CAP-Entwickler eine Verbindung zu einem SAP-System braucht, schreibt er Code. Dieser Code kann alles tun — inklusive Dinge, die niemand beabsichtigt hat.
In Simplifier sind Integrationen deklarativ:
- REST-Connectors mit definierten Endpoints, Login-Methoden und SSL-Konfiguration
- RFC-Connectors mit expliziter SAP-System-Anbindung
- SQL-Connectors mit kontrolliertem Datenbankzugriff
Jede Integration ist konfiguriert, versioniert und auditierbar. Ein kompromittiertes npm-Paket kann in Simplifier keine SAP-RFC-Verbindung missbrauchen, weil es keinen programmatischen Zugriff auf die Connector-Infrastruktur gibt, der nicht über die Plattform-Governance läuft.
Kein CI/CD-Pipeline-Risiko
Der Shai-Hulud-Angriff zielt gezielt auf CI/CD-Pipelines ab — GitHub Actions, Jenkins, Azure DevOps. Dort liegen die wertvollsten Secrets: Deploy-Keys, Cloud-Credentials, API-Tokens.
Simplifier-Projekte benötigen keine externe CI/CD-Pipeline für Build und Deployment. Die Plattform verwaltet den gesamten Lifecycle intern:
- Kein Build-Schritt mit unkontrolliertem Code-Execution
- Kein
npm installin einer Pipeline - Kein Risiko, dass ein kompromittiertes Paket Pipeline-Secrets extrahiert
Keine AI-Agent-Persistence-Angriffe
Der Shai-Hulud-Angriff schreibt sich in .claude/settings.json und .vscode/tasks.json ein — Dateien, die AI-Coding-Tools automatisch ausführen.
Simplifier-Entwicklung findet auf der Simplifier-Plattform statt, nicht in lokalen IDEs mit unkontrollierten Extension- und Hook-Mechanismen. Der Angriffsvektor „AI-Coding-Agent führt Malware aus“ existiert in diesem Modell nicht.
Das bedeutet nicht: „Low-Code ist immer besser“
Fairness erfordert Differenzierung. Es gibt legitime Gründe, in der SAP BTP mit CAP und Node.js zu arbeiten:
- Maximale Flexibilität bei komplexen, nicht-standardisierbaren Anforderungen
- Große Entwickler-Community und umfangreiches Ökosystem
- Bewährte Patterns für Microservices und Event-Driven Architectures
Aber mit dieser Flexibilität kommt Verantwortung. Und der Shai-Hulud-Angriff zeigt, dass viele Unternehmen diese Verantwortung nicht tragen — weil sie die Risiken nicht kennen, die Tools nicht haben oder die Prozesse nicht leben.
Die Frage ist nicht „Low-Code vs. Pro-Code“. Die Frage ist: Passt euer Sicherheitsmodell zu eurem Entwicklungsmodell?
Konkrete Handlungsempfehlungen
Wenn ihr bei SAP CAP / BTP bleiben wollt:
--ignore-scriptsals Standard fürnpm installsetzen und Hooks einzeln freigeben- Lock-Files (
package-lock.json) committen und Integrity-Hashes prüfen - StepSecurity Harden-Runner oder vergleichbare Tools in CI/CD-Pipelines einsetzen
- Egress-Monitoring in Pipelines aktivieren — jede Netzwerkverbindung muss erklärbar sein
- npm-Tokens mit minimalen Scopes und IP-Einschränkungen versehen
- OIDC Trusted Publishing auf spezifische Branches und Workflows einschränken
- AI-Tool-Konfigurationsdateien (
.claude/,.vscode/tasks.json) in.gitignoreaufnehmen oder per Branch Protection schützen
Wenn ihr auf Simplifier wechseln wollt:
- Bestehende SAP-Integrationen als Simplifier-Connectors (REST, RFC, SQL) abbilden
- Geschäftslogik in Business Object Functions migrieren
- CI/CD-Pipeline-Abhängigkeiten eliminieren — Simplifier verwaltet den Lifecycle
- Security-Audit der bestehenden npm-Dependencies durchführen — ihr werdet überrascht sein, was ihr findet
Fazit: Die Supply Chain ist das neue Schlachtfeld
Der Shai-Hulud-Angriff ist kein theoretisches Risiko. Er ist am 29. April 2026 passiert. Er hat SAP-Kern-Pakete getroffen. Er hat Credentials gestohlen. Er hat sich über AI-Coding-Tools verbreitet. Und er wird nicht der letzte seiner Art sein.
Vibe Coding — schnelles, AI-gestütztes Entwickeln ohne Security-Bewusstsein — ist ein Luxus, den sich Unternehmen im SAP-Umfeld nicht mehr leisten können. Nicht, weil AI-Tools schlecht sind. Sondern weil das zugrunde liegende Modell — hunderte unkontrollierte Open-Source-Dependencies, offene Runtimes, ungeschützte Pipelines — eine Angriffsfläche bietet, die aktiv ausgenutzt wird.
Simplifier bietet eine Alternative: Eine Plattform, die SAP-Integration, Geschäftslogik und Deployment in einer kontrollierten, verwalteten Umgebung vereint — ohne die Dependency-Hölle, ohne die Pipeline-Risiken und ohne die Angriffsflächen, die den Shai-Hulud-Wurm erst möglich gemacht haben.
Die Frage ist nicht, ob der nächste Supply-Chain-Angriff kommt. Die Frage ist, ob eure Architektur darauf vorbereitet ist.
Weiterführende Links:
- StepSecurity: A Mini Shai-Hulud Has Appeared — Vollständige technische Analyse des Angriffs
- DSAGNet Beitrag: WICHTIG! NPM Angriff!
- KI Verantwortung im Unternehmen
