Cyber-Risiko-Alarm: Neuer Threat Report veröffentlicht

Bösartige Pakete in der Open-Source-Lieferkette: Was die Daten von FortiGuard (November 2024 – März 2025) Versicherern sagen

Im November 2024 wurde ein bösartiges npm-Paket, das als legitimes Entwicklungstool getarnt war, mehr als 2.100 Mal heruntergeladen, bevor es markiert und aus der Registry entfernt wurde. Bis Verteidiger dies bemerkten, hatte der eingebettete Diebstahl von Anmeldedaten bereits Umgebungsvariablen von Dutzenden von CI/CD-Pipelines an den Angreifer übermittelt. Dieser einzelne Vorfall ist einer von Tausenden, die in der laufenden Telemetrie-Analyse von FortiGuard Labs zu öffentlichen Paket-Registries erfasst wurden, und er ist die Art von Ereignis, die mittlerweile mit beunruhigender Regelmäßigkeit in den Schadenverläufen der Cyber-Versicherung auftaucht.

Zwischen November 2024 und März 2025 dokumentierte FortiGuard Labs anhaltende Aktivitäten in den Ökosystemen npm, PyPI, RubyGems und NuGet. Der Datensatz ist groß genug und die Angriffstechniken vielfältig genug, dass der Bericht direkte Relevanz für das Underwriting hat. Dieser Beitrag fasst das operative Bild zusammen, übersetzt es in Versicherungskonzepte und skizziert, wie Makler, Underwriter, CISOs und Risk Engineers mit den Daten umgehen sollten.

Was die Telemetriedaten zeigen

Das Bedrohungsaufklärungsteam von FortiGuard verfolgt Pakete, die bei der Installation, danach oder bei der nachfolgenden Abhängigkeitsauflösung bösartiges Verhalten zeigen. Über den Fünf-Monats-Zeitraum identifizierte und analysierte das Team eine hohe Anzahl bestätigter bösartiger Pakete, wobei der Schwerpunkt auf npm und PyPI lag – den beiden Registries, die die JavaScript- und Python-Entwicklungspipelines dominieren.

Drei Muster dominieren den Datensatz:

1. Typosquatting und Identitätswechsel. Bedrohungsakteure registrieren Namen, die sich um ein einziges Zeichen, eine vertauschte Abhängigkeit oder einen Namespace-Bereich von einem legitimen Paket unterscheiden. Beispiele sind crossenv, das cross-env imitiert, und Nachahmerpakete, die interne Utility-Bibliotheken großer Unternehmen imitieren.
2. Dependency Confusion und Namespace-Hijacking. Interne Paketnamen, die privat veröffentlicht werden, werden von Angreifern durch die Veröffentlichung eines bösartigen Pakets mit höherer Versionsnummer in der öffentlichen Registry überholt, sodass der nächste interne Build die trojanisierte öffentliche Version zieht.
3. Living-off-the-Pipeline. Anstatt ein auffälliges ausführbares Programm abzulegen, verstecken Angreifer Payloads in Installationsskripten, Postinstall-Hooks und Pre-Commit-Hooks, die in der lokalen Umgebung des Entwicklers oder in CI-Runnern ausgeführt werden. Stealer zielen auf .npmrc, .pypirc, AWS-Anmeldedaten, GitHub-Tokens und SSH-Schlüssel ab.

Die geografische Verteilung kompromittierter Entwicklungsumgebungen ist stark auf Nordamerika und Westeuropa konzentriert, was widerspiegelt, wo die meiste Unternehmenssoftwareentwicklung stattfindet, aber auch, wo die wertvollsten Anmeldedaten und Cloud-Mandanten (Tenants) angesiedelt sind.

Warum dies für die Cyber-Versicherung relevant ist

Die Risikofläche in der Lieferkette ist kein Randphänomen mehr. Aus versicherungstechnischer Sicht machen drei Faktoren Aktivitäten mit bösartigen Paketen zu einem wesentlichen Treiber für Schäden:

Schadenfrequenz. Ein einzelnes bösartiges Paket kann durch transitive Abhängigkeiten Dutzende nachgelagerte Opfer erzeugen. Wenn ein Entwickler bei einem Versicherungsnehmer ein kompromittiertes Utility installiert, löst der resultierende Vorfall oft Erstschadenskosten für forensische Untersuchungen, Benachrichtigungen und Betriebsunterbrechungen sowie potenzielle Drittschäden (Haftpflicht) aus, wenn Kundendaten offengelegt werden. Die Frequenz zeigt seit drei aufeinanderfolgenden Jahren einen Aufwärtstrend.

