Die Lieferkette als Einfallstor: Warum der Angriff auf SAP-Pakete kein Randthema ist

Am 1. Mai 2026 bestätigten Sicherheitsforscher, was viele als theoretisches Risiko abgetan hatten: Die SAP-Entwicklungspakete mbt und @cap-js – zusammen fast zehn Millionen mal monatlich heruntergeladen – waren mit einer Schadkomponente versehen worden. Die sogenannte „Mini Shai-Hulud"-Kampagne hatte einen bösartigen Preinstall-Hook in die Pakete eingeschleust, der bei jeder Entwicklerinstallation plattformspezifische Binärdateien von GitHub bezog und ausführte.

Kein hypothetisches Angriffsszenario. Kein Zero-Day auf einem exotischen System. Sondern der SAP Cloud Application Programming Model – das Fundament moderner DACH-Enterprise-Entwicklung auf SAP BTP.

Das ist ein Eskalationsmoment.

Die Kampagne in der Einordnung

„Mini Shai-Hulud" ist kein Einzelfall. Sie ist der bisher schärfste Punkt einer anhaltenden Angriffsserie gegen Software-Lieferketten, die seit Mitte 2025 an Intensität und Raffinesse zunimmt.

September 2025: 20 Pakete mit zwei Milliarden wöchentlichen Downloads kompromittiert. Eine Phishing-Attacke gegen den Maintainer Joshua Junon ermöglichte die Übernahme populärer npm-Pakete, darunter chalk, ansi-regex und color-convert. Der Angriff verlief über Tage unentdeckt – nicht weil er technisch perfekt war, sondern weil niemand aktiv überwachte.

September 2025: Sich selbst replizierender Wurm infiziert über 180 npm-Pakete. Der Angriff injizierte Code, der bei jeder Veröffentlichung automatisch weitere Pakete kompromittierte und Entwickler-Credentials über TruffleHog abgriff.

Februar 2026: PyTorch Lightning, Versionen 2.6.2 und 2.6.3, kompromittiert. Versteckte Payload-Verzeichnisse führten Code aus, sobald das Framework initialisierte – auf den Systemen tausender ML-Entwickler weltweit.

April–Mai 2026: Ruby Gems und Go Module aus dem „BufferZoneCorp"-Account schmuggeln Credential-Theft, CI-Pipeline-Manipulation und persistente SSH-Zugänge in beliebte Entwicklerwerkzeuge.

Mai 2026: Mini Shai-Hulud – SAP-Kern-Pakete betroffen.

Die Linie von 2025 nach 2026 ist eindeutig: Angreifer haben die Bedeutung von Entwicklerinfrastruktur erkannt und verlagern ihren Fokus systematisch von Endpunkten zu Werkzeugen.

Drei Angriffsmuster, die DACH-Entscheider kennen müssen

1. Preinstall-Hook-Angriffe auf vertrauenswürdige Pakete

Das Muster von Mini Shai-Hulud ist besonders tückisch: Ein bösartiger Preinstall-Hook – also Code, der beim npm install automatisch ausgeführt wird – aktiviert die Schadlogik, bevor der Entwickler irgendetwas getan hat. Kein Klick, kein Öffnen einer Datei, keine Interaktion. Allein die Installation genügt.

Für SAP-Entwicklungsumgebungen bedeutet das: Jede CI/CD-Pipeline, die mbt oder @cap-js referenziert und keine Paket-Integrität prüft, hätte zum Zeitpunkt der Kompromittierung Schadcode ausgeführt – automatisch, unsichtbar, auf privilegierten Build-Servern.

2. Maintainer-Kompromittierung als skalierbare Angriffsfläche

Der Angriff auf Josh Junon im September 2025 zeigt, dass es für Angreifer oft effizienter ist, einen vertrauenswürdigen Menschen zu kompromittieren als ein System. Ein Maintainer-Account mit Schreibrechten auf zwanzig Pakete ist wertvoller als eine Zero-Day-Lücke – und billiger zu erlangen.

npm und GitHub haben als Reaktion 2FA, kurzlebige Tokens und OpenID-Connect-basiertes Trusted Publishing eingeführt. Diese Maßnahmen helfen. Sie schützen nicht rückwirkend und sind kein Ersatz für eigenständige Supply-Chain-Governance in Unternehmen.

3. KI-generierte Malware senkt die Einstiegsschwelle

Die nordkoreanische PromptMink-Kampagne dokumentierte erstmals, was Sicherheitsforscher befürchtet hatten: KI-generierter Code – konkret durch Claude erzeugte Malware in npm-Paketen wie @validate-sdk/v2 – ermöglicht professionell anmutende Angriffe durch Akteure, die bisher nicht über die technische Basis verfügten. Famous Chollima, eine mit Nordkorea assoziierte Gruppe, setzt diese Werkzeuge in laufenden Kampagnen ein.

Die Schwelle zwischen einem staatlichen APT und einem schlecht ausgestatteten Angreifer sinkt. Das Ergebnis: Mehr Angreifer, höhere Angriffsdichte, schwieriger zu attribuieren.

Warum das für DACH-Unternehmen anders ist als für den Rest der Welt

SAP ist nicht irgendein Softwareanbieter. SAP ist das Rückgrat der DACH-Unternehmenslandschaft. Über 80 Prozent der deutschen DAX-Unternehmen laufen auf SAP. Der Mittelstand – Maschinenbau, Automotive, Chemie, Pharma – nutzt SAP ERP in seinen kritischsten Prozessen: Produktion, Finanzen, Beschaffung, Personal.

