Ihre App ist risikoarm. Ihre Build-Pipeline nicht.

Die Überlegung stimmt, bis zu einem gewissen Punkt

Wir hören das oft, und es hat meist vernünftige Gründe. Die App ist ein internes Dashboard, eine Datenpipeline oder ein kleiner Dienst mit einer Handvoll Nutzern. Sie enthält nichts, was ein Angreifer will. Das Sicherheitsbudget fließt zuerst in das Produkt für die Kunden.

Für die Anwendung stimmt diese Logik. Für die Art, wie die Anwendung gebaut wird, stimmt sie nicht. Jedes Team hat, was immer es ausliefert, eine CI-Pipeline mit Zugangsdaten und einen Abhängigkeitsbaum, den es nicht geschrieben hat. Beide sind lohnende Ziele, weil sie gemeinsam genutzt werden, und eine Kompromittierung dort erreicht alles andere, worauf diese Zugangsdaten zugreifen können: Ihre Registries, Ihre Cloud-Konten und Ihre anderen Repositories.

Angriffe, denen egal war, was die App tut

Keiner dieser Vorfälle zielte auf eine bestimmte Art von Anwendung. Jeder erreichte Teams über ein Tool oder Paket, mit dem sie Software bauten.

tj-actions/changed-files, 2025

Eine weit verbreitete GitHub Action, die geänderte Dateien erkennt, wurde kompromittiert. Laut CISA waren bösartige Versionen zwischen dem 12. und 15. März 2025 aktiv, und die Kompromittierung legte Secrets offen, darunter Access Keys, GitHub Personal Access Tokens, npm-Tokens und private RSA-Schlüssel. Wiz berichtete, dass der Code den Speicher des CI-Runners auslas, sodass die Secrets bei öffentlichen Repositories in den Workflow-Logs landeten. Workflows, die die Action per Versions-Tag referenzierten, führten den bösartigen Code aus, unabhängig davon, was das Repository enthielt.

npm-Wurm Shai-Hulud, 2025

Im September 2025 warnte CISA vor einem sich selbst replizierenden Wurm, der mehr als 500 npm-Pakete kompromittiert hatte. Er sammelte GitHub Personal Access Tokens und Cloud-API-Schlüssel für AWS, Google Cloud und Azure. Palo Alto Networks Unit 42 beschrieb, wie er gestohlene npm-Tokens nutzte, um infizierte Versionen der anderen Pakete des Opfers zu veröffentlichen, und wie eine spätere Welle während der Pre-Install-Phase lief, was seine Reichweite in CI/CD-Pipelines vergrößerte.

3:27

Codecov Bash Uploader, 2021

Ein Angreifer gelangte über einen Fehler im Docker-Image-Build-Prozess von Codecov an Zugangsdaten und veränderte das Skript Bash Uploader, das viele Teams im CI ausführten. Vom 31. Januar bis zum 1. April 2021 konnte das veränderte Skript Umgebungsvariablen, darunter die in der CI-Umgebung verfügbaren Zugangsdaten, Tokens und Schlüssel, an Dritte senden. Entdeckt wurde es, als ein Kunde bemerkte, dass die Prüfsumme des Skripts nicht übereinstimmte.

xz utils, 2024

Bösartiger Code wurde in die XZ-Utils-Versionen 5.6.0 und 5.6.1 eingebettet, eine Bibliothek zur Datenkompression, die in Linux-Distributionen enthalten sein kann. CISA riet dazu, auf eine nicht kompromittierte Version wie 5.4.6 zurückzugehen und nach bösartigen Aktivitäten zu suchen. Unspektakulärer als eine Kompressionsbibliothek kann eine Abhängigkeit kaum sein, und sie war trotzdem ein Ziel.

event-stream, 2018

Eine Person, die sich als hilfsbereiter Maintainer ausgab, übernahm das beliebte npm-Paket event-stream und fügte in Version 3.3.6 die bösartige Abhängigkeit flatmap-stream hinzu. Laut dem npm-Team zielte die Schadfunktion auf eine bestimmte Anwendung, die Bitcoin-Wallet Copay. Alle anderen, die event-stream installierten, erhielten den bösartigen Code ebenfalls.

Was diese Vorfälle gemeinsam haben

