Red Team vs. Blue Team
Angreifer haben es selten auf Ihr Unternehmen abgesehen. Sie zielen auf das Paket, die Action oder das Build-Tool, von dem Unternehmen überall abhängen, und probieren den Exploit dann an allen gleichzeitig aus. Ihre Abhängigkeitsliste brauchen die Angreifer nicht. Sie schon.
Ein Angriff auf die Software-Lieferkette kompromittiert etwas, aus dem ein Produkt gebaut wird, etwa ein Open-Source-Paket, eine CI/CD-Komponente oder das Build-System, statt das Produkt direkt anzugreifen. Moderne Software besteht größtenteils aus dem Code anderer: Das meiste stammt aus Open-Source-Paketen, und die meisten davon sind transitive Abhängigkeiten, die niemand im Team ausgewählt hat. Kompromittieren Sie eine weit verbreitete Komponente, und Sie erreichen jede Organisation, die darauf aufbaut.
Das verändert, wie Angreifer ihre Ziele wählen. Sie recherchieren nicht die Abhängigkeiten eines einzelnen Unternehmens. Sie wählen ein Paket oder Tool mit großer Verbreitung, nutzen es überall aus und sehen, was antwortet.
Ein Fehler in einem beliebten Open-Source-Paket wird bekannt, und Angreifer nutzen ihn in jedem Produkt aus, das die verwundbare Version ausliefert, meist als transitive Abhängigkeit, die niemand direkt ausgewählt hat.
Ein Angreifer übernimmt ein Maintainer-Konto, oder ein Wurm stiehlt Veröffentlichungs-Tokens, und veröffentlicht eine vergiftete Version eines vertrauenswürdigen Pakets. Sie läuft in dem Moment, in dem ein Build sie installiert, wie beim npm-Wurm Shai-Hulud.
Ein Mitwirkender gewinnt über längere Zeit das Vertrauen eines Open-Source-Projekts und schleust dann bösartigen Code in ein Release ein, das nachgelagerte Distributionen und Produkte übernehmen, wie bei der Hintertür in xz utils.
Pakete mit Namen, die beliebten Paketen ähneln, fangen Tippfehler ab. Dependency Confusion geht weiter: Ein öffentliches Paket mit demselben Namen wie ein internes Paket eines Unternehmens wird an dessen Stelle installiert.
Eine GitHub Action oder ein anderes Build-Tool wird gekapert, und jede Pipeline, die es nutzt, führt den Code des Angreifers aus, mit ihren Secrets in Reichweite, wie bei tj-actions und Codecov.
Der Build selbst wird verändert oder das Artefakt zwischen Build und Deployment ausgetauscht, sodass auch sauberer Quellcode ein kompromittiertes Release ergibt, wie bei SolarWinds.
SolarWinds ist der bekannteste Lieferkettenangriff: bösartiger Code, der beim Build eingefügt und als normales Update an Kunden ausgeliefert wurde. Die jüngsten Angriffe zielen stattdessen auf Paket-Registries und CI-Pipelines, wo ein einziges kompromittiertes Paket oder eine einzige kompromittierte Action jeden Build erreicht, der sie nutzt. Die neuesten zuerst:
Ein sich selbst verbreitender Wurm, der läuft, wenn ein infiziertes npm-Paket installiert wird, npm-, GitHub- und Cloud-Tokens stiehlt und infizierte Versionen der anderen Pakete des Opfers veröffentlicht. Die meisten Infektionen liefen im CI.
So prüfen Sie Ihre Builds →Laut CISA war jede Version dieser beliebten GitHub Action drei Tage lang kompromittiert, wobei Secrets in Workflow-Logs offengelegt wurden. Workflows, die sie per Tag referenzierten, führten den Code des Angreifers aus.
Andres Freund fand eine Hintertür in den xz-Versionen 5.6.0 und 5.6.1, nachdem ihm aufgefallen war, dass SSH-Logins zu viel CPU verbrauchten. Sie war in das Upstream-Projekt selbst eingeschleust worden.
Ein Fehler in Apache Log4j 2 erlaubte einem Angreifer, der eine geloggte Nachricht kontrollierte, beliebigen Code auszuführen, bewertet mit CVSS 10.0. Die Schwierigkeit für die meisten Teams bestand darin, herauszufinden, welche Anwendungen log4j-core enthielten, meist als Abhängigkeit einer Abhängigkeit.
Angreifer veränderten das Bash-Uploader-Skript, das Teams in ihren CI-Pipelines ausführten, sodass es die CI-Umgebung samt Zugangsdaten, Tokens und Schlüsseln an einen Server außerhalb der Codecov-Infrastruktur sendete. Es lief unbemerkt vom 31. Januar, bis ein Kunde es am 1. April meldete.
Angreifer hatten langfristigen, verdeckten Zugang zum Build-Prozess von SolarWinds Orion und fügten bösartigen Code in die Orion-Releases 2019.4 bis 2020.2.1 HF1 ein, die Kunden als normale Updates installierten. CISA erließ daraufhin eine Notfallanweisung.
Red Team vs. Blue Team
Jede Stufe in den Worten des Angreifers und die Verteidigung, die darauf antwortet.
Stufe 1 von 3
Sie müssen das Ziel nicht kennen. Wählen Sie das Paket, und die Ziele ergeben sich von selbst.
Red Team
Sie brauchen deren Lockfile nicht. Beliebte Pakete stecken tief im transitiven Baum von fast allem, und die meisten Teams können nicht sagen, welche sie ausliefern. Öffentliche Hinweise grenzen es ein: Versionen in JavaScript-Bundles und HTTP-Headern, öffentliche Repositories und Container-Images. Und was deren Build außerhalb des Lockfiles lädt, etwa die Binärdatei, die ein Postinstall-Skript herunterlädt, oder die Schichten unter dem Basis-Image, hat deren Scanner nie gesehen, also patcht es niemand.
Blue Team
CRACI sieht den Datenverkehr, der in jeden Build hineinkommt, und zeichnet jedes Paket und jede Datei auf, die er lädt, einschließlich der versteckten Abhängigkeiten, die Lockfile-basierte Tools übersehen, auf jeder Ebene des transitiven Baums. Ihre SBOM stammt aus dem Build, der ausgeliefert wurde. So haben Sie die Liste, die ein Angreifer nie gebraucht hat, bevor irgendjemand danach sucht.
SBOMs zur Build-Zeit →Red Team
Ein neues Advisory sagt Ihnen genau, welche Versionen verwundbar sind. Bauen Sie den Exploit, scannen Sie nach allem, was antwortet, und lassen Sie sich vom Scan sagen, wer die Ziele sind. Sie beginnen noch am selben Tag, während deren Team in einem Slack-Thread noch fragt: „Sind wir betroffen?“
Blue Team
CRACI bewertet überwachte SBOMs laufend anhand neuer Schwachstellendaten neu. Die Build-Historie zeigt, welche Builds die verwundbare Abhängigkeit enthielten, direkt oder transitiv, sodass Sie wissen, wo sie ausgeliefert wurde und wie lange.
Sind wir betroffen? →Stufe 2 von 3
Nutzen Sie den Fehler aus, bevor er gepatcht ist, oder sparen Sie sich den Fehler und fahren Sie in deren Pipeline mit.
Red Team
KI macht aus einem Advisory und einem Patch-Diff einen funktionierenden Angriff, bevor deren Sicherheitsteam das Ticket gesichtet hat. Die Offenlegung ist Ihr Startschuss. Deren Sprint-Planung ist nächste Woche.
Blue Team
Policy-Gates können jeden Build blockieren, der eine bestimmte CVE enthält. So wird die verwundbare Version ab dem Moment, in dem Sie es entscheiden, nicht mehr ausgeliefert, egal wie tief sie im Baum steckt.
CVE-Behebung →Red Team
Workflows vertrauen Tags wie @v4, und Tags lassen sich verschieben. Kompromittieren Sie eine beliebte GitHub Action, und jeder Workflow, der sie nutzt, führt Ihren Code aus, mit seinen Secrets in Reichweite.
Blue Team
CRACI hält die GitHub Actions, die ein Workflow ausführt, in der SBOM des Builds fest, gepinnt auf den Commit, der tatsächlich gelaufen ist. Wird eine Action kompromittiert, sehen Sie, welche Builds den schädlichen Code ausgeführt haben, statt anhand eines Tags zu raten.
CI/CD-Sicherheitscheckliste →Stufe 3 von 3
Nehmen Sie die Secrets mit und bleiben Sie, um mehr zu holen.
Red Team
Ein bösartiges Paket-Release führt sein Install-Skript in deren Build aus, dort, wo die Tokens und Cloud-Zugangsdaten liegen. CI-Runner erreichen meist das gesamte Internet, also gehen die Secrets an Ihren Server, bevor irgendjemand weiß, dass das Paket bösartig ist.
Blue Team
Eine Default-Deny-Egress-Richtlinie lässt einen Build seine Paketquellen und Veröffentlichungsziele erreichen und blockiert alles andere. Malware, die Ihre Secrets an den Host eines Angreifers sendet, wird blockiert, selbst als Patient null eines Angriffs, den noch niemand gesehen hat, und Sie erhalten eine Warnung zum Richtlinienverstoß.
Egress-Richtlinien →Red Team
Langlebige Self-Hosted Runner sind ein Geschenk: Platzieren Sie etwas im Workspace oder Tool-Cache und warten Sie, bis der nächste Job und die nächsten Secrets zu Ihnen kommen.
Blue Team
Jeder CRACI-Job läuft in seiner eigenen isolierten virtuellen Maschine, sodass nichts, was ein Job hinterlässt, auf den nächsten wartet. Es gibt auch keine Runner-Flotte, die Sie patchen und härten müssen.
Verwaltete vs. Self-Hosted Runner →Nach der Offenlegung
Der Angreifer muss nicht wissen, dass Sie die Abhängigkeit nutzen. Er probiert den Exploit überall aus und sieht, was antwortet. Ihr Team muss wissen, wohin diese Abhängigkeit ausgeliefert wurde. Der Unterschied ist, ob Sie danach suchen müssen, und jedes Jahr gibt es mehr Rennen zu laufen: siehe wie viele CVEs täglich veröffentlicht werden.
Red Team
Blue Team, ohne Build-Aufzeichnung
Blue Team, mit CRACI
Keine einzelne Maßnahme stoppt jeden Lieferkettenangriff. Kombinieren Sie diese Maßnahmen, und jede Stufe oben wird schwieriger. Die Pipeline-Seite im Detail finden Sie in der Checkliste für CI/CD-Pipeline-Sicherheit.
Angreifer beobachten jedes Advisory und probieren den Exploit noch am Tag der Offenlegung an allen aus. Ihre Abhängigkeitsliste haben sie nie gebraucht. Sie schon. CRACI gibt Ihrem Team diese Liste, aus dem Build selbst, und schließt die Türen, auf die Angreifer setzen: offenen Egress und geteilte Runner.
Ein Angriff auf den Code, die Tools oder die Dienste, aus denen ein Produkt gebaut wird, etwa ein Open-Source-Paket, eine CI/CD-Komponente oder das Build-System, statt auf das Produkt selbst. Eine einzige Kompromittierung erreicht jede Organisation, die die betroffene Komponente nutzt.
Der Wurm Shai-Hulud (seit 2025) verbreitete sich über infizierte npm-Pakete und stahl CI-Secrets. Bei der Kompromittierung von tj-actions/changed-files (CVE-2025-30066) wurde eine beliebte GitHub Action gekapert. Die Hintertür in xz utils (CVE-2024-3094) wurde in eine Upstream-Kompressionsbibliothek eingeschleust. Log4Shell (CVE-2021-44228) nutzte einen Fehler in einer weit verbreiteten Java-Logging-Bibliothek aus. Der Bash Uploader von Codecov (2021) wurde so verändert, dass er CI-Zugangsdaten an einen externen Server sendete, und SolarWinds Orion (2020) lieferte bösartigen Code aus, der beim Build eingefügt worden war.
SolarWinds. 2020 fügten Angreifer mit verdecktem Zugang zum Build-Prozess von SolarWinds Orion bösartigen Code in dessen Releases ein, und Kunden installierten ihn als normales Update. Der Fall zeigte, dass sauberer Quellcode nicht reicht: Auch der Build selbst muss vertrauenswürdig und überprüfbar sein.
Meist nicht, und das müssen sie auch nicht. Die meisten Angriffe zielen auf ein Paket statt auf ein Unternehmen: Sobald ein Advisory erschienen ist, probieren Angreifer den Exploit an allem aus, was eine verwundbare Version ausführen könnte, und sehen, was antwortet. Öffentliche Hinweise wie Versionen in JavaScript-Bundles oder Open-Source-Repositories helfen ihnen beim Zielen. Die Asymmetrie: Sie brauchen die Liste sehr wohl. Um zu wissen, ob Sie betroffen sind, müssen Sie wissen, was jeder Build ausgeliefert hat, einschließlich dessen, was er außerhalb des Lockfiles geladen hat.
Keine einzelne Maßnahme stoppt sie alle. Führen Sie eine SBOM dessen, was jeder Build ausliefert, und überwachen Sie sie auf neue Advisories, pinnen Sie Abhängigkeiten und GitHub Actions, blockieren Sie verwundbare Versionen beim Build, beschränken Sie, womit sich CI-Jobs verbinden dürfen, isolieren Sie Jobs und begrenzen Sie ihre Secrets, und prüfen Sie, ob die deployten Artefakte die sind, die Sie gebaut haben.
Committen Sie ein Lockfile und installieren Sie im CI daraus, und deaktivieren Sie Install-Skripte, wo ein Build sie nicht braucht (--ignore-scripts bei npm). Führen Sie eine Aufzeichnung darüber, welche Paketversionen jeder Build tatsächlich installiert hat, damit Sie schnell prüfen können, wenn eine neue Welle wie Shai-Hulud bekannt wird. Beschränken Sie, womit sich CI-Jobs verbinden dürfen, damit ein bösartiges Install-Skript Ihre Tokens nicht hinaussenden kann, und rotieren Sie jedes Token, das eine infizierte Version erreicht haben könnte.
Bei Sicherheitsübungen spielt das Red Team den Angreifer, und das Blue Team verteidigt. Diese Seite nutzt dieselbe Aufteilung: jede Stufe eines Lieferkettenangriffs in den Worten des Angreifers, beantwortet von der Verteidigung.
Bekannte, ja. Ein bösartiges Release mit einer veröffentlichten CVE, etwa die xz-Hintertür, wird wie jede andere Schwachstelle gekennzeichnet, und ein Policy-Gate kann Builds blockieren, die es enthalten. CRACI analysiert weder das Verhalten von Paketen, noch bewertet es ihre Reputation, daher bleibt ein brandneues bösartiges Paket ungekennzeichnet, bis ein Advisory existiert. Dafür ist die Egress-Richtlinie da: Mit Default Deny erreicht der Build nur die Hosts, die er braucht, sodass das Paket Ihre Secrets nicht hinaussenden kann, selbst bei einem Angriff, den noch niemand gesehen hat.