SAP BTP und das Cloud Application Programming Model (@cap-js) sind die strategische Entwicklungsplattform, mit der diese Unternehmen heute ihre SAP-Systemlandschaft erweitern und modernisieren. Ein kompromittiertes @cap-js-Paket in einer Entwicklungsumgebung bedeutet: Der Schadcode läuft auf der Infrastruktur, die Zugriff auf SAP-Systeme hat.

Das ist kein Worst-Case-Szenario. Das war der Zustand der Mini Shai-Hulud-Kampagne, bis die Pakete vom Repository entfernt wurden.

Und die meisten Unternehmen hätten es nicht bemerkt.

Was NIS2 in diesem Kontext verlangt

Die NIS2-Richtlinie, die seit Oktober 2024 in deutsches Recht umgesetzt werden musste, enthält explizite Anforderungen an Lieferkettensicherheit. Artikel 21 verpflichtet betroffene Einrichtungen zu Maßnahmen, die die Sicherheit der Lieferkette einschließlich sicherheitsbezogener Aspekte der Beziehungen zu Lieferanten und Dienstleistern adressieren.

Das ist nicht abstrakt. Es bedeutet konkret:

• Softwareabhängigkeiten sind Lieferanten. Wer als wichtige oder kritische Einrichtung nach NIS2 gilt und keine Kontrolle über seine Build-Abhängigkeiten hat, verletzt nachweislich seine Sorgfaltspflichten.
• Dokumentationspflicht. Unternehmen müssen nachweisen können, welche Maßnahmen sie zur Prüfung ihrer Software-Lieferkette ergriffen haben.
• Managerhaftung. Geschäftsführer und Vorstandsmitglieder haften persönlich für schwerwiegende Versäumnisse – bis zu zehn Millionen Euro oder zwei Prozent des weltweiten Jahresumsatzes.

Ein Supply-Chain-Vorfall, der durch eine ungeprüfte npm-Abhängigkeit verursacht wird, ist vor diesem Hintergrund kein technisches Problem. Er ist ein Haftungsfall der Geschäftsführung.

Drei Maßnahmen mit konkreter Wirkung

Software Composition Analysis und SBOM einführen

Software Bill of Materials – eine strukturierte Liste aller Softwareabhängigkeiten – ist die Grundlage jeder Supply-Chain-Governance. SBOMs ermöglichen es, kompromittierte Pakete in Echtzeit zu identifizieren und aus CI/CD-Pipelines zu entfernen.

Werkzeuge wie Dependabot, Snyk oder OWASP Dependency-Track können in bestehende Build-Systeme integriert werden. Der Aufwand ist überschaubar; der Nachweis gegenüber Regulatoren ist erheblich.

Ein strukturierter Compliance Sprint schafft in vier Wochen die prozessuale und dokumentarische Grundlage, die NIS2 für Supply-Chain-Sicherheit verlangt – inklusive SBOM-Prozess und Richtlinien für Drittanbieter-Software.

M&A-Targets auf Software-Lieferketten prüfen

Wer ein Unternehmen erwirbt, übernimmt auch seine Build-Infrastruktur, seine CI/CD-Pipelines und seine Abhängigkeitslandschaft. Die Frage „Welche npm-Pakete referenziert das Target?" klingt technisch; sie ist finanziell.

Ein kompromittiertes Entwicklungssystem in einem Akquisitionsziel kann erheblichen Reputations- und Haftungsschaden nach Closing nach sich ziehen – insbesondere wenn das Target im DACH-Raum als kritische oder wichtige Einrichtung nach NIS2 gilt.

Ein professionelles M&A Cyber Due Diligence Audit schließt heute die Prüfung von Software-Lieferketten explizit ein. Das Angriffsmuster von 2026 macht das zur Pflicht, nicht zur Option.

Kontinuierliche Sicherheitsführung statt reaktivem Patch-Management

Die Angriffswelle der vergangenen Monate zeigt: Die Frage ist nicht, ob eine Abhängigkeit kompromittiert wird, sondern wann – und ob das eigene Unternehmen es rechtzeitig bemerkt. Dafür braucht es kontinuierliche Überwachung, klare Eskalationsprozesse und eine Person, die verantwortlich ist.

Ein vCISO-Mandat gibt Unternehmen genau das: strategische Sicherheitsführung, die das Bedrohungslagebild versteht, Supply-Chain-Risiken in das laufende ISMS integriert und bei einem Vorfall sofort handlungsfähig ist – ohne die Fixkosten eines Vollzeit-CISO.

Der eigentliche Befund

Die Mini Shai-Hulud-Kampagne ist nicht das Ende dieser Entwicklung. Sie ist ein Datenpunkt in einer Kurve, die seit 2025 konstant nach oben zeigt. Angreifer haben verstanden, dass Entwicklerinfrastruktur das schwächste Glied in modernen Sicherheitsarchitekturen ist – weil sie hohe Privilegien hat, wenig überwacht wird und von Unternehmen implizit als vertrauenswürdig behandelt wird.

SAP-Pakete mit zehn Millionen Downloads sind kein Nischenprodukt. Sie sind der Kern der DACH-Enterprise-Softwareentwicklung.

Die Frage, die jede IT-Verantwortliche und jeder Geschäftsführer im DACH-Raum heute stellen sollte, ist nicht: „Könnten wir betroffen sein?" Die Frage ist: „Hätten wir es bemerkt?"

---

Woodlands Advisory unterstützt DACH-Unternehmen dabei, Software-Lieferketten nachweisbar abzusichern – von der SBOM-Implementierung über NIS2-konforme Prozesse bis zur strategischen Sicherheitsführung. Wenn Sie Ihre aktuelle Exponierung einschätzen möchten, sprechen Sie mit uns.

Erstgespräch vereinbaren →