Schadensspitzen (Severity Tail). Der Diebstahl von Anmeldedaten auf der Ebene der Build-Pipeline ist besonders kostspielig, da er Angreifern lateralen Zugriff auf Produktionsumgebungen, Quellcode-Repositories und Cloud-Steuerungsebenen ermöglicht. Incident-Response-Firmen berichten regelmäßig von mehrwöchigen Eindämmungszeiträumen und siebenstelligen Sanierungskosten, wenn eine Kompromittierung des Build-Systems involviert ist.

Systemische Korrelation. Ein einzelnes bösartiges Paket erstellt ein Korrelationsereignis auf Portfoliobene. Mehrere Versicherungsnehmer können durch dasselbe Paket am selben Tag kompromittiert werden. Dies ist die Art von Kumulrisiko, das Katastrophenmodelleure und Rückversicherer genau beobachten, und es ist ein häufiges Thema in den umfassenderen Quantifizierungsarbeiten von Resiliently, einschließlich der Analyse in Cyber-Risiko-Quantifizierungstools für KMUs.

Für Underwriter bedeutet dies, dass zwei Versicherungsnehmer mit identischem Umsatz, Personalbestand und Reifegrad des Sicherheitsprogramms sehr unterschiedliche erwartete Schadenprofile haben können, je nach ihren Softwareentwicklungsmethoden. Der Expositionsvektor ist für einen Standard-Antragsfragebogen unsichtbar, aber für die Schadenprognose materiell.

Übertragung des technischen Bildes auf Wirtschaftszweige

Die Mechanismen eines Angriffs mit bösartigen Paketen sind in geschäftlichen Begriffen verständnenswert, da die Kontrollmaßnahmen zu ihrer Verhinderung organisatorisch ebenso wie technisch sind.

Wie der Anriff erfolgt. Ein Entwickler sucht nach einem Utility, kopiert einen Befehl von Stack Overflow oder führt npm install <name> mit einem Tippfehler aus. Das Paket wird ohne sichtbaren Fehler installiert. Ein preinstall- oder postinstall-Skript führt sich lautlos aus. Das Skript liest bekannte Pfade für Anmeldedateien, kodiert den Inhalt in Base64 und sendet ihn per POST an einen vom Angreifer kontrollierten Endpunkt. In einigen Fällen lässt das Payload auch ein sekundäres Implantat für Persistenz fallen.

Warum herkömmliche Kontrollmaßnahmen dies übersehen. Endpoint-Erkennungstools sehen einen legitimen Paketmanager, der ein legitimes Skript ausführt. Netzwerkfilter markieren möglicherweise keinen HTTPS-POST an eine unvertraute Domain, wenn der Computer des Entwicklers großzügige Ausgangsregeln (Egress-Regeln) hat. Code-Review fängt einige dieser Pakete ab, aber transitive Abhängigkeiten – Pakete, die automatisch von anderen Paketen gezogen werden – werden selten namentlich überprüft.

Was der Angreifer erhält. In den meisten Fällen ist der unmittelbare Gewinn Quellcode und Cloud-Anmeldedaten. Die Weitergabe von Quellcode ist an sich ein versichertes Ereignis unter vielen Cyber-Policen, wenn sie regulatorische Benachrichtigungen, die Offenlegung von geistigem Eigentum oder eine nachgelagerte Datenpanne auslöst. Cloud-Anmeldedaten führen direkt zur Aufzählung von S3-Buckets, zum Diebstahl von KMS-Schlüsseln und – zunehmend – zur Vorbereitung von Ransomware, bei der Angreifer legitime Cloud-APIs nutzen, um Daten mit den Tools des Opfers zu verschlüsseln oder zu exfiltrieren.

Zeit bis zur Erkennung. Die mittlere Erkennungszeit für Pakete, die Anmeldedaten stehlen, wird in Wochen, nicht in Stunden gemessen, da die Aktivität wie normales Entwicklerverhalten aussieht. Diese Verzögerung wirkt sich direkt auf die Berechnungen zum Betriebsausfall und die Kosten der forensischen Rekonstruktion aus.

