„Moment mal – hat gerade jemand unser AWS SDK manipuliert?“ Genau diese Frage hätten sich Millionen von Entwicklern stellen müssen, wäre der CodeBreach-Angriff nicht rechtzeitig entdeckt worden. Wiz Research hat eine kritische Schwachstelle in AWS CodeBuild aufgedeckt, die eine vollständige Übernahme des AWS JavaScript SDKs ermöglicht hätte. Mit über 15 Jahren Erfahrung in Softwarequalität, Open Source und Remote Consulting zeigen wir euch bei Never Code Alone, was passiert ist, warum CI/CD-Pipelines zum primären Angriffsziel geworden sind und wie ihr eure eigenen Build-Systeme absichert.
Warum der CodeBreach-Angriff die Cloud-Welt hätte erschüttern können
Das AWS JavaScript SDK ist keine unbedeutende Bibliothek. Es steckt in der AWS Console selbst und damit im zentralen Nervensystem der Cloud-Infrastruktur. Wiz-Analysen zeigen, dass das SDK in rund zwei Dritteln aller Cloud-Umgebungen installiert ist. Ein erfolgreicher Supply-Chain-Angriff hätte nicht nur einzelne Anwendungen, sondern potenziell jeden AWS-Account betroffen, der die Console nutzt.
Die Schwachstelle selbst ist dabei fast schon banal: Zwei fehlende Zeichen in einem Regex-Filter. Die Anchor-Zeichen ^ und $ fehlten in der ACTOR_ID-Validierung, was es Angreifern ermöglichte, Build-Prozesse mit beliebigen GitHub-User-IDs auszulösen, solange diese die legitimen IDs als Substring enthielten. Ein klassischer Fall von „kleine Ursache, massive Wirkung“.
1. Was genau ist bei der CodeBreach-Schwachstelle passiert?
Wiz Research entdeckte im August 2025 eine Fehlkonfiguration in AWS CodeBuild, die öffentliche Build-Projekte betraf. Der Kern des Problems: CodeBuild-Webhooks sollten nur Builds von autorisierten GitHub-Benutzern zulassen. Die Implementierung nutzte dafür einen ACTOR_ID-Filter mit Regular Expressions.
Das Problem: Die Regex-Pattern waren nicht korrekt verankert. Statt ^12345$ (exakte Übereinstimmung) wurde nur 12345 verwendet. Das bedeutet: Jede GitHub-User-ID, die „12345″ enthält, also auch „1234567″ oder „9912345″, konnte den Filter passieren.
Die Forscher nutzten einen Effekt namens „Eclipse“: Da GitHub numerische User-IDs sequentiell vergibt, konnten sie vorhersagen, wann neue IDs erstellt würden, die autorisierte IDs als Substring enthalten. Mit automatisierter GitHub-App-Erstellung sicherten sie sich IDs, die den Filter umgingen. Sobald sie einen Build auslösen konnten, extrahierten sie aus dem Build-Speicher einen GitHub Personal Access Token mit Admin-Rechten über das gesamte JavaScript SDK Repository.
2. Welche Repositories waren konkret betroffen und welche Zugriffsrechte konnten erlangt werden?
Wiz identifizierte mindestens vier AWS GitHub-Repositories mit der gleichen Schwachstelle: das AWS SDK für JavaScript, AWS Libcrypto, Amazon Corretto Crypto Provider und das Registry of Open Data on AWS.
Die erlangten Credentials gehörten zum Automationsaccount „aws-sdk-js-automation“, der volle Admin-Rechte über das JavaScript SDK Repository besaß. Damit hätten Angreifer folgende Aktionen ausführen können: Code direkt in den Main-Branch pushen, Pull Requests eigenständig genehmigen, Repository-Secrets exfiltrieren und externe Collaborator als Repository-Administratoren einladen.
Besonders kritisch: Der gleiche Bypass betraf auch mehrere private AWS Repositories, darunter scheinbar private Mirrors des JavaScript SDKs. Bei einem der betroffenen Accounts handelte es sich sogar um einen persönlichen GitHub-Account eines AWS-Mitarbeiters, nicht um einen Automationsaccount.
3. Warum sind CI/CD-Pipelines zum Hauptziel für Supply-Chain-Angriffe geworden?
CI/CD-Systeme vereinen drei Eigenschaften, die sie für Angreifer attraktiv machen: Sie sind komplex, verarbeiten nicht vertrauenswürdige Eingaben und besitzen privilegierte Credentials. Diese Kombination macht sie zum perfekten Angriffsziel.
Build-Pipelines haben naturgemäß Zugriff auf Quellcode, Deployment-Credentials und oft auch auf Produktionsumgebungen. Gleichzeitig müssen sie Code aus externen Quellen verarbeiten, etwa Pull Requests von Contributors. Jede Fehlkonfiguration in dieser Vertrauenskette kann katastrophale Folgen haben.
Der CodeBreach-Fall ist kein Einzelfall. Im Juli 2025 wurde bereits die Amazon Q VS Code Extension über eine ähnliche CodeBuild-Schwachstelle kompromittiert. Die Nx S1ngularity Supply-Chain-Attacke im August 2025 nutzte ebenfalls CI/CD-Schwachstellen. Der Trend ist eindeutig: Angreifer haben erkannt, dass ein kompromittiertes Build-System weitreichendere Auswirkungen hat als das Hacken einzelner Endpunkte.
4. Wie hätte ein erfolgreicher Angriff auf das AWS SDK konkret ausgesehen?
Das JavaScript SDK wird wöchentlich auf GitHub und NPM released. Ein Angreifer mit Repository-Kontrolle hätte kurz vor einem Release bösartigen Code injizieren können, der dann automatisch an Millionen von Nutzern verteilt worden wäre.
Da die AWS Console selbst das SDK bündelt und aktuelle Versionen ausliefert, wäre der Schadcode direkt in der Administrationsoberfläche gelandet. Administratoren hätten bei der Nutzung der Console unwissentlich kompromittierten Code ausgeführt, der Zugriff auf ihre AWS-Credentials gehabt hätte.
Wiz beschreibt das Szenario als potenziell gravierender als SolarWinds: Während SolarWinds Angreifern Zugang zu Unternehmensnetzwerken verschaffte, hätte CodeBreach Code-Ausführung in der Oberfläche ermöglicht, über die Administratoren ihre gesamte Cloud-Infrastruktur verwalten. Der Unterschied zwischen Netzwerkzugang und Zugang zur zentralen Management-Konsole ist substanziell.
5. Was hat AWS unternommen, um die Schwachstelle zu beheben?
AWS reagierte schnell nach der Meldung durch Wiz am 25. August 2025. Innerhalb von 48 Stunden wurden die Regex-Filter korrigiert und der kompromittierte Personal Access Token widerrufen. Im September 2025 implementierte AWS zusätzliche Härtungsmaßnahmen, um zu verhindern, dass nicht-privilegierte Builds über Memory-Dumps auf Credentials zugreifen können.
AWS führte zudem ein umfassendes Audit aller öffentlichen Build-Umgebungen durch und analysierte CloudTrail-Logs, um sicherzustellen, dass niemand die Schwachstelle bereits ausgenutzt hatte. Das Ergebnis: Keine Anzeichen für eine Kompromittierung vor der Entdeckung durch Wiz.
Als präventive Maßnahme hat AWS eine neue Funktion eingeführt: Die Pull Request Comment Approval Build Gate. Diese ermöglicht es Organisationen, Builds von nicht vertrauenswürdigen Pull Requests erst nach expliziter Genehmigung auszuführen. Zusätzlich wurden CodeBuild-hosted Runners eingeführt, die Build-Trigger über GitHub Actions statt über AWS-eigene Webhook-Verarbeitung managen.
6. Welche Best Practices sollten Teams jetzt für ihre CodeBuild-Projekte implementieren?
Die wichtigste Sofortmaßnahme: Überprüft eure Webhook-Filter auf korrekte Regex-Verankerung. Jedes Pattern, das eine User-ID oder andere Identifikatoren filtert, muss mit ^ beginnen und mit $ enden. Ohne diese Anker ist der Filter praktisch wirkungslos.
Aktiviert die neue Pull Request Comment Approval Gate. Diese Funktion stellt sicher, dass Builds von externen Pull Requests erst nach expliziter Genehmigung durch einen Maintainer starten. Das unterbricht den automatischen Angriffsvektor, den Wiz demonstriert hat.
Verwendet Fine-Grained Personal Access Tokens statt Classic Tokens. Fine-Grained Tokens ermöglichen granulare Berechtigungen und können auf spezifische Repositories beschränkt werden. Classic Tokens mit repo-Scope gewähren dagegen Vollzugriff auf alle Repositories des Accounts.
Wenn ihr automatische Builds von Pull Requests benötigt, nutzt CodeBuild-hosted Runners statt direkte Webhook-Konfiguration. Die Runner-Architektur isoliert Repository-Credentials vom Build-Environment und nutzt GitHub Actions statt CodeBuild-eigene Webhook-Verarbeitung.
7. Wie können wir erkennen, ob unsere eigenen Build-Systeme ähnliche Schwachstellen aufweisen?
Der erste Schritt ist ein Audit eurer öffentlichen CodeBuild-Projekte. Wenn ein Projekt auf „public“ gesetzt ist, sind seine Einstellungen über ein öffentlich zugängliches Dashboard einsehbar. Dieses Dashboard zeigt auch die verwendeten Webhook-Filter, also genau die Informationen, die ein Angreifer für die Exploitation benötigt.
Überprüft alle Regex-Pattern in euren Webhook-Konfigurationen. Sucht nach Patterns, die numerische IDs filtern, aber keine Start- und End-Anker verwenden. Testet eure Filter mit Werten, die die legitimen IDs als Substring enthalten, also nicht nur exakte Matches.
Analysiert, welche Credentials in euren Build-Environments verfügbar sind. Jedes Token, jeder API-Key und jede Zugangsberechtigung, die während eines Builds im Speicher liegt, kann potenziell exfiltriert werden. Dokumentiert diese Credentials und prüft, ob sie wirklich minimal notwendige Berechtigungen haben.
Wiz bietet Queries an, mit denen ihr eure eigene Infrastruktur auf ähnliche Fehlkonfigurationen scannen könnt. Diese helfen, verwundbare Setups automatisiert zu identifizieren, bevor ein Angreifer sie findet.
8. Was bedeutet das Shared Responsibility Model bei CI/CD-Security konkret?
AWS betont in seinem Security Bulletin, dass CodeBreach keine Schwachstelle im CodeBuild-Service selbst war, sondern eine projekt-spezifische Fehlkonfiguration. Diese Unterscheidung ist wichtig: AWS ist für die Sicherheit der Infrastruktur verantwortlich, aber die Konfiguration der Build-Projekte liegt in eurer Verantwortung.
Das Shared Responsibility Model bei CI/CD bedeutet konkret: AWS stellt sichere Dienste bereit und implementiert Schutzmaßnahmen auf Plattformebene. Ihr seid verantwortlich für die korrekte Konfiguration dieser Dienste, für Access Controls, für das Credential Management und für den Code, der in euren Build-Environments läuft.
Bei Never Code Alone sehen wir häufig, dass Teams dieses Modell missverstehen. Sie gehen davon aus, dass „managed services“ automatisch sicher konfiguriert sind. Das Gegenteil ist der Fall: Managed Services bieten Flexibilität, die auch zu unsicheren Konfigurationen führen kann. Die Sicherheit eurer Pipelines ist eure Aufgabe.
9. Wie sollte eine Defense-in-Depth-Strategie für Build-Pipelines aussehen?
Defense in Depth bedeutet mehrere unabhängige Sicherheitsschichten, sodass das Versagen einer Schicht nicht zur vollständigen Kompromittierung führt. Für Build-Pipelines empfehlen wir ein Fünf-Schichten-Modell.
Die erste Schicht ist Access Control: Verwendet IAM-Rollen mit minimalen Berechtigungen für jeden Build-Agent. Keine Wildcard-Policies, keine geteilten Credentials zwischen Projekten. Jedes Projekt bekommt genau die Rechte, die es braucht, nicht mehr.
Die zweite Schicht ist Build-Isolation: Privilegierte Builds sollten in isolierten Environments laufen, getrennt von Builds, die externen Code verarbeiten. Ephemeral Runners, die nach jedem Build zerstört werden, minimieren das Risiko persistenter Kompromittierung.
Die dritte Schicht ist Credential Management: Keine Secrets in Environment-Variablen oder Build-Logs. Verwendet AWS Secrets Manager mit Runtime-Injection und rotiert Credentials regelmäßig. Personal Access Tokens sollten Fine-Grained sein mit minimal notwendigen Scopes.
Die vierte Schicht ist Monitoring und Alerting: CloudTrail für API-Audits, CloudWatch für Build-Logs, Alarme bei ungewöhnlichen Aktivitäten. Jeder Build-Trigger, jeder Credential-Zugriff sollte nachvollziehbar sein.
Die fünfte Schicht ist Incident Response: Habt einen Plan für den Fall einer Pipeline-Kompromittierung. Wer rotiert die Credentials? Wer analysiert die Build-Logs? Wie schnell könnt ihr alle betroffenen Releases identifizieren und kommunizieren?
10. Welche Lehren sollten Entscheider aus dem CodeBreach-Fall ziehen?
Der CodeBreach-Fall zeigt, dass Supply-Chain-Sicherheit keine rein technische Angelegenheit ist. Zwei fehlende Zeichen in einer Konfiguration hätten Millionen von AWS-Nutzern gefährdet. Das Risiko ist real, die Auswirkungen potenziell katastrophal, und die Angriffsvektoren oft subtil.
Investiert in CI/CD-Security, bevor ein Incident passiert. Die Kosten für proaktive Sicherheitsmaßnahmen sind ein Bruchteil dessen, was eine erfolgreiche Supply-Chain-Attacke kosten würde. Teams, die heute ihre Build-Pipelines härten, vermeiden morgen die Krisenkommunikation.
Behandelt eure CI/CD-Infrastruktur als kritische Angriffsfläche. Build-Systeme haben oft mehr Rechte als die Anwendungen, die sie deployen. Sie verdienen mindestens das gleiche Security-Audit wie eure Produktionsumgebungen.
Etabliert regelmäßige Security Reviews für Pipeline-Konfigurationen. Webhook-Filter, IAM-Rollen, Credential-Scopes, alles davon kann sich über Zeit ändern und neue Angriffsvektoren eröffnen. Continuous Security bedeutet auch kontinuierliche Überprüfung eurer Build-Infrastruktur.
Best Practices aus über 15 Jahren Security-Consulting
Bei Never Code Alone haben wir in unzähligen Projekten gesehen, wie leicht sich Build-Pipelines kompromittieren lassen und wie schwer die Folgen wiegen. Hier unsere konsolidierten Empfehlungen:
Assume Breach bei externen Pull Requests: Jeder PR von außen ist potenziell bösartig. Behandelt externe Contributions wie nicht vertrauenswürdigen Input, validiert alles, führt nichts automatisch mit erhöhten Rechten aus.
Credential Minimierung: Wenn ein Build-Process nur Leserechte auf ein Repository braucht, gebt ihm keine Schreibrechte. Fine-Grained Tokens mit expliziten Scopes sind Pflicht, Classic Tokens mit breiten Berechtigungen ein Risiko.
Transparenz über Build-Environments: Dokumentiert, welche Secrets in welchen Build-Stages verfügbar sind. Jedes Token, jeder Key, jede Berechtigung sollte begründet und regelmäßig überprüft werden.
Automatisierte Security-Checks: Integriert Scans für Fehlkonfigurationen in eure CI/CD-Pipeline selbst. Tools wie Checkov oder AWS Config Rules können Policy-Violations automatisch erkennen.
Incident Response vorbereiten: Plant für den Fall einer Pipeline-Kompromittierung. Wer ist zuständig? Welche Credentials müssen rotiert werden? Wie kommuniziert ihr mit betroffenen Downstream-Nutzern?
Der entscheidende Vorteil für eure Projekte
Supply-Chain-Sicherheit ist kein optionales Feature mehr. Der CodeBreach-Fall demonstriert eindrücklich, dass selbst große Cloud-Provider anfällig für Konfigurationsfehler sind. Die gute Nachricht: Die Schutzmaßnahmen sind bekannt, dokumentiert und implementierbar.
Teams, die jetzt in CI/CD-Security investieren, verschaffen sich einen echten Wettbewerbsvorteil. Sie vermeiden nicht nur potenzielle Incidents, sondern demonstrieren auch Kunden und Partnern, dass Sicherheit ernst genommen wird. In einer Zeit, in der Supply-Chain-Attacken zunehmen, ist das ein starkes Signal.
Direkte Unterstützung für euer Team
Ihr wollt eure Build-Pipelines systematisch absichern und braucht Unterstützung bei der Umsetzung? Oder steht ihr vor der Aufgabe, eure CI/CD-Architektur auf Schwachstellen zu auditieren? Mit über 15 Jahren Expertise in Softwarequalität, Open Source und Remote Consulting helfen wir euch gerne weiter.
Kontakt: roland@nevercodealone.de
Gemeinsam machen wir eure Build-Infrastruktur resilient, mit pragmatischen Lösungen, die in euren Workflow passen und eure Entwickler nicht ausbremsen.
Fazit: Supply-Chain-Security beginnt bei der Pipeline
Der CodeBreach-Fall ist ein Weckruf für alle, die CI/CD-Systeme betreiben. Zwei fehlende Zeichen hätten ausgereicht, um das zentrale Nervensystem der AWS-Cloud zu kompromittieren. Die Angriffsfläche ist real, die Angreifer sind aktiv, und die Zeit für proaktive Maßnahmen ist jetzt.
Startet heute: Auditiert eure Webhook-Konfigurationen, aktiviert die neuen Schutzfunktionen, implementiert Defense in Depth. Die Erkenntnisse werden euch überraschen, und eure Systeme nachhaltig sicherer machen.
Never Code Alone – Gemeinsam für bessere Software-Qualität!