• Sie geschahen beim Build oder bei der Installation. Der bösartige Code lief auf Entwicklerrechnern und CI-Runnern, nicht in der produktiven App.
• Sie zielten auf Zugangsdaten. Tokens und Schlüssel in der Pipeline waren die Beute, denn sie öffnen Türen über das gebaute Projekt hinaus.
• Sie kamen über vertrauenswürdige Namen. Eine vertraute Action, ein vertrautes Paket, ein vertrautes Skript. Niemand hat sich dafür entschieden, Malware zu installieren.
• Die erste Frage danach war immer dieselbe. Hat einer unserer Builds die schädliche Version geladen, und was konnte sie erreichen? Teams ohne Aufzeichnung dessen, was jeder Build genutzt hat, mussten es rekonstruieren.

Wie minimaler Aufwand aussieht

Für die Grundlagen brauchen Sie kein Sicherheitsteam. Die meisten Empfehlungen von GitHub und CISA passen in eine kurze Liste:

1. Pinnen Sie GitHub Actions von Drittanbietern auf einen vollständigen Commit-SHA statt auf einen Tag, damit ein verschobener Tag nicht ändern kann, was ausgeführt wird.
2. Committen Sie Lockfiles und pinnen Sie Abhängigkeitsversionen auf bekannte gute Releases.
3. Geben Sie CI-Tokens die engsten Rechte, mit denen es funktioniert, und rotieren Sie sie, wenn ein Vorfall etwas betrifft, das Sie nutzen.
4. Verlangen Sie für Entwickler- und Veröffentlichungskonten eine phishing-resistente Multi-Faktor-Authentifizierung.
5. Führen Sie Aufzeichnungen darüber, was jeder Build installiert hat, damit Sie die Frage „Waren wir betroffen?“ aus Daten beantworten können statt aus der Erinnerung.

Die ersten vier sind Konfiguration. Den fünften Punkt lassen die meisten kleinen Teams aus, weil er Tools erfordert.

Wo CRACI mit wenig Aufwand hilft

CRACI übernimmt die Aufzeichnung und ergänzt eine Netzwerkgrenze, ohne dass Sie Ihre App oder Ihre Workflows ändern müssen.

• Eine Zeile pro Job. Ändern Sie runs-on auf craci. Ihre GitHub-Actions-Workflows bleiben, wie sie sind, und die Läufe erscheinen weiterhin in GitHub.
• Eine SBOM aus jedem Build. CRACI zeichnet die Pakete auf, die jeder Job tatsächlich lädt, einschließlich der aus Caches wiederhergestellten Pakete, und exportiert das Ergebnis als CycloneDX oder SPDX.
• Ein Netzwerk-Trace pro Job. Wird ein Vorfall bekannt, können Sie prüfen, welche Builds das betroffene Paket geladen haben und wohin sich jeder Job verbunden hat.
• Eine Egress-Richtlinie, die Sie auf Default Deny umstellen können. Erlauben Sie die Paketquellen, die ein Job braucht, und ein kompromittierter Schritt hat weniger Ziele für das, was er findet. Richtlinien blockieren im Zweifel (fail closed), und Verstöße lösen eine Warnung aus.
• Laufende Neubewertung. Überwachte SBOMs werden erneut geprüft, sobald neue Schwachstellen veröffentlicht werden, damit ein alter Build nicht nur deshalb „sauber“ bleibt, weil niemand nachgesehen hat.

Um die Grenzen klar zu benennen: Eine Egress-Richtlinie hätte die tj-actions-Kompromittierung nicht daran gehindert, Secrets in ein öffentliches Log zu schreiben, und kein Tool macht ein geleaktes Token ungeschehen. Pinnen und Rotieren bleiben wichtig. Was CRACI ändert, ist, wie schnell Sie beantworten können, ob Sie exponiert waren, und wie weit ein kompromittierter Schritt reichen kann.

Für einen ersten laufenden Workflow installieren Sie die GitHub App und ändern eine Zeile auf runs-on: craci.

Was es kostet

CRACI berechnet nur Build-Minuten: $0.002 pro vCPU-Minute ($0.004 für einen Standard-Runner mit 2 vCPUs), sekundengenau abgerechnet, ohne Monatsgebühr und ohne Gebühr pro SBOM. Die vollständigen Bedingungen finden Sie unter Preise. Berechtigte Startups können sich für das Startup-Programm bewerben und erhalten mindestens 100k kostenlose Build-Minuten und ein persönliches Onboarding.

Wenn Sie Software in der EU verkaufen, lohnt es sich außerdem zu prüfen, ob der Cyber Resilience Act für Sie gilt. Unser Leitfaden zum CRA erklärt den Anwendungsbereich und die Fristen.