Underwriting-Signale und Deckungsauswirkungen

Für Underwriter, die ein Risiko bewerten, übersetzt sich die Bedrohung durch bösartige Pakete in mehrere konkrete Signale, die es im Rahmen des Antrags zu prüfen gilt:

• Fußabdruck der Softwareentwicklung. Versicherungsnehmer, die Software intern entwickeln, CI/CD-Pipelines betreiben oder zu Open-Source-Projekten beitragen, haben ein signifikant anderes Expositionsprofil als solche, die nur Standardsoftware (Commercial Off-the-Shelf) nutzen. Eine einfache Frage, ob der Versicherungsnehmer eigene Code-Repositories unterhält, ist mittlerweile ein lohnenswerter Underwriting-Datenpunkt.
• Reifegrad der Software-Bill-of-Materials (SBOM). Versicherungsnehmer, die auf Anforderung eine SBOM erstellen können und über automatisierte Tools zur Erkennung von Schwachstellen und bösartigen Paketen verfügen, üben eine Kontrolle aus, die die Frequenz materiell reduziert. Behandeln Sie die SBOM-Fähigkeit als positiven Tarifierungsfaktor.
• Hygiene im Secrets-Management. Umgebungsvariablen, hartcodierte Anmeldedaten und langlebige API-Schlüssel, die in Arbeitsbereichen von Entwicklern gespeichert sind, sind die Hauptziele für Payloads. Versicherungsnehmer, die kurzlebige Anmeldedaten, hardwaregestützte Schlüssel oder Secrets-Manager verwenden, reduzieren die Schadenshöhe, wenn ein Paket erfolgreich ausgeführt wird.
• Egress-Kontrollen und Segmentierung von Entwickler-Arbeitsstationen. Versicherungsnehmer, die Entwicklungsumgebungen segmentieren, Egress-Whitelists durchsetzen und ausgehenden Verkehr von Build-Infrastruktur überwachen, verkürzen das Zeitfenster bis zur Erkennung.

Auf der Deckungsseite verdienen mehrere Lücken explizite Aufmerksamkeit:

• Systemausfall versus Sicherheitsversagen. Einige Policen schließen Schäden aus, die durch nicht bösartige Codefehler entstehen, decken aber Schäden durch bösartigen Code ab. Die Grenze zwischen einem absichtlich bösartigen Paket und einem anfälligen Paket, in das versehentlich Schadsoftware eingebracht wurde, ist nicht immer sauber, und Deckungsstreitigkeiten drehen sich oft um die Ursachenzuschreibung (Attribution) und nicht um die Auswirkung.
• Ausschlüsse für Geldtransfers und Social Engineering. Der Diebstahl von Anmeldedaten von einem Entwickler ermöglicht oft späteren Business Email Compromise oder Überweisungsbetrug. Ob diese nachgelagerten Ereignisse unter den ursprünglichen Diebstahl fallen oder unter die Untergrenzen (Sublimits) für Social Engineering mit wesentlich geringeren Deckungssummen fallen, kann bestimmen, ob ein Schaden vollständig erstattet wird.
• Rufschädigung und Offenlegung von Quellcode. Wenn proprietärer Code durch eine Kompromittierung des Entwicklers exfiltriert wird, können die Kosten für Benachrichtigungen und Wettbewerbsnachteile erheblich sein. Bestätigen Sie, ob Quellcode als vertrauliche Geschäftsinformation oder als regulierte Datenkategorie gemäß der Police behandelt wird, da der auslösende Wortlaut (Trigger) zwischen den beiden oft differs.
• Deckung bei Unbrauchbarmachung (Bricking) und Wiederaufbau. Eine ernsthafte Kompromittierung der Lieferkette kann den Wiederaufbau der Build-Infrastruktur, die Rotation aller Secrets und die Neuerausstellung jedes signierten Artefakts erfordern. Bestätigen Sie, ob die Police auf die Kosten des Wiederaufbaus reagiert, wenn letztlich kein Betroffener benachrichtigt wird.

Empfehlungen nach Rolle

Die Daten von FortiGuard deuten auf eine kurze Liste praktischer Maßnahmen für jede Seite der Versicherungs- und Sicherheitsbeziehung hin.

Für Underwriter:

• Fügen Sie Fragen zur Hygiene der Lieferkette in Antragsformulare ein, einschließlich der Frage, ob der Versicherungsnehmer private Paket-Repositories unterhält, Dependency Pinning verwendet und automatisierte Scanner für bösartige Pakete im CI betreibt.
• Gewichten Sie SBOM-Reife und Secrets-Management positiv in Tarifierungsmodellen. Beide sind während des Antragsprozesses beobachtbar und korrelieren mit reduzierter Frequenz und Schwere.
• Erstellen Sie Kumulszenarien, die an den am weitesten verbreiteten Registries und den am häufigsten installierten Utilities anknüpfen. Eine Handvoll Pakete macht einen unverhältnismäßig großen Anteil an transitiven Abhängigkeiten aus.
• Nutzen Sie das Broker-Scorecard von Resiliently, um den Kontrollreifegrad über ein Portfolio hinweg zu benchmarken und Versicherungsnehmer zu identifizieren, deren Lieferkettenexposition materiell über der der Gleichaltrigen liegt.

Für Makler:

• Positionieren Sie die Einführung von SBOM und das Secrets-Management während Verlängerungsgesprächen als Differenzierungsmerkmale der Deckung, nicht nur als IT-Hygiene-Themen.
• Gehen Sie mit Versicherungsnehmern während der Verlängerung Szenarien zur Lieferkette durch, einschließlich eines durchgerechneten Beispiels, wie ein einziges kompromittiertes Utility ihre Policenauslöser (Trigger), Untergrenzen (Sublimits) und Ausschlüsse beeinträchtigen könnte.
• Kennzeichnen Sie die Nutzung von Entwicklertools – einschließlich npm, PyPI, RubyGems und NuGet – als Tarifierungsfaktor, der vorab offenzulegen ist, da eine unzureichende Offenlegung im Antrag die Schadenregulierung später erschweren kann.
• Ermutigen Sie Versicherungsnehmer, ihre Lieferkettenexposition vor der Verlängerung mit dem Cyber-Risk-Rechner von Resiliently zu quantifizieren, damit Gespräche über die Deckung auf Schadenszahlen und nicht auf abstrakter Risikosprache basieren.

Für CISOs und Risikomanager:

• Implementieren Sie die automatisierte Erkennung bösartiger Pakete direkt in CI/CD-Pipelines, wobei ein Build-Abbruch die Standardreaktion auf eine bestätigte Übereinstimmung ist.
• Erzwingen Sie gepinnte Abhängigkeiten mit Hash-Verifizierung, damit ein Angreifer, der ein bösartiges Paket mit höherer Version veröffentlicht, eine vertrauenswürdige Abhängigkeit nicht stillschweigend ersetzen kann.
• Rotieren Sie Anmeldedaten in kurzen Zyklen, bevorzugen Sie Workload-Identitäten gegenüber langlebigen Schlüsseln, und prüfen Sie .npmrc, .pypirc und die Shell-Historie auf verbliebene Secrets.
• Segmentieren Sie Entwickler-Arbeitsstationen von der Produktion, erzwingen Sie Egress-Whitelists und leiten Sie Build-Runner-Logs an ein überwachtes SIEM weiter, damit ungewöhnlicher ausgehender Verkehr innerhalb von Stunden und nicht Wochen einen Alarm auslöst.

Abschließender Gedanke

Der Datensatz von FortiGuard bestätigt, was Vorfall-Response-Teams seit mehreren Jahren anekdotisch berichten: Die Open-Source-Lieferkette ist mittlerweile ein primärer Schadenvektor für Cyber-Versicherungsportfolios, und die Kluft zwischen gut verwalteten und schlecht verwalteten Entwicklungsumgebungen weitet sich. Underwriter, die die technischen Signale lesen können, Makler, die sie in Deckungsgespräche übersetzen können, und CISOs, die die richtigen Kontrollmaßnahmen nachweisen können, werden alle besser positioniert sein, während sich diese Exposition weiter verstärkt.

Die Daten sind öffentlich, die Muster sind dokumentiert und die Kontrollmaßnahmen sind gut verstanden. Die verbleibende Arbeit besteht darin, die Distanz zu schließen zwischen dem, was die Bedrohungsakteure in den Registries tun, und wofür die Police nach einem Schadenfall tatsächlich aufkommt.